File: rfc8921.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (4707 lines) | stat: -rw-r--r-- 263,757 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8921: Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)</title>
<meta content="Mohamed Boucadair" name="author">
<meta content="Christian Jacquenet" name="author">
<meta content="Dacheng Zhang" name="author">
<meta content="Panos Georgatsos" name="author">
<meta content="
       This document defines the Connectivity Provisioning Negotiation
      Protocol (CPNP), which is designed to facilitate the dynamic negotiation
      of service parameters. 
       CPNP is a generic protocol that can be used for various negotiation
      purposes that include (but are not necessarily limited to) connectivity
      provisioning services, storage facilities, Content Delivery Networks,
      etc. 
    " name="description">
<meta content="xml2rfc 3.3.0" name="generator">
<meta content="SDN" name="keyword">
<meta content="Order Request Handling" name="keyword">
<meta content="Automation" name="keyword">
<meta content="Dynamic Provisioning" name="keyword">
<meta content="CDN" name="keyword">
<meta content="Interconnection" name="keyword">
<meta content="Service Delivery" name="keyword">
<meta content="Service Activation" name="keyword">
<meta content="8921" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.3.0
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc8921.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8921" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-protocol-22" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8921</td>
<td class="center">CPNP</td>
<td class="right">October 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Boucadair, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8921" class="eref">8921</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-10" class="published">October 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">M. Boucadair, <span class="editor">Ed.</span>
</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">C. Jacquenet</div>
<div class="org">Orange</div>
</div>
<div class="author">
      <div class="author-name">D. Zhang</div>
<div class="org">Huawei Technologies</div>
</div>
<div class="author">
      <div class="author-name">P. Georgatsos</div>
<div class="org">CERTH</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8921</h1>
<h1 id="title">Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines the Connectivity Provisioning Negotiation
      Protocol (CPNP), which is designed to facilitate the dynamic negotiation
      of service parameters.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">CPNP is a generic protocol that can be used for various negotiation
      purposes that include (but are not necessarily limited to) connectivity
      provisioning services, storage facilities, Content Delivery Networks,
      etc.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8921">https://www.rfc-editor.org/info/rfc8921</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-cpnp-functional-elements" class="xref">CPNP Functional Elements</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-order-processing-models" class="xref">Order Processing Models</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-sample-use-cases" class="xref">Sample Use Cases</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-cpnp-deployment-models" class="xref">CPNP Deployment Models</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-cpnp-negotiation-model" class="xref">CPNP Negotiation Model</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-protocol-overview" class="xref">Protocol Overview</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-client-server-communication" class="xref">Client/Server Communication</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-policy-configuration-on-the" class="xref">Policy Configuration on the CPNP Server</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-cpnp-session-entries" class="xref">CPNP Session Entries</a><a href="#section-toc.1-1.8.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#section-8.4" class="xref">8.4</a>.  <a href="#name-cpnp-transactions" class="xref">CPNP Transactions</a><a href="#section-toc.1-1.8.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.5">
                <p id="section-toc.1-1.8.2.5.1"><a href="#section-8.5" class="xref">8.5</a>.  <a href="#name-cpnp-timers" class="xref">CPNP Timers</a><a href="#section-toc.1-1.8.2.5.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.6">
                <p id="section-toc.1-1.8.2.6.1"><a href="#section-8.6" class="xref">8.6</a>.  <a href="#name-cpnp-operations" class="xref">CPNP Operations</a><a href="#section-toc.1-1.8.2.6.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.7">
                <p id="section-toc.1-1.8.2.7.1"><a href="#section-8.7" class="xref">8.7</a>.  <a href="#name-connectivity-provisioning-d" class="xref">Connectivity Provisioning Documents</a><a href="#section-toc.1-1.8.2.7.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.8">
                <p id="section-toc.1-1.8.2.8.1"><a href="#section-8.8" class="xref">8.8</a>.  <a href="#name-child-pqos" class="xref">Child PQOs</a><a href="#section-toc.1-1.8.2.8.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.9">
                <p id="section-toc.1-1.8.2.9.1"><a href="#section-8.9" class="xref">8.9</a>.  <a href="#name-multi-segment-service" class="xref">Multi-Segment Service</a><a href="#section-toc.1-1.8.2.9.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.10">
                <p id="section-toc.1-1.8.2.10.1"><a href="#section-8.10" class="xref">8.10</a>. <a href="#name-negotiating-with-multiple-c" class="xref">Negotiating with Multiple CPNP Servers</a><a href="#section-toc.1-1.8.2.10.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.11">
                <p id="section-toc.1-1.8.2.11.1"><a href="#section-8.11" class="xref">8.11</a>. <a href="#name-state-management" class="xref">State Management</a><a href="#section-toc.1-1.8.2.11.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.8.2.11.2.1">
                    <p id="section-toc.1-1.8.2.11.2.1.1"><a href="#section-8.11.1" class="xref">8.11.1</a>.  <a href="#name-on-the-client-side" class="xref">On the Client Side</a><a href="#section-toc.1-1.8.2.11.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.8.2.11.2.2">
                    <p id="section-toc.1-1.8.2.11.2.2.1"><a href="#section-8.11.2" class="xref">8.11.2</a>.  <a href="#name-on-the-server-side" class="xref">On the Server Side</a><a href="#section-toc.1-1.8.2.11.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-cpnp-objects" class="xref">CPNP Objects</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-attributes" class="xref">Attributes</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.1">
                    <p id="section-toc.1-1.9.2.1.2.1.1"><a href="#section-9.1.1" class="xref">9.1.1</a>.  <a href="#name-customer_order_identifier" class="xref">CUSTOMER_ORDER_IDENTIFIER</a><a href="#section-toc.1-1.9.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.2">
                    <p id="section-toc.1-1.9.2.1.2.2.1"><a href="#section-9.1.2" class="xref">9.1.2</a>.  <a href="#name-provider_order_identifier" class="xref">PROVIDER_ORDER_IDENTIFIER</a><a href="#section-toc.1-1.9.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.3">
                    <p id="section-toc.1-1.9.2.1.2.3.1"><a href="#section-9.1.3" class="xref">9.1.3</a>.  <a href="#name-transaction_id" class="xref">TRANSACTION_ID</a><a href="#section-toc.1-1.9.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.4">
                    <p id="section-toc.1-1.9.2.1.2.4.1"><a href="#section-9.1.4" class="xref">9.1.4</a>.  <a href="#name-sequence_number" class="xref">SEQUENCE_NUMBER</a><a href="#section-toc.1-1.9.2.1.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.5">
                    <p id="section-toc.1-1.9.2.1.2.5.1"><a href="#section-9.1.5" class="xref">9.1.5</a>.  <a href="#name-nonce" class="xref">NONCE</a><a href="#section-toc.1-1.9.2.1.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.6">
                    <p id="section-toc.1-1.9.2.1.2.6.1"><a href="#section-9.1.6" class="xref">9.1.6</a>.  <a href="#name-expected_response_time" class="xref">EXPECTED_RESPONSE_TIME</a><a href="#section-toc.1-1.9.2.1.2.6.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.7">
                    <p id="section-toc.1-1.9.2.1.2.7.1"><a href="#section-9.1.7" class="xref">9.1.7</a>.  <a href="#name-expected_offer_time" class="xref">EXPECTED_OFFER_TIME</a><a href="#section-toc.1-1.9.2.1.2.7.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.8">
                    <p id="section-toc.1-1.9.2.1.2.8.1"><a href="#section-9.1.8" class="xref">9.1.8</a>.  <a href="#name-validity_offer_time" class="xref">VALIDITY_OFFER_TIME</a><a href="#section-toc.1-1.9.2.1.2.8.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.9">
                    <p id="section-toc.1-1.9.2.1.2.9.1"><a href="#section-9.1.9" class="xref">9.1.9</a>.  <a href="#name-service_description" class="xref">SERVICE_DESCRIPTION</a><a href="#section-toc.1-1.9.2.1.2.9.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.1.2.10">
                    <p id="section-toc.1-1.9.2.1.2.10.1"><a href="#section-9.1.10" class="xref">9.1.10</a>. <a href="#name-cpnp-information-elements" class="xref">CPNP Information Elements</a><a href="#section-toc.1-1.9.2.1.2.10.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-operation-messages" class="xref">Operation Messages</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.1">
                    <p id="section-toc.1-1.9.2.2.2.1.1"><a href="#section-9.2.1" class="xref">9.2.1</a>.  <a href="#name-quotation" class="xref">QUOTATION</a><a href="#section-toc.1-1.9.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.2">
                    <p id="section-toc.1-1.9.2.2.2.2.1"><a href="#section-9.2.2" class="xref">9.2.2</a>.  <a href="#name-processing" class="xref">PROCESSING</a><a href="#section-toc.1-1.9.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.3">
                    <p id="section-toc.1-1.9.2.2.2.3.1"><a href="#section-9.2.3" class="xref">9.2.3</a>.  <a href="#name-offer" class="xref">OFFER</a><a href="#section-toc.1-1.9.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.4">
                    <p id="section-toc.1-1.9.2.2.2.4.1"><a href="#section-9.2.4" class="xref">9.2.4</a>.  <a href="#name-accept" class="xref">ACCEPT</a><a href="#section-toc.1-1.9.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.5">
                    <p id="section-toc.1-1.9.2.2.2.5.1"><a href="#section-9.2.5" class="xref">9.2.5</a>.  <a href="#name-decline" class="xref">DECLINE</a><a href="#section-toc.1-1.9.2.2.2.5.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.6">
                    <p id="section-toc.1-1.9.2.2.2.6.1"><a href="#section-9.2.6" class="xref">9.2.6</a>.  <a href="#name-ack" class="xref">ACK</a><a href="#section-toc.1-1.9.2.2.2.6.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.7">
                    <p id="section-toc.1-1.9.2.2.2.7.1"><a href="#section-9.2.7" class="xref">9.2.7</a>.  <a href="#name-cancel" class="xref">CANCEL</a><a href="#section-toc.1-1.9.2.2.2.7.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.8">
                    <p id="section-toc.1-1.9.2.2.2.8.1"><a href="#section-9.2.8" class="xref">9.2.8</a>.  <a href="#name-withdraw" class="xref">WITHDRAW</a><a href="#section-toc.1-1.9.2.2.2.8.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.9">
                    <p id="section-toc.1-1.9.2.2.2.9.1"><a href="#section-9.2.9" class="xref">9.2.9</a>.  <a href="#name-update" class="xref">UPDATE</a><a href="#section-toc.1-1.9.2.2.2.9.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.10">
                    <p id="section-toc.1-1.9.2.2.2.10.1"><a href="#section-9.2.10" class="xref">9.2.10</a>. <a href="#name-fail" class="xref">FAIL</a><a href="#section-toc.1-1.9.2.2.2.10.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.9.2.2.2.11">
                    <p id="section-toc.1-1.9.2.2.2.11.1"><a href="#section-9.2.11" class="xref">9.2.11</a>. <a href="#name-activate" class="xref">ACTIVATE</a><a href="#section-toc.1-1.9.2.2.2.11.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-cpnp-message-validation" class="xref">CPNP Message Validation</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-on-the-client-side-2" class="xref">On the Client Side</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-on-the-server-side-2" class="xref">On the Server Side</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-theory-of-operation" class="xref">Theory of Operation</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-client-behavior" class="xref">Client Behavior</a><a href="#section-toc.1-1.11.2.1.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.11.2.1.2.1">
                    <p id="section-toc.1-1.11.2.1.2.1.1"><a href="#section-11.1.1" class="xref">11.1.1</a>.  <a href="#name-order-negotiation-cycle" class="xref">Order Negotiation Cycle</a><a href="#section-toc.1-1.11.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.1.2.2">
                    <p id="section-toc.1-1.11.2.1.2.2.1"><a href="#section-11.1.2" class="xref">11.1.2</a>.  <a href="#name-order-withdrawal-cycle" class="xref">Order Withdrawal Cycle</a><a href="#section-toc.1-1.11.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.1.2.3">
                    <p id="section-toc.1-1.11.2.1.2.3.1"><a href="#section-11.1.3" class="xref">11.1.3</a>.  <a href="#name-order-update-cycle" class="xref">Order Update Cycle</a><a href="#section-toc.1-1.11.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-server-behavior" class="xref">Server Behavior</a><a href="#section-toc.1-1.11.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.11.2.2.2.1">
                    <p id="section-toc.1-1.11.2.2.2.1.1"><a href="#section-11.2.1" class="xref">11.2.1</a>.  <a href="#name-order-processing" class="xref">Order Processing</a><a href="#section-toc.1-1.11.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.2.2.2">
                    <p id="section-toc.1-1.11.2.2.2.2.1"><a href="#section-11.2.2" class="xref">11.2.2</a>.  <a href="#name-order-withdrawal" class="xref">Order Withdrawal</a><a href="#section-toc.1-1.11.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.2.2.3">
                    <p id="section-toc.1-1.11.2.2.2.3.1"><a href="#section-11.2.3" class="xref">11.2.3</a>.  <a href="#name-order-update" class="xref">Order Update</a><a href="#section-toc.1-1.11.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#section-11.3" class="xref">11.3</a>.  <a href="#name-sequence-numbers" class="xref">Sequence Numbers</a><a href="#section-toc.1-1.11.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.11.2.4">
                <p id="section-toc.1-1.11.2.4.1"><a href="#section-11.4" class="xref">11.4</a>.  <a href="#name-message-retransmission" class="xref">Message Retransmission</a><a href="#section-toc.1-1.11.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-some-operational-guidelines" class="xref">Some Operational Guidelines</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-cpnp-server-logging" class="xref">CPNP Server Logging</a><a href="#section-toc.1-1.12.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-business-guidelines-and-obj" class="xref">Business Guidelines and Objectives</a><a href="#section-toc.1-1.12.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.13.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#section-14" class="xref">14</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.14.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#section-15" class="xref">15</a>. <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.15.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.15.2.1">
                <p id="section-toc.1-1.15.2.1.1"><a href="#section-15.1" class="xref">15.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.15.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.15.2.2">
                <p id="section-toc.1-1.15.2.2.1"><a href="#section-15.2" class="xref">15.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.15.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.16.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.17">
            <p id="section-toc.1-1.17.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.17.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document defines the Connectivity Provisioning Negotiation
      Protocol (CPNP) that is meant to dynamically exchange and negotiate
      connectivity provisioning parameters and other service-specific
      parameters between a Customer and a Provider. CPNP is a tool that
      introduces automation to the service negotiation and activation
      procedures, thus fostering the overall service provisioning process.
      CPNP can be seen as a component of the dynamic negotiation metadomain
      described in <span><a href="https://www.rfc-editor.org/rfc/rfc7149#section-2.4" class="relref">Section 2.4</a> of [<a href="#RFC7149" class="xref">RFC7149</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">CPNP is a generic protocol that can be used for negotiation
      purposes other than connectivity provisioning. For example, CPNP can be used
      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).
      Sample negotiation use cases are described in 
<a href="#suc" class="xref">Section 5</a>. <a href="#opm" class="xref">Section 4</a> introduces several
      order processing models and defines those that are targeted by CPNP.
      The CPNP negotiation model is then detailed in <a href="#cnm" class="xref">Section 7</a>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3"><span>[<a href="#RFC7297" class="xref">RFC7297</a>]</span> describes a Connectivity Provisioning
      Profile (CPP) template to capture connectivity requirements to be met by
      a transport infrastructure for the delivery of various services such as
      Voice over IP (VoIP), IPTV, and Virtual Private Network (VPN) services
      <span>[<a href="#RFC4026" class="xref">RFC4026</a>]</span>. The CPP document defines the set of IP
      transfer parameters that reflect the guarantees that can be provided by
      the underlying transport network together with reachability scope and
      capacity needs. CPNP uses the CPP template to encode connectivity
      provisioning clauses that are subject to negotiation. The accepted CPP
      will then be passed to other functional elements that are responsible
      for the actual service activation and provisioning. For example, 
      Network Configuration Protocol (NETCONF)
      <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span> or RESTCONF 
      <span>[<a href="#RFC8040" class="xref">RFC8040</a>]</span> 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
      provisioning actions is out of scope of this document.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">As a reminder, several proposals have been made in the past by the
      (research) community (e.g., Common Open Policy Service protocol for 
      supporting Service Level Specification <span>[<a href="#I-D.nguyen-rap-cops-sls" class="xref">COPS-SLS</a>]</span>, Service Negotiation Protocol
      <span>[<a href="#SrNP" class="xref">SrNP</a>]</span>, Dynamic Service Negotiation
      Protocol <span>[<a href="#I-D.itsumo-dsnp" class="xref">DSNP</a>]</span>, Resource
      Negotiation and Pricing Protocol <span>[<a href="#RNAP" class="xref">RNAP</a>]</span>,
      Service Negotiation and Acquisition Protocol <span>[<a href="#SNAP" class="xref">SNAP</a>]</span>). 
      CPNP leverages the authors' experience
      with SrNP by separating the negotiation primitives from the service
      under negotiation. Moreover, careful examination of the other proposals
      revealed certain deficiencies that were easier to address through the
      creation of a new protocol rather than the modification of existing protocols. For
      example:<a href="#section-1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-5.1">COPS-SLS relies upon the COPS usage for policy provisioning (COPS-PR) <span>[<a href="#RFC3084" class="xref">RFC3084</a>]</span>,
          which is a Historic RFC.<a href="#section-1-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-5.2">DSNP is tightly designed with one specific service in mind (QoS)
          and does not make any distinction between a quotation phase and the
          actual service-ordering phase.<a href="#section-1-5.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-6">One of the primary motivations of this document is to provide a
      permanent reference to exemplify how service negotiation can be
      automated.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">Implementation details are out of scope. An example of required
      modules and interfaces to implement this specification is sketched in
      Section 4 of <span>[<a href="#AGAVE" class="xref">AGAVE</a>]</span>. This specification builds on
      that effort.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">This document makes use of the following terms:<a href="#section-2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2-2">
        <dt id="section-2-2.1">Customer:</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.2">
          <p id="section-2-2.2.1">Is a business role that denotes an entity
          that is involved in the definition and the possible negotiation of
          an order, including a Connectivity Provisioning Agreement, with a
          Provider. A connectivity provisioning document is captured in a
          dedicated CPP template-based document, which may specify (among
          other information) the sites to be connected, border nodes,
          outsourced operations (e.g., routing, traffic steering).<a href="#section-2-2.2.1" class="pilcrow">¶</a></p>
<p id="section-2-2.2.2">The right to invoke the subscribed service may be
          delegated by the Customer to third-party end users or brokering
          services.<a href="#section-2-2.2.2" class="pilcrow">¶</a></p>
<p id="section-2-2.2.3">A Customer can be a Service
          Provider, an application owner, an enterprise, a user, etc.<a href="#section-2-2.2.3" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.3">Network Provider (or Provider):</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.4">
          <p id="section-2-2.4.1">Owns and administers
          one or many transport domain(s) (typically Autonomous Systems (ASes))
          composed of (IP) switching and transmission resources (e.g.,
          routing, switching, forwarding, etc.). Network Providers are
          responsible for delivering and operating connectivity services
          (e.g., offering global or restricted reachability at specific
          rates). Offered connectivity services may not necessarily be
          restricted to IP.<a href="#section-2-2.4.1" class="pilcrow">¶</a></p>
<p id="section-2-2.4.2">The policies to be
          enforced by the connectivity service delivery components can be
          derived from the technology-specific clauses that might be included
          in agreements with the Customers. If no such clauses are included in
          the agreement, the mapping between the connectivity requirements and
          the underlying technology-specific policies to be enforced is
          deployment specific.<a href="#section-2-2.4.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.5">Quotation Order:</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.6">Denotes a request made by the
          Customer to the Provider that includes a set of requirements. The
          Customer may express its service-specific requirements by assigning
          (strictly or loosely defined) values to the information items
          included in the commonly understood template (e.g., CPP template)
          describing the offered service. These requirements constitute the
          parameters to be mutually agreed upon.<a href="#section-2-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.7">Offer:</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.8">
          <p id="section-2-2.8.1">Refers to a response made by the Provider to a
          Customer's quotation order that describes the ability of the
          Provider to satisfy the order at the time of its receipt. Offers
          reflect the capability of the Provider in accommodating received
          Customer orders beyond monolithic 'yes/no' answers.<a href="#section-2-2.8.1" class="pilcrow">¶</a></p>
<p id="section-2-2.8.2">An offer may fully or partially meet the
          requirements of the corresponding order. In the latter case, it may
          include alternative suggestions that the Customer may take into
          account by issuing a new order.<a href="#section-2-2.8.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.9">Agreement:</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.10">Refers to an order placed by the Customer
          and accepted by the Provider. It signals the successful conclusion
          of a negotiation cycle.<a href="#section-2-2.10" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
</section>
<div id="fe">
<section id="section-3">
      <h2 id="name-cpnp-functional-elements">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-cpnp-functional-elements" class="section-name selfRef">CPNP Functional Elements</a>
      </h2>
<p id="section-3-1">The following functional elements are defined:<a href="#section-3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3-2">
        <dt id="section-3-2.1">CPNP client (or client): </dt>
        <dd style="margin-left: 1.5em" id="section-3-2.2">
          <p id="section-3-2.2.1">Denotes a software instance
          that sends CPNP requests and receives CPNP responses. The current
          operations that can be performed by a CPNP client are listed
          below:<a href="#section-3-2.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-2.2.2">
            <li id="section-3-2.2.2.1">Create a quotation order (<a href="#provision" class="xref">Section 9.2.1</a>).<a href="#section-3-2.2.2.1" class="pilcrow">¶</a>
</li>
            <li id="section-3-2.2.2.2">Cancel an ongoing quotation order under negotiation (<a href="#cancel" class="xref">Section 9.2.7</a>).<a href="#section-3-2.2.2.2" class="pilcrow">¶</a>
</li>
            <li id="section-3-2.2.2.3">Accept an offer made by a server (<a href="#accept" class="xref">Section 9.2.4</a>).<a href="#section-3-2.2.2.3" class="pilcrow">¶</a>
</li>
            <li id="section-3-2.2.2.4">Withdraw an agreement (<a href="#with" class="xref">Section 9.2.8</a>).<a href="#section-3-2.2.2.4" class="pilcrow">¶</a>
</li>
            <li id="section-3-2.2.2.5">Update an agreement (<a href="#upd" class="xref">Section 9.2.9</a>).<a href="#section-3-2.2.2.5" class="pilcrow">¶</a>
</li>
          </ol>
</dd>
        <dd class="break"></dd>
<dt id="section-3-2.3">CPNP server (or server):</dt>
        <dd style="margin-left: 1.5em" id="section-3-2.4">
          <p id="section-3-2.4.1">Denotes a software instance
          that receives CPNP requests and sends back CPNP responses
          accordingly. The CPNP server is responsible for the following
          operations:<a href="#section-3-2.4.1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-2.4.2">
            <li id="section-3-2.4.2.1">Process a quotation order (<a href="#proc" class="xref">Section 9.2.2</a>).<a href="#section-3-2.4.2.1" class="pilcrow">¶</a>
</li>
            <li id="section-3-2.4.2.2">Make an offer (<a href="#offer" class="xref">Section 9.2.3</a>).<a href="#section-3-2.4.2.2" class="pilcrow">¶</a>
</li>
            <li id="section-3-2.4.2.3">Cancel an ongoing quotation order (<a href="#sordu" class="xref">Section 11.2.3</a>).<a href="#section-3-2.4.2.3" class="pilcrow">¶</a>
</li>
            <li id="section-3-2.4.2.4">Process an order withdrawal (<a href="#sordu" class="xref">Section 11.2.3</a>).<a href="#section-3-2.4.2.4" class="pilcrow">¶</a>
</li>
          </ol>
</dd>
      <dd class="break"></dd>
</dl>
</section>
</div>
<div id="opm">
<section id="section-4">
      <h2 id="name-order-processing-models">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-order-processing-models" class="section-name selfRef">Order Processing Models</a>
      </h2>
<p id="section-4-1">For preparing their service orders, Customers may need to be aware of
      the offered services. Therefore, Providers should first proceed with the
      announcement (or the exposure) of the services they can provide. The
      service announcement process may take place at designated global or
      Provider-specific service markets or through explicit interactions with
      the Providers. The details of this process are outside the scope of this
      document.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">With or without such service announcement/exposure mechanisms in
      place, the following order processing models can be distinguished:<a href="#section-4-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-4-3">
        <dt id="section-4-3.1">Frozen model:</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.2">The Customer
          cannot actually negotiate the parameters of the service(s) offered
          by a Provider. After consulting the Provider's service portfolio,
          the Customer selects the service offer to which he or she wants to subscribe and
          places an order to the Provider. Order handling is quite simple on
          the Provider side because the service is not customized per
          Customer's requirements, but rather designed to address a
          Customer base that shares the same requirements (i.e., these
          Customers share the same Connectivity Provisioning Profile). This mode
          can be implemented using existing tools such as <span>[<a href="#RFC8309" class="xref">RFC8309</a>]</span>.<a href="#section-4-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-3.3">Negotiation-based model:</dt>
        <dd style="margin-left: 1.5em" id="section-4-3.4">Unlike the frozen model, the Customer documents
          his/her requirements in a request for a quotation, which is then
          sent to one or several Providers. Solicited Providers check whether
          they can address these requirements or not, and get back to the
          Customer accordingly, possibly with an offer that may not exactly
          match the Customer's requirements (e.g., a 100 Mbps connection cannot be
          provisioned given the amount of available resources, but an 80 Mbps
          connection can be provided). A negotiation between the Customer and
          the Provider(s) then follows until both parties reach an agreement
          (or do not).<a href="#section-4-3.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-4">Both frozen and negotiation-based models require the existence of
      appropriate service templates like a CPP template and their
      instantiation for expressing specific offerings from Providers and
      service requirements from Customers, respectively. CPNP can be used in
      either model for automating the required Customer-Provider interactions.
      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
      'yes/no' answers but also counterproposals may be offered
      by the Provider in response to Customer orders.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">Order processing management on the Network Provider's side usually
      solicits features supported by the following functional blocks:<a href="#section-4-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-6.1">Network provisioning (including order activation, Network
          Planning, etc.)<a href="#section-4-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-6.2">Authentication, authorization, and accounting (AAA)<a href="#section-4-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-6.3">Network and service management (performance measurement and
          assessment, fault detection, etc.)<a href="#section-4-6.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-6.4">Sales-related functional blocks (e.g., billing, invoice
          validation)<a href="#section-4-6.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-6.5">Network impact analysis<a href="#section-4-6.5" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-7">CPNP does not assume any specific knowledge about these functional
      blocks, drawing an explicit line between protocol operation and the
      logic for handling connectivity provisioning requests. An order
      processing logic is typically fed with the information manipulated by
      the aforementioned functional blocks. For example, the resources that
      can be allocated to accommodate the Customer's requirements may depend on
      network availability estimates as calculated by the planning functions
      and related policies, as well as the number of orders to be processed
      simultaneously over a given period of time.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">This document does not elaborate on how Customers are identified and
      subsequently managed by the Provider's information system.<a href="#section-4-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="suc">
<section id="section-5">
      <h2 id="name-sample-use-cases">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-sample-use-cases" class="section-name selfRef">Sample Use Cases</a>
      </h2>
<p id="section-5-1">A non-exhaustive list of CPNP use cases is provided below:<a href="#section-5-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5-2">
        <li id="section-5-2.1">
          <p id="section-5-2.1.1"><span>[<a href="#RFC4176" class="xref">RFC4176</a>]</span> introduces the Layer 3 VPN (L3VPN)
          Service Order Management functional block, which is responsible for
          managing the requests initiated by the Customers and tracks the
          status of the completion of the related operations. CPNP can be used
          between the Customer and the Provider to negotiate L3VPN service
          parameters.<a href="#section-5-2.1.1" class="pilcrow">¶</a></p>
<p id="section-5-2.1.2">A CPNP server could therefore
          be part of the L3VPN Service Order Management functional block
          discussed in <span>[<a href="#RFC4176" class="xref">RFC4176</a>]</span>. A L3VPN Service YANG
          data model (L3SM) is defined in <span>[<a href="#RFC8299" class="xref">RFC8299</a>]</span>. Once
          an agreement is reached, the service can be provisioned using, e.g.,
          the L3VPN Network YANG data model specified in <span>[<a href="#I-D.ietf-opsawg-l3sm-l3nm" class="xref">L3VPN-NETWORK-YANG</a>]</span>.<a href="#section-5-2.1.2" class="pilcrow">¶</a></p>
<p id="section-5-2.1.3">Likewise, a CPNP server could be part of the Layer
          2 VPN (L2VPN) Service Order Management functional block. A YANG data
          model for L2VPN service delivery is defined in <span>[<a href="#RFC8466" class="xref">RFC8466</a>]</span>. Once an agreement is reached, the L2VPN
          service can be provisioned using, e.g., the L2VPN Network YANG data model
          specified in <span>[<a href="#I-D.ietf-opsawg-l2nm" class="xref">L2VPN-NETWORK-YANG</a>]</span>.<a href="#section-5-2.1.3" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-2.2">
          <p id="section-5-2.2.1">CPNP can be used between two adjacent domains to deliver IP
          interconnection services (e.g., enable, update, disconnect). For
          example, two Autonomous Systems (ASes) can be connected via several
          interconnection points. CPNP can be used between these ASes to
          upgrade existing links, request additional resources, provision a
          new interconnection point, etc.<a href="#section-5-2.2.1" class="pilcrow">¶</a></p>
<p id="section-5-2.2.2">See, for
          example, the framework documented in <span>[<a href="#ETICS" class="xref">ETICS</a>]</span>.<a href="#section-5-2.2.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-2.3">An integrated Provider can use CPNP to rationalize connectivity
          provisioning needs related to its service portfolio. A CPNP server
          function is used by network operations teams. A CPNP interface to
          trigger CPNP negotiation cycles is exposed to service management
          teams.<a href="#section-5-2.3" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.4">
          <p id="section-5-2.4.1">Service Providers can use CPNP to initiate connectivity
          provisioning requests towards a number of Network Providers so as to
          optimize the cost of delivering their services. Although multiple
          CPNP ordering cycles can be initiated by a Service Provider towards
          multiple Network Providers, a subset of these orders may actually be
          put into effect.<a href="#section-5-2.4.1" class="pilcrow">¶</a></p>
<p id="section-5-2.4.2">For example, a cloud
          Service Provider can use CPNP to request more resources from Network
          Providers.<a href="#section-5-2.4.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-2.5">CPNP can also be used in the context of network slicing 
          <span>[<a href="#I-D.geng-netslices-architecture" class="xref">NETSLICES-ARCH</a>]</span> to request network
          resources together with a set of requirements that need to be
          satisfied by the Provider. Such requirements are not restricted to
          basic IP forwarding capabilities, but may also include a
          characterization of a set of service functions that may be invoked.
          For the network slicing case, the instances of a CPP template could
          be derived from the network slice template documented in
          <span>[<a href="#I-D.contreras-teas-slice-nbi" class="xref">TEAS-SLICE-NBI</a>]</span>.<a href="#section-5-2.5" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.6">
          <p id="section-5-2.6.1">CPNP can be used in Machine-to-Machine (M2M) environments to
          dynamically subscribe to M2M services (e.g., access data
          retrieved by a set of sensors, extend sensor coverage, etc.).<a href="#section-5-2.6.1" class="pilcrow">¶</a></p>
<p id="section-5-2.6.2">Also, Internet of Things (IoT) <span>[<a href="#RFC6574" class="xref">RFC6574</a>]</span> 
          domains may rely on CPNP to enable dynamic
          access to data produced by involved objects, according to their
          specific policies, to various external stakeholders such as data
          analytics and business intelligence companies. Direct CPNP-based
          interactions between IoT domains and interested parties enable open
          access to diverse sets of data across the Internet, e.g., from
          multiple types of sensors, user groups, and/or geographical
          areas.<a href="#section-5-2.6.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-2.7">CPNP can be used in the context of Interface to Network Security Functions 
         (I2NSF) <span>[<a href="#RFC8329" class="xref">RFC8329</a>]</span> 
          to capture the Customer-driven policies to
          be enforced by a set of Network Security Functions.<a href="#section-5-2.7" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.8">
          <p id="section-5-2.8.1">A Provider offering cloud services can expose a CPNP interface to
          allow Customers to dynamically negotiate typical data center
          resources, such as additional storage, processing and networking
          resources, enhanced security filters, etc.<a href="#section-5-2.8.1" class="pilcrow">¶</a></p>
<p id="section-5-2.8.2">Cloud computing Providers typically structure their
          computation service offerings by bundling CPU, RAM, and storage
          units as quotas, instances, or flavors that can be consumed in an
          ephemeral or temporal fashion during the lifetime of the required
          function. A similar approach is followed by CPNP (see for example,
          <a href="#activate" class="xref">Section 9.2.11</a>).<a href="#section-5-2.8.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-5-2.9">In the inter-cloud context (also called cloud of clouds or cloud
          federation), CPNP can be used to reserve computing and networking
          resources hosted by various cloud infrastructures.<a href="#section-5-2.9" class="pilcrow">¶</a>
</li>
        <li id="section-5-2.10">
          <p id="section-5-2.10.1">CDN Providers can use CPNP to extend their footprint by
          interconnecting their respective CDN infrastructures <span>[<a href="#RFC6770" class="xref">RFC6770</a>]</span> (see <a href="#cdni" class="xref">Figure 1</a>).<a href="#section-5-2.10.1" class="pilcrow">¶</a></p>
<span id="name-cdn-interconnection"></span><div id="cdni">
<figure id="figure-1">
            <div class="artwork art-text alignCenter" id="section-5-2.10.2.1">
<pre>
       ,--,--,--.             ,--,--,--.
    ,-'          `-.       ,-'          `-.
   (CDN Provider 'A')=====(CDN Provider 'B')
    `-.  (CDN-A) ,-'       `-. (CDN-B)  ,-'
      `--'--'--'             `--'--'--'
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-cdn-interconnection" class="selfRef">CDN Interconnection</a>
            </figcaption></figure>
</div>
</li>
        <li id="section-5-2.11">
          <p id="section-5-2.11.1">Mapping Service Providers (MSPs) <span>[<a href="#RFC7215" class="xref">RFC7215</a>]</span>
          can use CPNP to enrich their mapping database by interconnecting
          their mapping system (see <a href="#map" class="xref">Figure 2</a>). This
          interconnection allows the relaxation of the constraints on PxTR (Proxy
          Ingress/Egress Tunnel Router) in favour of native LISP (Locator/ID
          Separation Protocol) forwarding <span>[<a href="#RFC6830" class="xref">RFC6830</a>]</span>.
          Also, it prevents the fragmentation of the LISP mapping database. A
          framework is described in <span>[<a href="#I-D.boucadair-lisp-idr-ms-discovery" class="xref">LISP-MS-DISCOVERY</a>]</span>.<a href="#section-5-2.11.1" class="pilcrow">¶</a></p>
<span id="name-lisp-mapping-system-interco"></span><div id="map">
<figure id="figure-2">
            <div class="artwork art-text alignCenter" id="section-5-2.11.2.1">
<pre>
       ,--,--,--.             ,--,--,--.
    ,-'          `-.       ,-'          `-.
   (Mapping System 'A')===(Mapping System 'B')
    `-.          ,-'       `-.           ,-'
       `--'--'--'             `--'--'--'
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-lisp-mapping-system-interco" class="selfRef">LISP Mapping System Interconnect</a>
            </figcaption></figure>
</div>
</li>
        <li id="section-5-2.12">CPNP may also be used between SDN (Software-Defined Networking)
          controllers in contexts where Cooperating Layered Architecture for
          Software-Defined Networking (CLAS) is enabled <span>[<a href="#RFC8597" class="xref">RFC8597</a>]</span>.<a href="#section-5-2.12" class="pilcrow">¶</a>
</li>
      </ol>
</section>
</div>
<div id="dm">
<section id="section-6">
      <h2 id="name-cpnp-deployment-models">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-cpnp-deployment-models" class="section-name selfRef">CPNP Deployment Models</a>
      </h2>
<p id="section-6-1">Several CPNP deployment models can be envisaged. Two examples are
      listed below:<a href="#section-6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.1">The Customer deploys a CPNP client while one or several CPNP
          servers are deployed by the Provider. A CPNP client can discover its
          CPNP servers using a variety of means (static, dynamic, etc.).<a href="#section-6-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.2">The Customer does not enable any CPNP client. The Provider
          maintains a Customer Order Management portal. The Customer can
          initiate connectivity provisioning quotation orders via the portal;
          appropriate CPNP messages are then generated and sent to the
          relevant CPNP server. In this model, both the CPNP client and CPNP
          server are under the responsibility of the same administrative
          entity (i.e., Network Provider).<a href="#section-6-2.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-3">Once the negotiation of connectivity provisioning parameters is
      successfully concluded, that is, an order has been placed by the
      Customer, the actual network provisioning operations are initiated. The
      specification of related dynamic resource allocation and policy
      enforcement schemes, as well as how CPNP servers interact with the
      network provisioning functional blocks on the Provider side, are out of the
      scope of this document.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">This document does not make any assumptions about the CPNP deployment
      model either.<a href="#section-6-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cnm">
<section id="section-7">
      <h2 id="name-cpnp-negotiation-model">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-cpnp-negotiation-model" class="section-name selfRef">CPNP Negotiation Model</a>
      </h2>
<p id="section-7-1">CPNP runs between a Customer and a Provider, carrying service orders
      from the Customer and corresponding responses from the Provider in 
      order to reach a service provisioning agreement. As the services
      offered by the Provider are well described, by means of the CPP template
      for connectivity matters, the negotiation process is essentially a
      value-settlement process, where an agreement is pursued on the values of
      the commonly understood information items (service parameters) included
      in the service description template (<a href="#service_template" class="xref">Section 9.1.9</a>).<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">The content that CPNP carries and the negotiation logic invoked 
      at Customer and Provider sides to manipulate the content (i.e., 
      the information carried in CPNP messages to proceed with the 
      negotiation) is transparent to the protocol.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">The protocol aims to facilitate the execution of the negotiation
      logic by providing the required generic communication primitives.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">Since negotiations are initiated and primarily driven by 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
      approach is adopted for not overloading the protocol with additional
      messages. In particular, the acceptance of an offer made by the Provider
      signals a call for agreement from the Customer. Note that it is almost
      certain the Provider will accept this call since it refers to an offer
      that the Provider made. Of course, at any point the Provider or the Customer
      may quit the negotiations, each on its own grounds.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">Based on the above, CPNP adopts a quotation order/offer/answer model,
      which proceeds through the following basic steps (<a href="#service_variants" class="xref">Figure 3</a>):<a href="#section-7-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7-6">
        <li id="section-7-6.1">The CPNP client specifies its service requirements in a
          Provisioning Quotation Order (PQO). The order may include strictly or
          loosely defined values in the clauses describing service
          provisioning characteristics.<a href="#section-7-6.1" class="pilcrow">¶</a>
</li>
        <li id="section-7-6.2">The CPNP server declines the PQO, or makes an offer to address
          the requirements of the PQO, or suggests a counterproposal that
          partially addresses the requirements of the PQO in case specific
          requirements cannot be accommodated.<a href="#section-7-6.2" class="pilcrow">¶</a>
</li>
        <li id="section-7-6.3">The CPNP client either accepts or declines the offer. The acceptance 
          of the offer by the CPNP client implies a call for
   agreement and, thus, the
          agreement between both parties and the conclusion of the
          negotiation.<a href="#section-7-6.3" class="pilcrow">¶</a>
</li>
      </ol>
<span id="name-simplified-service-negotiat"></span><div id="service_variants">
<figure id="figure-3">
        <div class="artwork art-text alignCenter" id="section-7-7.1">
<pre>
+------+                     +------+
|Client|                     |Server|
+------+                     +------+
   |=====Requested Service=====&gt;|
   |&lt;=====Offered Service=======|
   |=====Accepted Service======&gt;|
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-simplified-service-negotiat" class="selfRef">Simplified Service Negotiation</a>
        </figcaption></figure>
</div>
<p id="section-7-8">Multiple instances of CPNP may run at a Customer's or a Provider's
      domains. A CPNP client may be engaged in multiple, simultaneous
      negotiations with the same or different CPNP servers (parallel
      negotiations, see <a href="#mser" class="xref">Section 8.10</a>), and a CPNP server may
      need to negotiate with other Provider(s) as part of negotiations that
      are ongoing with a CPNP client (cascaded negotiations, see <a href="#cascaded" class="xref">Section 8.8</a>).<a href="#section-7-8" class="pilcrow">¶</a></p>
<p id="section-7-9">CPNP relies on various timers to run its operations. Two types of
      timers are defined: those that are specific to CPNP message transmission
      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
      sides, particularly in cases where the CPNP client is involved in
      parallel negotiations with several CPNP servers or in cases where the
      CPNP server is, in turn, involved in negotiations with other Providers for
      processing a given Customer-originated quotation order. CPNP allows a
      CPNP server to request extra time to proceed with the negotiation.
      This request may be accepted or rejected by the CPNP client.<a href="#section-7-9" class="pilcrow">¶</a></p>
<p id="section-7-10">Providers may need to publish available services to the Customers
      (see <a href="#opm" class="xref">Section 4</a>). CPNP may optionally support this
      functionality. Dedicated templates can be defined for the purpose of
      service announcement, which will be used by the CPNP clients to initiate
      their CPNP negotiation cycles.<a href="#section-7-10" class="pilcrow">¶</a></p>
<p id="section-7-11">For the sake of simplicity, a single offer/answer stage is assumed
      within one CPNP negotiation cycle. Nevertheless, as already stated,
      multiple CPNP negotiation cycles can be undertaken by a CPNP client (see
      <a href="#examples" class="xref">Figure 4</a>).<a href="#section-7-11" class="pilcrow">¶</a></p>
<p id="section-7-12">The model is flexible enough to accommodate changing conditions
      during the lifetime of a service (e.g., the introduction of an additional
      VPN site).<a href="#section-7-12" class="pilcrow">¶</a></p>
<span id="name-overall-negotiation-process"></span><div id="examples">
<figure id="figure-4">
        <div class="artwork art-text alignCenter" id="section-7-13.1">
<pre>
+------+                  +------+ +------+                  +------+
|Client|                  |Server| |Client|                  |Server|
+------+                  +------+ +------+                  +------+
   |=====Quotation Order=====&gt;|       |=====Quotation Order=====&gt;|
   |&lt;==========Offer==========|       |&lt;==========Offer==========|
   |===========Accept========&gt;|       |==========Decline========&gt;|

  1-Step Successful Negotiation         1-Step Failed Negotiation
            Cycle                               Cycle

+------+                  +------+ +------+                  +------+
|Client|                  |Server| |Client|                  |Server|
+------+                  +------+ +------+                  +------+
   |===Quotation Order(a)====&gt;|       |===Quotation Order(i)====&gt;|
   |&lt;==========Offer==========|       |&lt;==========Offer==========|
   |==========Decline========&gt;|       |==========Decline========&gt;|
   |===Quotation Order(b)====&gt;|       |===Quotation Order(j)====&gt;|
   |&lt;==========Offer==========|       |&lt;==========Offer==========|
   |===========Accept========&gt;|       |==========Decline========&gt;|
                                      |===Quotation Order(k)====&gt;|
                                      |&lt;==========Offer==========|
                                      |==========Decline========&gt;|
                                      |===Quotation Order(l)====&gt;|
                                      |&lt;==Fail to make an offer==|

    N-Step Negotiation Cycle:         N-Step Negotiation Cycle:
      Successful Negotiation              Failed Negotiation
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-overall-negotiation-process" class="selfRef">Overall Negotiation Process</a>
        </figcaption></figure>
</div>
<p id="section-7-14">The means used by a CPNP client to retrieve a list of active/accepted
      offers are not defined in this document.<a href="#section-7-14" class="pilcrow">¶</a></p>
<p id="section-7-15">An order can be implicitly or explicitly activated. 
      <span><a href="https://www.rfc-editor.org/rfc/rfc7297#section-3.11" class="relref">Section 3.11</a> of [<a href="#RFC7297" class="xref">RFC7297</a>]</span> specifies a dedicated clause called
      Activation Means. Such a clause indicates the required action(s) to be
      undertaken to activate access to the (IP connectivity) service. This
      document defines a dedicated CPNP message that can be used for explicit
      activation (<a href="#activate" class="xref">Section 9.2.11</a>).<a href="#section-7-15" class="pilcrow">¶</a></p>
</section>
</div>
<div id="po">
<section id="section-8">
      <h2 id="name-protocol-overview">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-protocol-overview" class="section-name selfRef">Protocol Overview</a>
      </h2>
<section id="section-8.1">
        <h3 id="name-client-server-communication">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-client-server-communication" class="section-name selfRef">Client/Server Communication</a>
        </h3>
<p id="section-8.1-1">CPNP is a client/server protocol that can run over any transport
        protocol. The default transport mode is UDP secured with Datagram
        Transport Layer Security (DTLS) <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span>. No
        permanent CPNP transport session needs to be maintained between the
        client and the server.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">The CPNP client can be configured with the CPNP server(s).
        Typically, the CPNP client is configured with an IP address together 
        with a port number using manual or dynamic configuration means
        (e.g., DHCP). Alternatively, a Provider may advertise the port number
        (CPNP_PORT) it uses to bind the CPNP service using SRV <span>[<a href="#RFC2782" class="xref">RFC2782</a>]</span>.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<p id="section-8.1-3">The CPNP client may be provided with a domain name of the CPNP
        server for PKIX-based authentication purposes. CPNP servers should
        prefer the use of DNS-ID and SRV-ID over CN-ID identifier types in
        certificate requests (<span><a href="https://www.rfc-editor.org/rfc/rfc6125#section-2.3" class="relref">Section 2.3</a> of [<a href="#RFC6125" class="xref">RFC6125</a>]</span>).
        URI-IDs should not be used for CPNP server identity verification.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
<p id="section-8.1-4">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
        CPNP request sent to a CPNP server is used by the server to reply to
        that request.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
<p id="section-8.1-5">CPNP is independent of the IP address family.<a href="#section-8.1-5" class="pilcrow">¶</a></p>
<p id="section-8.1-6">CPNP retransmission for unreliable transports is discussed in 
        <a href="#retrans" class="xref">Section 11.4</a>.<a href="#section-8.1-6" class="pilcrow">¶</a></p>
<p id="section-8.1-7">Considerations related to mutual authentication are discussed in
        <a href="#Security" class="xref">Section 13</a>.<a href="#section-8.1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-8.2">
        <h3 id="name-policy-configuration-on-the">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-policy-configuration-on-the" class="section-name selfRef">Policy Configuration on the CPNP Server</a>
        </h3>
<p id="section-8.2-1">As an input to its decision-making process, the CPNP server may be
        connected to various external modules such as Customer Profiles,
        Network Topology, Network Resource Management, Order Repositories,
        AAA, and Network Provisioning Manager (an example is shown in <a href="#fb" class="xref">Figure 5</a>).<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">These external modules provide inputs to the CPNP server so that
        it can do the following:<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.2-3.1">Check whether a Customer is entitled to initiate a provisioning
            quotation request.<a href="#section-8.2-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.2-3.2">Check whether a Customer is entitled to cancel an ongoing
            order.<a href="#section-8.2-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.2-3.3">Check whether administrative data (e.g., billing-related
            information) have been verified before the processing of the
            request starts.<a href="#section-8.2-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.2-3.4">Check whether network capacity is available or additional
            capacity is required.<a href="#section-8.2-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.2-3.5">Receive guidelines from network design and sales blocks (e.g.,
            pricing, network usage levels, thresholds associated with the
            number of CPP templates that can be processed over a given period
            of time as a function of the nature of the service to be
            delivered, etc.).<a href="#section-8.2-3.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.2-3.6">Transfer completed orders to network provisioning blocks
            (referred to as "Network Provisioning Manager" in <a href="#fb" class="xref">Figure 5</a>). For example, the outcome of CPNP may be
            passed to modules such as Application-Based Network Operations
            (ABNO) <span>[<a href="#RFC7491" class="xref">RFC7491</a>]</span> or network controllers.
            These controllers will use protocols such as NETCONF <span>[<a href="#RFC6241" class="xref">RFC6241</a>]</span> to interact with the appropriate network
            nodes and functions for the sake of proper service activation and
            delivery.<a href="#section-8.2-3.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-8.2-4">The above list of CPNP server operations is not
        exhaustive.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
<span id="name-order-handling-management-f"></span><div id="fb">
<figure id="figure-5">
          <div class="artwork art-text alignCenter" id="section-8.2-5.1">
<pre>       . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
       .Business &amp; Administrative Management                   .
       .+------------------------++---------------------------+.
       .| Business Guidelines    ||    Billing &amp; Charging     |.
       .+-----------+------------++-----------+---------------+.
       .            |                         |                .
       .            +-------------------+     |                .
       . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
       . . . . . . . . . . . . . . . . .|. . .|. . . . . . . . .
       .Order Handling Management       |     |                .
       . +-------------------+  +-------+-----+--------------+ .
       . |Network Topology DB+--+        CPNP Server         | .
       . +-------------------+  +-+---+---+---+---+-----+----+ .
       .                          |   |   |   |   |     |      .
       . +------------------------+-+ |   |   |   |     |      .
       . |   Network Dimensioning   | |   |   |   |     |      .
       . |        &amp; Planning        | |   |   |   |     |      .
       . +--------------------------+ |   |   |   |     |      .
       . +----------------------------+-+ |   |   | +---+----+ .
       . |                              | |   |   | |   AAA  | .
       . |   Network       +------------+ |   |   | +--------+ .
       . |  Resource       | +------------+-+ | +-+----------+ .
       . |  Management     | |   Customer   | | |   Orders   | .
       . |                 | |   Profiles   | | | Repository | .
       . +-----------------+ +--------------+ | +------------+ .
       . . . . . . . . . . . . . . . . . . . .|. . . . . . . . .
       +--------------------------------------+----------------+
       |             Network Provisioning Manager              |
       +-------------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-order-handling-management-f" class="selfRef">Order Handling Management Functional Block (Focus on Internal Interfaces)</a>
          </figcaption></figure>
</div>
<p id="section-8.2-6">The following order-handling modes can also be configured on the
        server:<a href="#section-8.2-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.2-7">
          <dt id="section-8.2-7.1">Fully automated mode:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-7.2">This mode does not require any action
            from the administrator when receiving a request for a service. The
            server can execute its decision-making process related to the
            orders received and can generate corresponding offers.<a href="#section-8.2-7.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-7.3">Administrative validation checking:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-7.4">Some or all of the server's
            operations are subject to administrative validation procedures.
            This mode requires an action from the administrator for every
            request received. To that aim, the CPNP methods that can be
            automatically handled by the server (or are subject to one or
            several validation administrative checks) can be configured on the
            server.<a href="#section-8.2-7.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<div id="session">
<section id="section-8.3">
        <h3 id="name-cpnp-session-entries">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-cpnp-session-entries" class="section-name selfRef">CPNP Session Entries</a>
        </h3>
<p id="section-8.3-1">A CPNP session entry is represented by a tuple defined as follows:<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.3-2.1">Transport session (typically, the IP address of the CPNP client,
            the client's port number, the IP address of the CPNP server, and the CPNP
            server's port number).<a href="#section-8.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.3-2.2">Incremented sequence number (<a href="#sq_nu" class="xref">Section 11.3</a>).<a href="#section-8.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.3-2.3">Customer agreement identifier: This is a unique identifier
            assigned to the order under negotiation by the CPNP client (<a href="#cu_id" class="xref">Section 9.1.1</a>). This identifier is also used by the
            client to identify the agreement that will result from a
            successful negotiation.<a href="#section-8.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.3-2.4">Provider agreement identifier: This is a unique identifier
            assigned to the order under negotiation by the CPNP server (<a href="#pr_id" class="xref">Section 9.1.2</a>). This identifier is also used by the
            server to identify the agreement that will result from a
            successful negotiation.<a href="#section-8.3-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.3-2.5">Transaction-ID (<a href="#trans" class="xref">Section 8.4</a>).<a href="#section-8.3-2.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="trans">
<section id="section-8.4">
        <h3 id="name-cpnp-transactions">
<a href="#section-8.4" class="section-number selfRef">8.4. </a><a href="#name-cpnp-transactions" class="section-name selfRef">CPNP Transactions</a>
        </h3>
<p id="section-8.4-1">A CPNP transaction occurs between a client and a server for
        completing, modifying, or withdrawing a service agreement, and comprises
        all CPNP messages exchanged between the client and the server, from
        the first request sent by the client to the final response sent by the
        server. A CPNP transaction is bound to a CPNP session (<a href="#session" class="xref">Section 8.3</a>).<a href="#section-8.4-1" class="pilcrow">¶</a></p>
<p id="section-8.4-2">Because multiple CPNP transactions can be maintained by the CPNP
        client, the client must assign an identifier to uniquely identify a
        given transaction. This identifier is the Transaction-ID.<a href="#section-8.4-2" class="pilcrow">¶</a></p>
<p id="section-8.4-3">The Transaction-ID must be randomly assigned by the CPNP client,
        according to the best current practice for generating random numbers
        <span>[<a href="#RFC4086" class="xref">RFC4086</a>]</span> that cannot be guessed easily.
        The Transaction-ID is used for validating CPNP responses received by the
        client.<a href="#section-8.4-3" class="pilcrow">¶</a></p>
<p id="section-8.4-4">In the context of a transaction, the client needs to 
        select a sequence number randomly and then needs to assign it to the first CPNP message to
        send. This number is then incremented for each request message that is
        subsequently sent within the ongoing CPNP transaction (see <a href="#sq_nu" class="xref">Section 11.3</a>).<a href="#section-8.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="timers">
<section id="section-8.5">
        <h3 id="name-cpnp-timers">
<a href="#section-8.5" class="section-number selfRef">8.5. </a><a href="#name-cpnp-timers" class="section-name selfRef">CPNP Timers</a>
        </h3>
<p id="section-8.5-1">CPNP adopts a simple retransmission procedure that relies on a
        retransmission timer represented by RETRANS_TIMER and a maximum retry
        threshold. The use of RETRANS_TIMER and a maximum retry threshold are
        described in <a href="#behavior" class="xref">Section 11</a>.<a href="#section-8.5-1" class="pilcrow">¶</a></p>
<p id="section-8.5-2">The response timer (EXPECTED_RESPONSE_TIME) is set by the client to
        denote the time, in seconds, the client will wait to receive a
        response from the server to a PQO request
        (see <a href="#extime" class="xref">Section 9.1.6</a>). If the timer expires, the
        respective PQO is cancelled by the client, and a CANCEL
        message is generated accordingly.<a href="#section-8.5-2" class="pilcrow">¶</a></p>
<p id="section-8.5-3">The expected offer timer (EXPECTED_OFFER_TIME) is set by the server
        to indicate the time by when the CPNP server is expected to make an
        offer to the CPNP client (see <a href="#EXPECTED_OFFER_TIME" class="xref">Section 9.1.7</a>). If no offer is received by
        then, the CPNP client will consider the order as rejected.<a href="#section-8.5-3" class="pilcrow">¶</a></p>
<p id="section-8.5-4">An offer expiration timer (VALIDITY_OFFER_TIME) is set by the
        server to represent the time, in minutes, after which an offer made by
        the server becomes invalid (see <a href="#valtime" class="xref">Section 9.1.8</a>).<a href="#section-8.5-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8.6">
        <h3 id="name-cpnp-operations">
<a href="#section-8.6" class="section-number selfRef">8.6. </a><a href="#name-cpnp-operations" class="section-name selfRef">CPNP Operations</a>
        </h3>
<p id="section-8.6-1">CPNP operations are listed below. They may be augmented depending
        on the nature of some transactions or because of security
        considerations that may necessitate a distinct CPNP client/server
        authentication phase before negotiation begins.<a href="#section-8.6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-8.6-2">
          <dt id="section-8.6-2.1">QUOTATION (<a href="#provision" class="xref">Section 9.2.1</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.2">This operation is used by the client to initiate
            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
            FAIL message.<a href="#section-8.6-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.3">PROCESSING (<a href="#proc" class="xref">Section 9.2.2</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.4">This operation is used to inform the remote party
            that its message (the order quotation or the offer) was
            received and it is being processed. This message can also be issued by
            the server to request more time, in which case, the client may
            reply with an ACK or FAIL message depending on whether extra time
            can or cannot be granted.<a href="#section-8.6-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.5">OFFER (<a href="#offer" class="xref">Section 9.2.3</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.6">This operation is used by the server to inform
            the client about an offer that can best accommodate the
            requirements indicated in the previously received QUOTATION
            message.<a href="#section-8.6-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.7">ACCEPT (<a href="#accept" class="xref">Section 9.2.4</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.8">This operation is used by the client to confirm
            the acceptance of an offer made by the server. This message
            implies a call for agreement. An agreement is reached when an ACK
            is subsequently received from the server, which is likely to
            happen if the message is sent before the offer validity time
            expires; the server is unlikely to reject an offer that it has
            already made.<a href="#section-8.6-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.9">DECLINE (<a href="#dec" class="xref">Section 9.2.5</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.10">This operation is used by the client to reject an
            offer made by the server. The ongoing transaction may not be
            terminated immediately, e.g., the client may issue another order
            or the server may issue another offer.<a href="#section-8.6-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.11">ACK (<a href="#ack" class="xref">Section 9.2.6</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.12">This
            operation is used by the server to acknowledge the receipt of an
            ACCEPT or WITHDRAW message or by the client to confirm the server's 
            request for a time extension (conveyed in a PROCESSING message) 
            in order to process the last received quotation order.<a href="#section-8.6-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.13">CANCEL (<a href="#cancel" class="xref">Section 9.2.7</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.14">This operation is used by the client to cancel
            (quit) the ongoing transaction.<a href="#section-8.6-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.15">WITHDRAW (<a href="#with" class="xref">Section 9.2.8</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.16">This operation is used by the client to withdraw
            a completed order (i.e., an agreement).<a href="#section-8.6-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.17">UPDATE (<a href="#upd" class="xref">Section 9.2.9</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.18">This operation is used by the client to update an
            existing agreement. For example, this method can be invoked to add
            a new VPN site. This method will trigger a new negotiation
            cycle.<a href="#section-8.6-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.6-2.19">FAIL (<a href="#fail" class="xref">Section 9.2.10</a>): </dt>
          <dd style="margin-left: 1.5em" id="section-8.6-2.20">
            <p id="section-8.6-2.20.1">This operation is used by the server to indicate
            that it cannot accommodate the requirements documented in the PQO
            conveyed in the QUOTATION message or to inform the client about an
            error encountered when processing the received message. In either
            case, the message implies that the server is unable to make offers,
            and, as a consequence, it terminates the ongoing transaction.<a href="#section-8.6-2.20.1" class="pilcrow">¶</a></p>
<p id="section-8.6-2.20.2">This message is also used by the client
            to reject a time extension request in a PROCESSING message received 
            from the server. The message includes a status code that 
            provides explanatory information.<a href="#section-8.6-2.20.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.6-3">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.<a href="#section-8.6-3" class="pilcrow">¶</a></p>
<p id="section-8.6-4">The document defines the service objects that are required for
        connectivity provisioning negotiation purposes 
        (see <a href="#cpd" class="xref">Section 8.7</a>). 
        Additional service-specific objects for CPNP messages to accommodate alternative
        deployment schemes or other service provisioning needs can be 
        defined in the future.<a href="#section-8.6-4" class="pilcrow">¶</a></p>
</section>
<div id="cpd">
<section id="section-8.7">
        <h3 id="name-connectivity-provisioning-d">
<a href="#section-8.7" class="section-number selfRef">8.7. </a><a href="#name-connectivity-provisioning-d" class="section-name selfRef">Connectivity Provisioning Documents</a>
        </h3>
<p id="section-8.7-1">CPNP makes use of several flavors of Connectivity Provisioning
        Documents (CPD). These documents follow the same CPP template
        described in <span>[<a href="#RFC7297" class="xref">RFC7297</a>]</span>.<a href="#section-8.7-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-8.7-2">
          <dt id="section-8.7-2.1">Requested CPD: </dt>
          <dd style="margin-left: 1.5em" id="section-8.7-2.2">Refers
            to the CPD included by a CPNP client in a QUOTATION request.<a href="#section-8.7-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.7-2.3">Offered CPD: </dt>
          <dd style="margin-left: 1.5em" id="section-8.7-2.4">This
            document is included by a CPNP server in an OFFER message. Its
            information reflects the proposal of the server to accommodate all
            or a subset of the clauses depicted in a Requested CPD. A validity
            time is associated with the offer made.<a href="#section-8.7-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.7-2.5">Accepted CPD: </dt>
          <dd style="margin-left: 1.5em" id="section-8.7-2.6">If
            the client accepts an offer made by the server, the Offered CPD is
            included in an ACCEPT message. This CPD is also included in an ACK
            message. Thus, a three-way handshake procedure is followed for
            successfully completing the negotiation.<a href="#section-8.7-2.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.7-3"><a href="#example" class="xref">Figure 6</a> shows a typical CPNP negotiation
        cycle and the use of the different types of CPDs.<a href="#section-8.7-3" class="pilcrow">¶</a></p>
<span id="name-connectivity-provisioning-do"></span><div id="example">
<figure id="figure-6">
          <div class="artwork art-text alignCenter" id="section-8.7-4.1">
<pre>
+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |======QUOTATION (Requested CPD)=====&gt;|
   |&lt;============PROCESSING==============|
   |&lt;========OFFER (Offered CPD)=========|
   |=============PROCESSING=============&gt;|
   |=======ACCEPT (Accepted CPD)========&gt;|
   |&lt;=======ACK (Accepted CPD)===========|
   |                                     |
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-connectivity-provisioning-do" class="selfRef">Connectivity Provisioning Documents</a>
          </figcaption></figure>
</div>
<p id="section-8.7-5">A CPD can include parameters with fixed values,
        loosely defined values, or any combination thereof. A CPD 
        is said to be concrete if all clauses have fixed values.<a href="#section-8.7-5" class="pilcrow">¶</a></p>
<p id="section-8.7-6">A typical evolution of a negotiation cycle would start with a
        quotation order with loosely defined parameters, and then, as offers
        are made, it would conclude with a concrete CPD for
        calling for the agreement.<a href="#section-8.7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cascaded">
<section id="section-8.8">
        <h3 id="name-child-pqos">
<a href="#section-8.8" class="section-number selfRef">8.8. </a><a href="#name-child-pqos" class="section-name selfRef">Child PQOs</a>
        </h3>
<p id="section-8.8-1">If the server detects that network resources from another Network
        Provider need to be allocated in order to accommodate the requirements
        described in a PQO (e.g., in the context of an inter-domain VPN
        service, additional Provider Edge (PE) router resources need to be allocated), the
        server may generate child PQOs to request the appropriate network
        provisioning operations (see <a href="#child" class="xref">Figure 7</a>). 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
        is implementation specific (e.g., this can be typically achieved by
        locally adding the reference of the child PQO to the parent
        order).<a href="#section-8.8-1" class="pilcrow">¶</a></p>
<span id="name-example-of-child-orders"></span><div id="child">
<figure id="figure-7">
          <div class="artwork art-text alignCenter" id="section-8.8-2.1">
<pre>
+------+            +--------+          +--------+
|Client|            |Server A|          |Server B|
+------+            +--------+          +--------+
   |                    |                    |
   |=====QUOTATION=====&gt;|                    |
   |&lt;====PROCESSING=====|                    |
   |                    |=====QUOTATION=====&gt;|
   |                    |&lt;====PROCESSING=====|
   |                    |&lt;=======OFFER=======|
   |                    |=====PROCESSING====&gt;|
   |                    |=======ACCEPT======&gt;|
   |                    |&lt;=======ACK=========|
   |&lt;=======OFFER=======|                    |
   |=====PROCESSING====&gt;|                    |
   |=======ACCEPT======&gt;|                    |
   |&lt;=======ACK=========|                    |
   |                    |                    |
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-example-of-child-orders" class="selfRef">Example of Child Orders</a>
          </figcaption></figure>
</div>
<p id="section-8.8-3">Note that the server must not activate recursion for an
        order if the client includes a negotiation option to restrict the
        negotiation scope to the resources of the server's domain (<a href="#nego" class="xref">Section 9.1.10.3</a>).<a href="#section-8.8-3" class="pilcrow">¶</a></p>
<p id="section-8.8-4">If recursion is not explicitly disabled, the server may notify the
        client when appropriate (<a href="#proc" class="xref">Section 9.2.2</a>). Such
        notification may depend on the nature of the service and also
        regulatory considerations.<a href="#section-8.8-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8.9">
        <h3 id="name-multi-segment-service">
<a href="#section-8.9" class="section-number selfRef">8.9. </a><a href="#name-multi-segment-service" class="section-name selfRef">Multi-Segment Service</a>
        </h3>
<p id="section-8.9-1">A composite service (e.g., connectivity) requested by a Customer
        could imply multi-segment services (e.g., multi-segment connectivity
        spanning an end-to-end scope), in the sense that one single CPNP
        request is decomposed into multiple connectivity requests on the Provider's
        side (thereby leading to child orders). The Provider is in charge of
        handling the complexity of splitting the generic provisioning order in
        a multi-segment context. Such complexity is local to the Provider.<a href="#section-8.9-1" class="pilcrow">¶</a></p>
</section>
<div id="mser">
<section id="section-8.10">
        <h3 id="name-negotiating-with-multiple-c">
<a href="#section-8.10" class="section-number selfRef">8.10. </a><a href="#name-negotiating-with-multiple-c" class="section-name selfRef">Negotiating with Multiple CPNP Servers</a>
        </h3>
<p id="section-8.10-1">A CPNP client may undertake multiple negotiations in parallel with
        several servers for various reasons, such as cost optimization and
        fail-safety. These multiple negotiations may lead to one or many
        agreements.<a href="#section-8.10-1" class="pilcrow">¶</a></p>
<p id="section-8.10-2">The salient point underlining the parallel negotiation scenarios is
        that, although the negotiation protocol is strictly between two
        parties, this may not be the case of the negotiation logic. The CPNP
        client negotiation logic may need to collectively drive parallel
        negotiations, as the negotiation with one server may affect the
        negotiation with other servers; for example, it may need to use the
        responses from all servers as an input for determining the messages
        (and their content) to subsequently send within the course of each
        individual negotiation. Therefore, timing is an important aspect on the
        client's side. The CPNP client needs to have the ability to
        synchronize the receipt of the responses from the servers. CPNP takes
        into account this requirement by allowing clients to specify in the
        QUOTATION message the time by which the server needs to respond (see
        <a href="#extime" class="xref">Section 9.1.6</a>).<a href="#section-8.10-2" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8.11">
        <h3 id="name-state-management">
<a href="#section-8.11" class="section-number selfRef">8.11. </a><a href="#name-state-management" class="section-name selfRef">State Management</a>
        </h3>
<p id="section-8.11-1">Both the client and the server maintain repositories to store
        ongoing orders. How these repositories are maintained is
        deployment specific. It is out of scope of this document to elaborate
        on such considerations. Timestamps are also logged to track state
        change. Tracking may be needed for various reasons, including
        regulatory or billing ones.<a href="#section-8.11-1" class="pilcrow">¶</a></p>
<p id="section-8.11-2">In order to accommodate failures that may lead to the reboot of the
        client or the server, the use of permanent storage is recommended,
        thereby facilitating state recovery.<a href="#section-8.11-2" class="pilcrow">¶</a></p>
<section id="section-8.11.1">
          <h4 id="name-on-the-client-side">
<a href="#section-8.11.1" class="section-number selfRef">8.11.1. </a><a href="#name-on-the-client-side" class="section-name selfRef">On the Client Side</a>
          </h4>
<p id="section-8.11.1-1">This is the list of the typical states that can be associated
          with a given order on the client's side:<a href="#section-8.11.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.11.1-2">
            <dt id="section-8.11.1-2.1">Created:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.2">The order has been created. It is not handled
              by the client until the administrator allows it to be processed.<a href="#section-8.11.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.3">AwaitingProcessing:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.4">The administrator has approved the
              processing of a created order, but the order has not been handled
              yet.<a href="#section-8.11.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.5">PQOSent:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.6"> The order has been sent to the server.<a href="#section-8.11.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.7">ServerProcessing:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.8">The server has confirmed the receipt
              of the order.<a href="#section-8.11.1-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.9">OfferReceived:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.10">An offer has been received from the
              server.<a href="#section-8.11.1-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.11">OfferProcessing:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.12">A received offer is being processed
              by the client.<a href="#section-8.11.1-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.13">AcceptSent:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.14">The client has confirmed the offer to the
              server.<a href="#section-8.11.1-2.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.15">Completed:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.16">The offer has been acknowledged by the server.<a href="#section-8.11.1-2.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.1-2.17">Cancelled:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.1-2.18">The order has failed or was cancelled.<a href="#section-8.11.1-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-8.11.1-3">Sub-states may be defined (e.g., to track failed vs. cancelled
          orders), but those are not shown in <a href="#clientstate" class="xref">Figure 8</a>.<a href="#section-8.11.1-3" class="pilcrow">¶</a></p>
<span id="name-example-of-a-cpnp-finite-st"></span><div id="clientstate">
<figure id="figure-8">
            <div class="artwork art-text alignCenter" id="section-8.11.1-4.1">
<pre>
+------------------+
|     Created      |-----------------+
+------------------+                 |
        |                            |
        v                            |
+------------------+                 |
|AwaitingProcessing|----------------+|
+------------------+                ||
        |                           ||
   QUOTATION/UPDATE                 ||
        v                           ||
+------------------+                ||
|     PQOSent      |---CANCEL------+||
+------------------+               vvv
        |                        +-----+
    PROCESSING                   |     |
        v                        |     |
+------------------+   CANCEL    |  C  |
| ServerProcessing |------------&gt;|  A  |
+------------------+    FAIL     |  N  |
        |                        |  C  |
        |                        |  E  |
      OFFER                      |  L  |
        |                        |  L  |
        v                        |  E  |
+------------------+             |  D  |
|  OfferReceived   |---CANCEL---&gt;|     |
+------------------+             |     |
        | PROCESSING             +-----+
        v                          ^^^
+------------------+               |||
|  OfferProcessing |---DECLINE-----+||
+------------------+                ||
        | ACCEPT                    ||
        v                           ||
+------------------+                ||
|    AcceptSent    |---CANCEL-------+|
+------------------+                 |
        | ACK                        |
        v                            |
+------------------+                 |
|   Completed      |---WITHDRAW------+
+------------------+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-example-of-a-cpnp-finite-st" class="selfRef">Example of a CPNP Finite State Machine (Client Side)</a>
            </figcaption></figure>
</div>
</section>
<section id="section-8.11.2">
          <h4 id="name-on-the-server-side">
<a href="#section-8.11.2" class="section-number selfRef">8.11.2. </a><a href="#name-on-the-server-side" class="section-name selfRef">On the Server Side</a>
          </h4>
<p id="section-8.11.2-1">The following lists the states on the server's side that can be associated with a
          given order and a corresponding offer:<a href="#section-8.11.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.11.2-2">
            <dt id="section-8.11.2-2.1">PQOReceived:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.2">The order has been received from the
              client.<a href="#section-8.11.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.3">AwaitingProcessing: </dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.4">The order is being processed by the
              server. An action from the server administrator may be
              needed.<a href="#section-8.11.2-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.5">OfferProposed:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.6">The request has been successfully handled,
              and an offer has been sent to the client.<a href="#section-8.11.2-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.7">ProcessingReceived:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.8">The server has received a PROCESSING message for
              an offer sent to the client.<a href="#section-8.11.2-2.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.9">AcceptReceived:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.10">The server has received a confirmation for
              the offer from the client.<a href="#section-8.11.2-2.10" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.11">Completed:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.12">The server has acknowledged the offer (accepted
              by client) to the client. Transitioning to this state assumes
              that the ACK was received by the client (this can be detected by
              the server if it receives a retransmitted ACCEPT message from the
              client).<a href="#section-8.11.2-2.12" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.13">Cancelled:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.14">The order cannot be accommodated, or it has
              been cancelled by the client. Associated resources must be
              released in the latter case, if previously reserved.<a href="#section-8.11.2-2.14" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.15">ChildCreated:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.16">A child order has been created in cases
              where resources from another Network Provider are needed.<a href="#section-8.11.2-2.16" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.17">ChildPQOSent:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.18">A child order has been sent to the remote
              server.<a href="#section-8.11.2-2.18" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.19">ChildServerProcessing:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.20">A child order is being
              processed by the remote server.<a href="#section-8.11.2-2.20" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.21">ChildOfferReceived:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.22"> The remote server has received an offer to a
              child order.<a href="#section-8.11.2-2.22" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.23">ChildOfferProcessing:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.24"> A received offer to a child order
              is being processed.<a href="#section-8.11.2-2.24" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.25">ChildAcceptSent: </dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.26">The child offer (the offer received from
              the remote server in response to a child order) is confirmed to
              the remote server.<a href="#section-8.11.2-2.26" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-8.11.2-2.27">ChildCompleted:</dt>
            <dd style="margin-left: 1.5em" id="section-8.11.2-2.28"> The accepted child offer has been acknowledged
              by the remote server.<a href="#section-8.11.2-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<span id="name-cpnp-finite-state-machine-s"></span><div id="serverstate">
<figure id="figure-9">
            <div class="artwork art-text alignCenter" id="section-8.11.2-3.1">
<pre>
+------------------+           +------------------+
|AwaitingProcessing|&lt;----------|    ChildCreated  |
+------------------+           +------------------+
        |                            |      ^
        v                            |      |
+------------------+                 |      |
|   ChildPQOSent   |----------------+|      Q
+------------------+                ||      U
        |                           ||      O
     QUOTATION/UPDATE               ||      T
        v                           ||      A  +--------------------+
+---------------------+   CANCEL    ||      T  |     PQOReceived    |
|ChildServerProcessing|------------+||      I  +--------------------+
+---------------------+    FAIL    vvv      O       |      |
        |                        +-----+    N    CANCEL    |
    PROCESSING                   |     |&lt;---|-------+  PROCESSING
        v                        |     |    |              v
+------------------+             |     |   +------------------------+
|ChildOfferReceived|----CANCEL---|  C  |&lt;--|   AwaitingProcessing   |
+------------------+             |  A  |   +------------------------+
        |                        |  N  |       ^          | OFFER
      OFFER                      |  C  |       | +------------------+
        |                        |  E  |&lt;DECLINE-|   OfferProposed  |
        |                        |  L  |       | +------------------+
        v                        |  L  |       |          |
+------------------+             |  E  |       |      PROCESSING
|ChildOfferReceived|---CANCEL----|  D  |       |          v
+------------------+             |     |       | +------------------+
        |                        |     |&lt;DECLINE-| Proc'ingReceived |
   PROCESSING                    |     |       |+------------------+
        |                        +-----+       |          | ACCEPT
        v                         ^^^^^        |          v
+------------------+              |||||        | +------------------+
|ChildOfferProc'ing|---DECLINE----+|||+-CANCEL-|-|  AcceptReceived  |
+------------------+               |||         | +------------------+
        |ACCEPT                    |||         |          |ACK
        v                          |||         |          v
+------------------+               |||         | +------------------+
|  ChildAcceptSent |---CANCEL------+|+-WITHDRAW|-|    Completed     |
+------------------+                |          | +------------------+
        | ACK                       |          |
        v                           |          |
+------------------+                |          |
|  ChildCompleted  |---WITHDRAW-----+          |
|                  +---------------------------+
+------------------+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-cpnp-finite-state-machine-s" class="selfRef">CPNP Finite State Machine (Server Side)</a>
            </figcaption></figure>
</div>
</section>
</section>
</section>
</div>
<div id="co">
<section id="section-9">
      <h2 id="name-cpnp-objects">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-cpnp-objects" class="section-name selfRef">CPNP Objects</a>
      </h2>
<p id="section-9-1">This section defines CPNP objects using the Routing Backus-Naur Form (RBNF) format defined in 
      <span>[<a href="#RFC5511" class="xref">RFC5511</a>]</span>.  Please also note the
      following:<a href="#section-9-1" class="pilcrow">¶</a></p>
<aside id="section-9-2">
        <p id="section-9-2.1">Note 1: The formats of CPNP messages are provided using a generic
          format. Implementors can adapt RBNF definitions to their "favorite"
          message format. For example, JSON <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span> or
          Concise Binary Object Representation (CBOR) <span>[<a href="#RFC7049" class="xref">RFC7049</a>]</span> can be used.<a href="#section-9-2.1" class="pilcrow">¶</a></p>
</aside>
<aside id="section-9-3">
        <p id="section-9-3.1">Note 2: CPNP messages cannot be blindly mapped to RESTCONF
          messages with the target service being modelled as configuration
          data because such data is supposed to be manipulated by a RESTCONF
          client only. In such a model, the RESTCONF server cannot use a value
          other than the one set by the client (e.g., <a href="#offer" class="xref">Section 9.2.3</a>) 
          or remove offers from its own initiative
          (e.g., <a href="#valtime" class="xref">Section 9.1.8</a>). An alternate approach might
          be to map CPNP operations into RESTCONF actions (RPC). Assessing the
          feasibility of such approach is out of scope.<a href="#section-9-3.1" class="pilcrow">¶</a></p>
</aside>
<section id="section-9.1">
        <h3 id="name-attributes">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-attributes" class="section-name selfRef">Attributes</a>
        </h3>
<div id="cu_id">
<section id="section-9.1.1">
          <h4 id="name-customer_order_identifier">
<a href="#section-9.1.1" class="section-number selfRef">9.1.1. </a><a href="#name-customer_order_identifier" class="section-name selfRef">CUSTOMER_ORDER_IDENTIFIER</a>
          </h4>
<p id="section-9.1.1-1">The CUSTOMER_ORDER_IDENTIFIER (Customer Order Identifier) is an identifier that is assigned
          by a client to identify an agreement. This identifier must be unique
          to the client.<a href="#section-9.1.1-1" class="pilcrow">¶</a></p>
<p id="section-9.1.1-2">Rules for assigning this identifier (including the structure and
          semantics) are specific to the client (Customer). The value of
          CUSTOMER_ORDER_IDENTIFIER is included in all CPNP messages.<a href="#section-9.1.1-2" class="pilcrow">¶</a></p>
<p id="section-9.1.1-3">The client (Customer) assigns an identifier to an order under
          negotiation before an agreement is reached. This identifier will be
          used to unambiguously identify the resulting agreement at the client
          side (Customer).<a href="#section-9.1.1-3" class="pilcrow">¶</a></p>
<p id="section-9.1.1-4">The server handles the CUSTOMER_ORDER_IDENTIFIER as an opaque
          value.<a href="#section-9.1.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="pr_id">
<section id="section-9.1.2">
          <h4 id="name-provider_order_identifier">
<a href="#section-9.1.2" class="section-number selfRef">9.1.2. </a><a href="#name-provider_order_identifier" class="section-name selfRef">PROVIDER_ORDER_IDENTIFIER</a>
          </h4>
<p id="section-9.1.2-1">The PROVIDER_ORDER_IDENTIFIER (Provider Order Identifier) is an identifier that is assigned
          by a server to identify an order. This identifier must be unique to
          the server.<a href="#section-9.1.2-1" class="pilcrow">¶</a></p>
<p id="section-9.1.2-2">Rules for assigning this identifier (including the structure and
          semantics) are specific to the server (Provider).
          The PROVIDER_ORDER_IDENTIFIER is included in all CPNP messages
          except QUOTATION messages (because the state is only present at the
          client side).<a href="#section-9.1.2-2" class="pilcrow">¶</a></p>
<p id="section-9.1.2-3">The server (Provider) assigns an identifier to an order under
          negotiation before an agreement is reached. This identifier will be
          used to unambiguously identify the resulting agreement at the server
          side (Provider).<a href="#section-9.1.2-3" class="pilcrow">¶</a></p>
<p id="section-9.1.2-4">The client handles the PROVIDER_ORDER_IDENTIFIER as an opaque
          value.<a href="#section-9.1.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="trans_id">
<section id="section-9.1.3">
          <h4 id="name-transaction_id">
<a href="#section-9.1.3" class="section-number selfRef">9.1.3. </a><a href="#name-transaction_id" class="section-name selfRef">TRANSACTION_ID</a>
          </h4>
<p id="section-9.1.3-1">This object conveys the Transaction-ID introduced in <a href="#trans" class="xref">Section 8.4</a>.<a href="#section-9.1.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9.1.4">
          <h4 id="name-sequence_number">
<a href="#section-9.1.4" class="section-number selfRef">9.1.4. </a><a href="#name-sequence_number" class="section-name selfRef">SEQUENCE_NUMBER</a>
          </h4>
<p id="section-9.1.4-1">The sequence number is a number that is monotonically incremented in
          every new CPNP message pertaining to a given CPNP transaction. This
          number is used to avoid replay attacks.<a href="#section-9.1.4-1" class="pilcrow">¶</a></p>
<p id="section-9.1.4-2">Refer to <a href="#sq_nu" class="xref">Section 11.3</a>.<a href="#section-9.1.4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-9.1.5">
          <h4 id="name-nonce">
<a href="#section-9.1.5" class="section-number selfRef">9.1.5. </a><a href="#name-nonce" class="section-name selfRef">NONCE</a>
          </h4>
<p id="section-9.1.5-1">The NONCE is a random value assigned by the CPNP server. 
          Assigning a unique NONCE value for each order is recommended.<a href="#section-9.1.5-1" class="pilcrow">¶</a></p>
<p id="section-9.1.5-2">It is mandatory to then include the NONCE in subsequent CPNP client
          operations on the associated order (including the resulting
          agreement) such as withdrawing the order or updating the order.<a href="#section-9.1.5-2" class="pilcrow">¶</a></p>
<p id="section-9.1.5-3">If the NONCE validation checks fail, the server rejects the
          request with a FAIL message that includes the appropriate failure reason
          code.<a href="#section-9.1.5-3" class="pilcrow">¶</a></p>
</section>
<div id="extime">
<section id="section-9.1.6">
          <h4 id="name-expected_response_time">
<a href="#section-9.1.6" class="section-number selfRef">9.1.6. </a><a href="#name-expected_response_time" class="section-name selfRef">EXPECTED_RESPONSE_TIME</a>
          </h4>
<p id="section-9.1.6-1">This attribute indicates the time by when the CPNP client is
          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
          quotation order to be rejected.<a href="#section-9.1.6-1" class="pilcrow">¶</a></p>
<p id="section-9.1.6-2">The EXPECTED_RESPONSE_TIME follows the date format specified in <span>[<a href="#RFC3339" class="xref">RFC3339</a>]</span>.<a href="#section-9.1.6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="EXPECTED_OFFER_TIME">
<section id="section-9.1.7">
          <h4 id="name-expected_offer_time">
<a href="#section-9.1.7" class="section-number selfRef">9.1.7. </a><a href="#name-expected_offer_time" class="section-name selfRef">EXPECTED_OFFER_TIME</a>
          </h4>
<p id="section-9.1.7-1">This attribute indicates the time by when the CPNP server is
          expecting to make an offer to the CPNP client. If no offer is
          received by then, the CPNP client will consider the order 
          rejected.<a href="#section-9.1.7-1" class="pilcrow">¶</a></p>
<p id="section-9.1.7-2">The CPNP server may propose an expected offer time that does not
          match the expected response time indicated in the quotation order
          message. The CPNP client can accept or reject the proposed expected
          time by when the CPNP server will make an offer.<a href="#section-9.1.7-2" class="pilcrow">¶</a></p>
<p id="section-9.1.7-3">The CPNP server can always request extra time for its processing,
          but this may be accepted or rejected by the CPNP client.<a href="#section-9.1.7-3" class="pilcrow">¶</a></p>
<p id="section-9.1.7-4">The EXPECTED_OFFER_TIME follows the date format specified in <span>[<a href="#RFC3339" class="xref">RFC3339</a>]</span>.<a href="#section-9.1.7-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="valtime">
<section id="section-9.1.8">
          <h4 id="name-validity_offer_time">
<a href="#section-9.1.8" class="section-number selfRef">9.1.8. </a><a href="#name-validity_offer_time" class="section-name selfRef">VALIDITY_OFFER_TIME</a>
          </h4>
<p id="section-9.1.8-1">This attribute indicates the time of validity of an offer made by
          the CPNP server. If the offer is not accepted before this time 
          expires, the CPNP server will consider the CPNP client as having rejected
          the offer; the CPNP server will silently remove this order from its
          base.<a href="#section-9.1.8-1" class="pilcrow">¶</a></p>
<p id="section-9.1.8-2">The VALIDITY_OFFER_TIME follows date format specified in <span>[<a href="#RFC3339" class="xref">RFC3339</a>]</span>.<a href="#section-9.1.8-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="service_template">
<section id="section-9.1.9">
          <h4 id="name-service_description">
<a href="#section-9.1.9" class="section-number selfRef">9.1.9. </a><a href="#name-service_description" class="section-name selfRef">SERVICE_DESCRIPTION</a>
          </h4>
<p id="section-9.1.9-1">This document defines a machinery to negotiate any aspect subject
          to negotiation. Service clauses that are under negotiation are
          conveyed using this attribute.<a href="#section-9.1.9-1" class="pilcrow">¶</a></p>
<p id="section-9.1.9-2">The structure of the connectivity provisioning clauses is
          provided in the following subsection.<a href="#section-9.1.9-2" class="pilcrow">¶</a></p>
<div id="cpd_template">
<section id="section-9.1.9.1">
            <h5 id="name-cpd">
<a href="#section-9.1.9.1" class="section-number selfRef">9.1.9.1. </a><a href="#name-cpd" class="section-name selfRef">CPD</a>
            </h5>
<p id="section-9.1.9.1-1">The RBNF format of the CPD
            is shown in <a href="#rbnf_cpd" class="xref">Figure 10</a>.<a href="#section-9.1.9.1-1" class="pilcrow">¶</a></p>
<span id="name-the-rbnf-format-of-the-cpd"></span><div id="rbnf_cpd">
<figure id="figure-10">
              <div id="section-9.1.9.1-2.1">
<pre class="sourcecode lang-rbnf">
&lt;CPD&gt; ::=  &lt;Connectivity Provisioning Component&gt; ...
&lt;Connectivity Provisioning Component&gt; ::=
                           &lt;CONNECTIVITY_PROVISIONING_PROFILE&gt; ...
&lt;CONNECTIVITY_PROVISIONING_PROFILE&gt; ::=
                           &lt;Customer Nodes Map&gt;
                           &lt;SCOPE&gt;
                           &lt;QoS Guarantees&gt;
                           &lt;Availability&gt;
                           &lt;CAPACITY&gt;
                           &lt;Traffic Isolation&gt;
                           &lt;Conformance Traffic&gt;
                           &lt;Flow Identification&gt;
                           &lt;Overall Traffic Guarantees&gt;
                           &lt;Routing and Forwarding&gt;
                           &lt;Activation Means&gt;
                           &lt;Invocation Means&gt;
                           &lt;Notifications&gt;
&lt;Customer Nodes Map&gt; ::=  &lt;Customer Node&gt; ...
&lt;Customer Node&gt; ::=  &lt;IDENTIFIER&gt;
                     &lt;LINK_IDENTIFIER&gt;
                     &lt;LOCALIZATION&gt;
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-the-rbnf-format-of-the-cpd" class="selfRef">The RBNF format of the CPD</a>
              </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<section id="section-9.1.10">
          <h4 id="name-cpnp-information-elements">
<a href="#section-9.1.10" class="section-number selfRef">9.1.10. </a><a href="#name-cpnp-information-elements" class="section-name selfRef">CPNP Information Elements</a>
          </h4>
<p id="section-9.1.10-1">An Information Element (IE) is an optional object that can be
          included in a CPNP message.<a href="#section-9.1.10-1" class="pilcrow">¶</a></p>
<section id="section-9.1.10.1">
            <h5 id="name-customer-description">
<a href="#section-9.1.10.1" class="section-number selfRef">9.1.10.1. </a><a href="#name-customer-description" class="section-name selfRef">Customer Description</a>
            </h5>
<p id="section-9.1.10.1-1">The client may include administrative information such
            as the following:<a href="#section-9.1.10.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.1.10.1-2.1">Name<a href="#section-9.1.10.1-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-9.1.10.1-2.2">Contact Information<a href="#section-9.1.10.1-2.2" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-9.1.10.1-3">The format of this Information Element is as follows:<a href="#section-9.1.10.1-3" class="pilcrow">¶</a></p>
<div id="section-9.1.10.1-4">
<pre class="sourcecode lang-rbnf">
&lt;Customer Description&gt; ::= [&lt;NAME&gt;] [&lt;Contact Information&gt;]
&lt;Contact Information&gt; ::=  [&lt;EMAIL_ADDRESS&gt;] [&lt;POSTAL_ADDRESS&gt;]
                           [&lt;TELEPHONE_NUMBER&gt; ...]
</pre><a href="#section-9.1.10.1-4" class="pilcrow">¶</a>
</div>
</section>
<section id="section-9.1.10.2">
            <h5 id="name-provider-description">
<a href="#section-9.1.10.2" class="section-number selfRef">9.1.10.2. </a><a href="#name-provider-description" class="section-name selfRef">Provider Description</a>
            </h5>
<p id="section-9.1.10.2-1">The server may include administrative information in an offer
            such as the following:<a href="#section-9.1.10.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.1.10.2-2.1">Name<a href="#section-9.1.10.2-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-9.1.10.2-2.2">AS Number <span>[<a href="#RFC6793" class="xref">RFC6793</a>]</span><a href="#section-9.1.10.2-2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-9.1.10.2-2.3">Contact Information<a href="#section-9.1.10.2-2.3" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-9.1.10.2-3">The format of this Information Element is as follows:<a href="#section-9.1.10.2-3" class="pilcrow">¶</a></p>
<div id="section-9.1.10.2-4">
<pre class="sourcecode lang-rbnf">
&lt;Provider Description&gt; ::= [&lt;NAME&gt;][&lt;Contact Information&gt;]
                           [&lt;AS_NUMBER&gt;]
</pre><a href="#section-9.1.10.2-4" class="pilcrow">¶</a>
</div>
</section>
<div id="nego">
<section id="section-9.1.10.3">
            <h5 id="name-negotiation-options">
<a href="#section-9.1.10.3" class="section-number selfRef">9.1.10.3. </a><a href="#name-negotiation-options" class="section-name selfRef">Negotiation Options</a>
            </h5>
<p id="section-9.1.10.3-1">The client may include some negotiation options such as the following:<a href="#section-9.1.10.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9.1.10.3-2">
              <dt id="section-9.1.10.3-2.1">Setup purpose:</dt>
              <dd style="margin-left: 1.5em" id="section-9.1.10.3-2.2">A client may request the setup of a service
                (e.g., connectivity) only for testing purposes during a
                limited period. The order can be extended to become permanent
                if the client was satisfied during the test period. This
                operation is achieved using the UPDATE method.<a href="#section-9.1.10.3-2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-9.1.10.3-2.3">Activation type:</dt>
              <dd style="margin-left: 1.5em" id="section-9.1.10.3-2.4"> A client may request a permanent or
                scheduled activation type. If no activation type clause is
                included during the negotiation, this means that the order
                will be immediately activated right after the negotiation
                ends.<a href="#section-9.1.10.3-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-9.1.10.3-3">The format of this Information Element is as follows:<a href="#section-9.1.10.3-3" class="pilcrow">¶</a></p>
<div id="section-9.1.10.3-4">
<pre class="sourcecode lang-rbnf">
&lt;Negotiation Options&gt; ::= [&lt;PURPOSE&gt;]
</pre><a href="#section-9.1.10.3-4" class="pilcrow">¶</a>
</div>
</section>
</div>
</section>
</section>
<section id="section-9.2">
        <h3 id="name-operation-messages">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-operation-messages" class="section-name selfRef">Operation Messages</a>
        </h3>
<p id="section-9.2-1">This section defines the RBNF format of CPNP operation messages.
        The following operation codes are used:<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<span id="name-cpnp-operation-message-code"></span><table class="left" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-cpnp-operation-message-code" class="selfRef">CPNP Operation Message Codes</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Code</th>
              <th class="text-left" rowspan="1" colspan="1">Operation Message</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">QUOTATION</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#provision" class="xref">Section 9.2.1</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">PROCESSING</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#proc" class="xref">Section 9.2.2</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3</td>
              <td class="text-left" rowspan="1" colspan="1">OFFER</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#offer" class="xref">Section 9.2.3</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4</td>
              <td class="text-left" rowspan="1" colspan="1">ACCEPT</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#accept" class="xref">Section 9.2.4</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5</td>
              <td class="text-left" rowspan="1" colspan="1">DECLINE</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#dec" class="xref">Section 9.2.5</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">6</td>
              <td class="text-left" rowspan="1" colspan="1">ACK</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#ack" class="xref">Section 9.2.6</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">7</td>
              <td class="text-left" rowspan="1" colspan="1">CANCEL</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#cancel" class="xref">Section 9.2.7</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">8</td>
              <td class="text-left" rowspan="1" colspan="1">WITHDRAW</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#with" class="xref">Section 9.2.8</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">9</td>
              <td class="text-left" rowspan="1" colspan="1">UPDATE</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#upd" class="xref">Section 9.2.9</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">10</td>
              <td class="text-left" rowspan="1" colspan="1">FAIL</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#fail" class="xref">Section 9.2.10</a>
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">11</td>
              <td class="text-left" rowspan="1" colspan="1">ACTIVATE</td>
              <td class="text-left" rowspan="1" colspan="1">
                <a href="#activate" class="xref">Section 9.2.11</a>
</td>
            </tr>
          </tbody>
        </table>
<p id="section-9.2-3">These codes are used to unambiguously identify a CPNP operation;
        the operation code is conveyed in the METHOD_CODE attribute
        mentioned in the following subsections.<a href="#section-9.2-3" class="pilcrow">¶</a></p>
<p id="section-9.2-4">In the following, VERSION refers to the CPNP version number. This
        attribute must be set to 1.<a href="#section-9.2-4" class="pilcrow">¶</a></p>
<div id="provision">
<section id="section-9.2.1">
          <h4 id="name-quotation">
<a href="#section-9.2.1" class="section-number selfRef">9.2.1. </a><a href="#name-quotation" class="section-name selfRef">QUOTATION</a>
          </h4>
<p id="section-9.2.1-1">The format of the QUOTATION message is shown below:<a href="#section-9.2.1-1" class="pilcrow">¶</a></p>
<div id="section-9.2.1-2">
<pre class="sourcecode lang-rbnf">
&lt;QUOTATION Message&gt; ::=  &lt;VERSION&gt;
                         &lt;METHOD_CODE&gt;
                         &lt;SEQUENCE_NUMBER&gt;
                         &lt;TRANSACTION_ID&gt;
                         &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                         [&lt;EXPECTED_RESPONSE_TIME&gt;]
                         &lt;REQUESTED_CPD&gt;
                         [&lt;INFORMATION_ELEMENT&gt;...]
</pre><a href="#section-9.2.1-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.1-3">A QUOTATION message must include an order
          identifier that is generated by the client
          (CUSTOMER_ORDER_IDENTIFIER). Because several orders can be
          issued to several servers, the QUOTATION message must also include a
          Transaction-ID.<a href="#section-9.2.1-3" class="pilcrow">¶</a></p>
<p id="section-9.2.1-4">The message may include an EXPECTED_RESPONSE_TIME, which indicates
          by when the client expects to receive an offer from the server.
          The QUOTATION message must also include a requested service description
          (that is, a Requested CPD for
          connectivity services).<a href="#section-9.2.1-4" class="pilcrow">¶</a></p>
<p id="section-9.2.1-5">The message may include ACTIVATION_TYPE to request a permanent or
          scheduled activation type (e.g., using the ACTIVATE method defined
          in <a href="#activate" class="xref">Section 9.2.11</a>). If no such clause is included,
          the default mode is to assume that the order will be active once the
          accepted activation means are successfully invoked (e.g., <span><a href="https://www.rfc-editor.org/rfc/rfc7297#section-3.11" class="relref">Section 3.11</a> of [<a href="#RFC7297" class="xref">RFC7297</a>]</span>).<a href="#section-9.2.1-5" class="pilcrow">¶</a></p>
<p id="section-9.2.1-6">When the client sends the QUOTATION message to the server, the
          state of the order changes to "PQOSent" at the client side.<a href="#section-9.2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="proc">
<section id="section-9.2.2">
          <h4 id="name-processing">
<a href="#section-9.2.2" class="section-number selfRef">9.2.2. </a><a href="#name-processing" class="section-name selfRef">PROCESSING</a>
          </h4>
<p id="section-9.2.2-1">The format of the PROCESSING message is shown below:<a href="#section-9.2.2-1" class="pilcrow">¶</a></p>
<div id="section-9.2.2-2">
<pre class="sourcecode lang-rbnf">
&lt;PROCESSING Message&gt; ::= &lt;VERSION&gt;
                         &lt;METHOD_CODE&gt;
                         &lt;SEQUENCE_NUMBER&gt;
                         &lt;TRANSACTION_ID&gt;
                         &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                         &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                         [&lt;EXPECTED_OFFER_TIME&gt;]
                         [&lt;PROCESSING_SUBCODE&gt;]
</pre><a href="#section-9.2.2-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.2-3">Upon receipt of a QUOTATION message, the
          server proceeds with the parsing rules (see <a href="#validation" class="xref">Section 10</a>). 
          If no error is encountered, the server
          generates a PROCESSING response to the client to indicate the PQO
          has been received and it is being processed. The server must
          generate an order identifier that identifies the order in its local
          order repository. The server must copy the content of the
          CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID fields as conveyed
          in the QUOTATION message. The server may include an
          EXPECTED_OFFER_TIME by when it expects to make an offer to the
          client.<a href="#section-9.2.2-3" class="pilcrow">¶</a></p>
<p id="section-9.2.2-4">Upon receipt of a PROCESSING message, the client verifies whether
          it has issued a PQO that contains the
          CUSTOMER_ORDER_IDENTIFIER and TRANSACTION_ID to that server. If no such PQO is
          found, the PROCESSING message must be silently ignored. If a PQO is
          found, the client may check whether it accepts the
          EXPECTED_OFFER_TIME, and then it changes to state of the order to
          "ServerProcessing".<a href="#section-9.2.2-4" class="pilcrow">¶</a></p>
<p id="section-9.2.2-5">If the server requires more time to process the quotation
          order, it may send a PROCESSING message that includes a new
          EXPECTED_OFFER_TIME. The client can answer with an ACK message if
          more time is granted (<a href="#timegranted" class="xref">Figure 11</a>) or with a
          FAIL message if the time extension request is rejected (<a href="#timerejected" class="xref">Figure 12</a>).<a href="#section-9.2.2-5" class="pilcrow">¶</a></p>
<p id="section-9.2.2-6">The server may provide more details in the PROCESSING_SUBCODE
          attribute about the reason for requesting more time to process the
          request. The following codes are defined:<a href="#section-9.2.2-6" class="pilcrow">¶</a></p>
<span id="name-processing_subcode-codes"></span><table class="left" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-processing_subcode-codes" class="selfRef">PROCESSING_SUBCODE Codes</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Subcode</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">Upgrade of local resources</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">Request external resources</td>
              </tr>
            </tbody>
          </table>
<span id="name-request-more-negotiation-ti"></span><div id="timegranted">
<figure id="figure-11">
            <div class="artwork art-text alignCenter" id="section-9.2.2-8.1">
<pre>
+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |=======QUOTATION(Requested CPD)=====&gt;|
   |&lt;========PROCESSING(time1)===========|
                     ...
   |&lt;========PROCESSING(MoreTime)========|
   |============ACK(TimeGranted)========&gt;|
                     ...
   |&lt;=========OFFER(Offered CPD)=========|
   |=============PROCESSING=============&gt;|
   |=========ACCEPT(Accepted CPD)=======&gt;|
   |&lt;=========ACK(Accepted CPD)==========|
   |                                     |
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-request-more-negotiation-ti" class="selfRef">Request More Negotiation Time: Granted</a>
            </figcaption></figure>
</div>
<span id="name-request-more-negotiation-tim"></span><div id="timerejected">
<figure id="figure-12">
            <div class="artwork art-text alignCenter" id="section-9.2.2-9.1">
<pre>
+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |=======QUOTATION(Requested CPD)=====&gt;|
   |&lt;========PROCESSING(time1)===========|
                     ...
   |&lt;========PROCESSING(MoreTime)========|
   |=====FAIL(More Time Rejected)=======&gt;|
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-request-more-negotiation-tim" class="selfRef">Request More Negotiation Time: Rejected</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="offer">
<section id="section-9.2.3">
          <h4 id="name-offer">
<a href="#section-9.2.3" class="section-number selfRef">9.2.3. </a><a href="#name-offer" class="section-name selfRef">OFFER</a>
          </h4>
<p id="section-9.2.3-1">The format of the OFFER message is shown below:<a href="#section-9.2.3-1" class="pilcrow">¶</a></p>
<div id="section-9.2.3-2">
<pre class="sourcecode lang-rbnf">
&lt;OFFER Message&gt; ::= &lt;VERSION&gt;
                    &lt;METHOD_CODE&gt;
                    &lt;SEQUENCE_NUMBER&gt;
                    &lt;TRANSACTION_ID&gt;
                    &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                    &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                    &lt;NONCE&gt;
                    &lt;VALIDITY_OFFER_TIME&gt;
                    &lt;OFFERED_CPD&gt;
                    [&lt;INFORMATION_ELEMENT&gt;...]
</pre><a href="#section-9.2.3-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.3-3">The server answers
          a QUOTATION request received from the client with an OFFER message. The offer will be
          considered to be rejected by the client if no confirmation (i.e., an ACCEPT
          message sent by the client) is received by the server before the
          expiration of the validity time.<a href="#section-9.2.3-3" class="pilcrow">¶</a></p>
<p id="section-9.2.3-4">The server may include ACTIVATION_TYPE to indicate whether the
          offer is about a permanent or scheduled activation type. The message
          may include ACTIVATION_SCHEDULE to indicate when the order is to be
          activated. If no such clause is included, the default mode is to
          assume that the order will be active once the accepted activation
          means are successfully invoked (e.g., <span><a href="https://www.rfc-editor.org/rfc/rfc7297#section-3.11" class="relref">Section 3.11</a> of [<a href="#RFC7297" class="xref">RFC7297</a>]</span> or <a href="#activate" class="xref">Section 9.2.11</a>).<a href="#section-9.2.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="accept">
<section id="section-9.2.4">
          <h4 id="name-accept">
<a href="#section-9.2.4" class="section-number selfRef">9.2.4. </a><a href="#name-accept" class="section-name selfRef">ACCEPT</a>
          </h4>
<p id="section-9.2.4-1">The format of the ACCEPT message is shown below:<a href="#section-9.2.4-1" class="pilcrow">¶</a></p>
<div id="section-9.2.4-2">
<pre class="sourcecode lang-rbnf">
&lt;ACCEPT Message&gt; ::= &lt;VERSION&gt;
                     &lt;METHOD_CODE&gt;
                     &lt;SEQUENCE_NUMBER&gt;
                     &lt;TRANSACTION_ID&gt;
                     &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                     &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                     &lt;NONCE&gt;
                     &lt;ACCEPTED_CPD&gt;
                     [&lt;INFORMATION_ELEMENT&gt;...]
</pre><a href="#section-9.2.4-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.4-3">This message is used by a client to
          confirm the acceptance of an offer received from a server. The
          fields of this message must be copied from the received OFFER
          message. This message should not be sent after the validity time of
          the offer expires, as indicated by the server (<a href="#offer" class="xref">Section 9.2.3</a>).<a href="#section-9.2.4-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="dec">
<section id="section-9.2.5">
          <h4 id="name-decline">
<a href="#section-9.2.5" class="section-number selfRef">9.2.5. </a><a href="#name-decline" class="section-name selfRef">DECLINE</a>
          </h4>
<p id="section-9.2.5-1">The format of the DECLINE message is shown below:<a href="#section-9.2.5-1" class="pilcrow">¶</a></p>
<div id="section-9.2.5-2">
<pre class="sourcecode lang-rbnf">
&lt;DECLINE Message&gt; ::= &lt;VERSION&gt;
                      &lt;METHOD_CODE&gt;
                      &lt;SEQUENCE_NUMBER&gt;
                      &lt;TRANSACTION_ID&gt;
                      &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                      &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                      &lt;NONCE&gt;
                      [&lt;REASON&gt;...]
</pre><a href="#section-9.2.5-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.5-3">The client may issue a DECLINE
          message to reject an offer. CUSTOMER_ORDER_IDENTIFIER,
          PROVIDER_ORDER_IDENTIFIER, TRANSACTION_ID, and NONCE are used by
          the server as keys to find the corresponding order. If an order
          matches, the server changes the state of this order to "Cancelled"
          and then returns an ACK with a copy of the Requested CPD to the
          requesting client.<a href="#section-9.2.5-3" class="pilcrow">¶</a></p>
<p id="section-9.2.5-4">A DECLINE message may include an Information Element to indicate
          the reason for declining an offer. The following codes are defined:<a href="#section-9.2.5-4" class="pilcrow">¶</a></p>
<span id="name-decline-message-codes"></span><table class="left" id="table-3">
            <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-decline-message-codes" class="selfRef">DECLINE Message Codes</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Code</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">Unacceptable gap between the request and the offer</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">Conflict with another offer from another server</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">Activation type mismatch</td>
              </tr>
            </tbody>
          </table>
<p id="section-9.2.5-6">If no order is found, the server returns a FAIL message to the
          requesting client. In order to prevent DDoS (Distributed Denial of
          Service) attacks, the server should restrict the number of FAIL
          messages sent to a requesting client. It may also rate-limit FAIL
          messages.<a href="#section-9.2.5-6" class="pilcrow">¶</a></p>
<p id="section-9.2.5-7">A flow example is shown in <a href="#decline" class="xref">Figure 13</a>.<a href="#section-9.2.5-7" class="pilcrow">¶</a></p>
<span id="name-decline-flow-example"></span><div id="decline">
<figure id="figure-13">
            <div class="artwork art-text alignCenter" id="section-9.2.5-8.1">
<pre>+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |=======QUOTATION(Requested CPD)=====&gt;|
   |&lt;============PROCESSING==============|
   |&lt;=========OFFER(Offered CPD)=========|
   |=============PROCESSING=============&gt;|
   |===============DECLINE==============&gt;|
   |&lt;================ACK=================|
   |                                     |
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-decline-flow-example" class="selfRef">DECLINE Flow Example</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="ack">
<section id="section-9.2.6">
          <h4 id="name-ack">
<a href="#section-9.2.6" class="section-number selfRef">9.2.6. </a><a href="#name-ack" class="section-name selfRef">ACK</a>
          </h4>
<p id="section-9.2.6-1">The format of the ACK message is shown below:<a href="#section-9.2.6-1" class="pilcrow">¶</a></p>
<div id="section-9.2.6-2">
<pre class="sourcecode lang-rbnf">
&lt;ACK Message&gt; ::= &lt;VERSION&gt;
                  &lt;METHOD_CODE&gt;
                  &lt;SEQUENCE_NUMBER&gt;
                  &lt;TRANSACTION_ID&gt;
                  &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                  &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                  [&lt;EXPECTED_RESPONSE_TIME&gt;]
                  [&lt;CPD&gt;]
                  [&lt;INFORMATION_ELEMENT&gt;...]
</pre><a href="#section-9.2.6-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.6-3">This message is issued by the server to
          close a CPNP transaction or by a client to grant more negotiation
          time to the server.<a href="#section-9.2.6-3" class="pilcrow">¶</a></p>
<p id="section-9.2.6-4">This message is sent by the server as a response to an ACCEPT,
          WITHDRAW, DECLINE, or CANCEL message. In this case, the ACK message
          must include the copy of the service description (i.e., CPD for connectivity services) as stored
          by the server. In particular, the following considerations are taken
          into account for connectivity provisioning services:<a href="#section-9.2.6-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.6-5.1">A copy of the Requested/Offered CPD is included by the server
              if it successfully handled a CANCEL message.<a href="#section-9.2.6-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.6-5.2">A copy of the Updated CPD is included by the server if it
              successfully handled an UPDATE message.<a href="#section-9.2.6-5.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.6-5.3">A copy of the Offered CPD is included by the server if it
              successfully handled an ACCEPT message in the context of a
              QUOTATION transaction (refer to "Accepted CPD" in <a href="#cpd" class="xref">Section 8.7</a>).<a href="#section-9.2.6-5.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.6-5.4">An Empty CPD is included by the server if it successfully
              handled a DECLINE or WITHDRAW message.<a href="#section-9.2.6-5.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-9.2.6-6">A client may issue an ACK message as a response to a time
          extension request (conveyed in PROCESSING) received from the server.
          In such case, the ACK message must include an EXPECTED_RESPONSE_TIME
          that is likely to be set to the time extension requested by the
          server.<a href="#section-9.2.6-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cancel">
<section id="section-9.2.7">
          <h4 id="name-cancel">
<a href="#section-9.2.7" class="section-number selfRef">9.2.7. </a><a href="#name-cancel" class="section-name selfRef">CANCEL</a>
          </h4>
<p id="section-9.2.7-1">The format of the CANCEL message is shown below:<a href="#section-9.2.7-1" class="pilcrow">¶</a></p>
<div id="section-9.2.7-2">
<pre class="sourcecode lang-rbnf">
&lt;CANCEL Message&gt; ::= &lt;VERSION&gt;
                     &lt;METHOD_CODE&gt;
                     &lt;SEQUENCE_NUMBER&gt;
                     &lt;TRANSACTION_ID&gt;
                     &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                     [&lt;CPD&gt;]
</pre><a href="#section-9.2.7-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.7-3">The client can issue a CANCEL
          message at any stage during the CPNP negotiation process before an
          agreement is reached. The CUSTOMER_ORDER_IDENTIFIER and
          TRANSACTION_ID are used by the server as keys to find the
          corresponding order. If a quotation order matches, the server
          changes the state of this quotation order to "Cancelled" and then
          returns an ACK with a copy of the Requested CPD to the requesting
          client.<a href="#section-9.2.7-3" class="pilcrow">¶</a></p>
<p id="section-9.2.7-4">If no quotation order is found, the server returns a FAIL message
          to the requesting client.<a href="#section-9.2.7-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="with">
<section id="section-9.2.8">
          <h4 id="name-withdraw">
<a href="#section-9.2.8" class="section-number selfRef">9.2.8. </a><a href="#name-withdraw" class="section-name selfRef">WITHDRAW</a>
          </h4>
<p id="section-9.2.8-1">The format of the WITHDRAW message is shown below:<a href="#section-9.2.8-1" class="pilcrow">¶</a></p>
<div id="section-9.2.8-2">
<pre class="sourcecode lang-rbnf">
&lt;WITHDRAW Message&gt; ::= &lt;VERSION&gt;
                       &lt;METHOD_CODE&gt;
                       &lt;SEQUENCE_NUMBER&gt;
                       &lt;TRANSACTION_ID&gt;
                       &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                       &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                       &lt;NONCE&gt;
                       [&lt;ACCEPTED_CPD&gt;]
                       [&lt;INFORMATION_ELEMENT&gt;...]
</pre><a href="#section-9.2.8-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.8-3">This message is used to withdraw an offer
          already accepted by the Customer. <a href="#withdraw" class="xref">Figure 14</a>
          shows a typical usage of this message.<a href="#section-9.2.8-3" class="pilcrow">¶</a></p>
<span id="name-withdraw-flow-example"></span><div id="withdraw">
<figure id="figure-14">
            <div class="artwork art-text alignCenter" id="section-9.2.8-4.1">
<pre>
+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |============WITHDRAW(CPD)===========&gt;|
   |&lt;============PROCESSING==============|
   |&lt;===========ACK(Empty CPD)===========|
   |                                     |
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-withdraw-flow-example" class="selfRef">WITHDRAW Flow Example</a>
            </figcaption></figure>
</div>
<p id="section-9.2.8-5">The WITHDRAW message must include the same
          CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
          NONCE as those used when creating the order.<a href="#section-9.2.8-5" class="pilcrow">¶</a></p>
<p id="section-9.2.8-6">Upon receipt of a WITHDRAW message, the server checks whether an
          order matching the request is found. If an order is found, the state
          of the order is changed to "Cancelled", and an ACK message including
          an Empty CPD is returned to the requesting client. If no order is
          found, the server returns a FAIL message to the requesting
          client.<a href="#section-9.2.8-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="upd">
<section id="section-9.2.9">
          <h4 id="name-update">
<a href="#section-9.2.9" class="section-number selfRef">9.2.9. </a><a href="#name-update" class="section-name selfRef">UPDATE</a>
          </h4>
<p id="section-9.2.9-1">The format of the UPDATE message is shown below:<a href="#section-9.2.9-1" class="pilcrow">¶</a></p>
<div id="section-9.2.9-2">
<pre class="sourcecode lang-rbnf">
&lt;UPDATE Message&gt; ::= &lt;VERSION&gt;
                     &lt;METHOD_CODE&gt;
                     &lt;SEQUENCE_NUMBER&gt;
                     &lt;TRANSACTION_ID&gt;
                     &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                     &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                     &lt;NONCE&gt;
                     &lt;EXPECTED_RESPONSE_TIME&gt;
                     &lt;REQUESTED_CPD&gt;
                     [&lt;INFORMATION_ELEMENT&gt;...]
</pre><a href="#section-9.2.9-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.9-3">This message is sent by the CPNP client
          to update an existing service agreement (e.g., Accepted 
          CPD). The UPDATE message must include the same
          CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
          NONCE as those used when creating the order. The CPNP client
          includes a new service description (e.g., Updated CPD) that
          integrates the requested modifications. A new Transaction_ID must be
          assigned by the client.<a href="#section-9.2.9-3" class="pilcrow">¶</a></p>
<p id="section-9.2.9-4">Upon receipt of an UPDATE message, the server checks whether an
          order, having state "Completed", matches
          CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
          NONCE.<a href="#section-9.2.9-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.9-5.1">If no order is found, the CPNP server generates a FAIL error
              with the appropriate error code (<a href="#fail" class="xref">Section 9.2.10</a>).<a href="#section-9.2.9-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.9-5.2">
              <p id="section-9.2.9-5.2.1">If an order is found, the server checks whether it can honor
              the request:<a href="#section-9.2.9-5.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.9-5.2.2.1">A FAIL message is sent to the client if the server cannot
                  honor the request. The client may initiate a new PQO
                  negotiation cycle (that is, send a new UPDATE message).<a href="#section-9.2.9-5.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-9.2.9-5.2.2.2">
                  <p id="section-9.2.9-5.2.2.2.1">An OFFER message including the updated clauses (e.g.,
                  Updated CPD) is sent to the
                  client. For example, the server maintains an order for
                  provisioning a VPN service that connects sites A, B, and C.
                  If the client sends an UPDATE message to remove site C, only
                  sites A and B will be included in the OFFER sent by the
                  server to the requesting client.<a href="#section-9.2.9-5.2.2.2.1" class="pilcrow">¶</a></p>
<p id="section-9.2.9-5.2.2.2.2">Note that the cycle that is triggered by an
                  UPDATE message is also considered to be a negotiation
                  cycle.<a href="#section-9.2.9-5.2.2.2.2" class="pilcrow">¶</a></p>
</li>
              </ul>
</li>
          </ul>
<p id="section-9.2.9-6">A flow chart that illustrates the use of UPDATE operation is
          shown in <a href="#update" class="xref">Figure 15</a>.<a href="#section-9.2.9-6" class="pilcrow">¶</a></p>
<span id="name-update-flow-example"></span><div id="update">
<figure id="figure-15">
            <div class="artwork art-text alignCenter" id="section-9.2.9-7.1">
<pre>
+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |=========UPDATE(Requested CPD)======&gt;|
   |&lt;============PROCESSING==============|
   |&lt;=========OFFER(Updated CPD)=========|
   |=============PROCESSING=============&gt;|
   |==========ACCEPT(Updated CPD)=======&gt;|
   |&lt;==========ACK(Updated CPD)==========|
   |                                     |
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-update-flow-example" class="selfRef">UPDATE Flow Example</a>
            </figcaption></figure>
</div>
</section>
</div>
<div id="fail">
<section id="section-9.2.10">
          <h4 id="name-fail">
<a href="#section-9.2.10" class="section-number selfRef">9.2.10. </a><a href="#name-fail" class="section-name selfRef">FAIL</a>
          </h4>
<p id="section-9.2.10-1">The format of the FAIL message is shown below:<a href="#section-9.2.10-1" class="pilcrow">¶</a></p>
<div id="section-9.2.10-2">
<pre class="sourcecode lang-rbnf">
&lt;FAIL Message&gt; ::=  &lt;VERSION&gt;
                    &lt;METHOD_CODE&gt;
                    &lt;SEQUENCE_NUMBER&gt;
                    &lt;TRANSACTION_ID&gt;
                    &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                    &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                    &lt;STATUS_CODE&gt;
</pre><a href="#section-9.2.10-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.10-3">This message is sent in the following
          cases:<a href="#section-9.2.10-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.10-4.1">The server cannot honor an order received from the client
              (i.e., received in a QUOTATION or UPDATE request).<a href="#section-9.2.10-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.10-4.2">The server encounters an error when processing a CPNP request
              received from the client.<a href="#section-9.2.10-4.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.10-4.3">The client cannot grant more time to the server. This is a
              response to a time extension request carried in a PROCESSING
              message.<a href="#section-9.2.10-4.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-9.2.10-5">The status code indicates the error code. The following codes are
          supported:<a href="#section-9.2.10-5" class="pilcrow">¶</a></p>
<span id="name-fail-message-error-codes"></span><table class="center" id="table-4">
            <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-fail-message-error-codes" class="selfRef">FAIL Message Error Codes</a>
            </caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Status Code</th>
                <th class="text-left" rowspan="1" colspan="1">Error Code</th>
                <th class="text-left" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">Message Validation Error</td>
                <td class="text-left" rowspan="1" colspan="1">The message cannot be validated (see <a href="#validation" class="xref">Section 10</a>).</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">Authentication Required</td>
                <td class="text-left" rowspan="1" colspan="1">The request cannot be handled because authentication is required.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">Authorization Failed</td>
                <td class="text-left" rowspan="1" colspan="1">The request cannot be handled because authorization failed.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">4</td>
                <td class="text-left" rowspan="1" colspan="1">Administratively prohibited</td>
                <td class="text-left" rowspan="1" colspan="1">The request cannot be handled because of administrative policies.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">Out of Resources</td>
                <td class="text-left" rowspan="1" colspan="1">The request cannot be honored because resources (e.g., capacity) are insufficient.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">6</td>
                <td class="text-left" rowspan="1" colspan="1">Network Presence Error</td>
                <td class="text-left" rowspan="1" colspan="1">The request cannot be honored because there is no network presence.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">7</td>
                <td class="text-left" rowspan="1" colspan="1">More Time Rejected</td>
                <td class="text-left" rowspan="1" colspan="1">The request to extend the time for negotiation is rejected by the client.</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">8</td>
                <td class="text-left" rowspan="1" colspan="1">Unsupported Activation Type</td>
                <td class="text-left" rowspan="1" colspan="1">The request cannot be handled because the requested activation type is not
supported.</td>
              </tr>
            </tbody>
          </table>
</section>
</div>
<div id="activate">
<section id="section-9.2.11">
          <h4 id="name-activate">
<a href="#section-9.2.11" class="section-number selfRef">9.2.11. </a><a href="#name-activate" class="section-name selfRef">ACTIVATE</a>
          </h4>
<p id="section-9.2.11-1">The format of the ACTIVATE message is shown below:<a href="#section-9.2.11-1" class="pilcrow">¶</a></p>
<div id="section-9.2.11-2">
<pre class="sourcecode lang-rbnf">
&lt;ACTIVATE Message&gt; ::= &lt;VERSION&gt;
                       &lt;METHOD_CODE&gt;
                       &lt;SEQUENCE_NUMBER&gt;
                       &lt;TRANSACTION_ID&gt;
                       &lt;CUSTOMER_ORDER_IDENTIFIER&gt;
                       &lt;PROVIDER_ORDER_IDENTIFIER&gt;
                       &lt;NONCE&gt;
                       &lt;ACTIVATION_SCHEDULE&gt;
                       [&lt;INFORMATION_ELEMENT&gt;...]
</pre><a href="#section-9.2.11-2" class="pilcrow">¶</a>
</div>
<p id="section-9.2.11-3">This message is sent by the CPNP client
          to request the activation of an existing service agreement. The
          message must include the same CUSTOMER_ORDER_IDENTIFIER,
          PROVIDER_ORDER_IDENTIFIER, and NONCE as those used when creating
          the order. The CPNP client may include a schedule target for
          activating this order. A new Transaction_ID must be assigned by the
          client.<a href="#section-9.2.11-3" class="pilcrow">¶</a></p>
<p id="section-9.2.11-4">Upon receipt of an ACTIVATE message, the server checks whether an
          order, having state "Completed", matches
          CUSTOMER_ORDER_IDENTIFIER, PROVIDER_ORDER_IDENTIFIER, and
          NONCE.<a href="#section-9.2.11-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.11-5.1">If no completed order is found, the CPNP server generates a
              FAIL error with the appropriate error code (<a href="#fail" class="xref">Section 9.2.10</a>).<a href="#section-9.2.11-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-9.2.11-5.2">
              <p id="section-9.2.11-5.2.1">If an order is found, the server checks whether it can honor
              the request:<a href="#section-9.2.11-5.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.2.11-5.2.2.1">A FAIL message is sent to the client if the server cannot
                  honor the request (e.g., out of resources or explicit
                  activation wasn't negotiated with this client).<a href="#section-9.2.11-5.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-9.2.11-5.2.2.2">An ACK is sent to the client to confirm that the
                  immediate activation (or deactivation) of the order or its
                  successful scheduling if a non-null ACTIVATION_SCHEDULE was
                  included in the request. Note that setting
                  ACTIVATION_SCHEDULE to 0 in an ACTIVATE request has a
                  special meaning: it is used to request a deactivation of an
                  accepted order.<a href="#section-9.2.11-5.2.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
          </ul>
<p id="section-9.2.11-6"><a href="#activateex" class="xref">Figure 16</a> illustrates the use of the ACTIVATE
          operation.<a href="#section-9.2.11-6" class="pilcrow">¶</a></p>
<span id="name-activate-flow-example"></span><div id="activateex">
<figure id="figure-16">
            <div class="artwork art-text alignCenter" id="section-9.2.11-7.1">
<pre>
+------+                              +------+
|Client|                              |Server|
+------+                              +------+
   |================ACTIVATE()==========&gt;|
   |&lt;==============ACK()=================|
   |                                     |
</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
<a href="#name-activate-flow-example" class="selfRef">ACTIVATE Flow Example</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</section>
</div>
<div id="validation">
<section id="section-10">
      <h2 id="name-cpnp-message-validation">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-cpnp-message-validation" class="section-name selfRef">CPNP Message Validation</a>
      </h2>
<p id="section-10-1">Both the client and the server proceed with CPNP message validation. The
      following tables summarize the validation checks to be followed.<a href="#section-10-1" class="pilcrow">¶</a></p>
<section id="section-10.1">
        <h3 id="name-on-the-client-side-2">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-on-the-client-side-2" class="section-name selfRef">On the Client Side</a>
        </h3>
<span id="name-client-side-validation-chec"></span><table class="left" id="table-5">
          <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-client-side-validation-chec" class="selfRef">Client Side Validation Checks</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Operation</th>
              <th class="text-left" rowspan="1" colspan="1">Validation Checks</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PROCESSING</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier}
          must match an existing PQO with a state set to "PQOSent". The
          sequence number carried in the packet must be larger than the
          sequence number maintained by the client.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">OFFER</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier}
          must match an existing order with state set to "PQOSent", or {Source
          IP address, source port number, destination IP address, destination
          port number, Transaction-ID, Customer Order Identifier, Provider
          Order Identifier} must match an existing order with a state set to
          "ServerProcessing". The sequence number carried in the packet must
          be larger than the sequence number maintained by the client.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ACK (QUOTATION Transaction)</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier,
          Provider Order Identifier, Offered Connectivity Provisioning Document}
          must match an order with a state set to "AcceptSent". The sequence
          number carried in the packet must be larger than the sequence number
          maintained by the client.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ACK (UPDATE Transaction)</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier,
          Provider Order Identifier, Updated Connectivity Provisioning Document}
          must match an order with a state set to "AcceptSent". The sequence
          number carried in the packet must be larger than the sequence number
          maintained by the client.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ACK (WITHDRAW Transaction)</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier,
          Provider Order Identifier, Empty Connectivity Provisioning Document}
          must match an order with a state set to "Cancelled". The sequence
          number carried in the packet must be larger than the sequence number
          maintained by the client.</td>
            </tr>
          </tbody>
        </table>
</section>
<section id="section-10.2">
        <h3 id="name-on-the-server-side-2">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-on-the-server-side-2" class="section-name selfRef">On the Server Side</a>
        </h3>
<span id="name-server-side-validation-chec"></span><table class="left" id="table-6">
          <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-server-side-validation-chec" class="selfRef">Server Side Validation Checks</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Method</th>
              <th class="text-left" rowspan="1" colspan="1">Validation Checks</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">QUOTATION</td>
              <td class="text-left" rowspan="1" colspan="1">The source IP address passes existing access filters (if any).
          The sequence number carried in the packet must not be lower than the
          sequence number maintained by the server.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">PROCESSING</td>
              <td class="text-left" rowspan="1" colspan="1">The sequence number carried in the packet must be greater than
          the sequence number maintained by the server.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">CANCEL</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier}
          must match an order with state set to "PQOReceived" or
          "OfferProposed" or "ProcessingReceived" or "AcceptReceived". The
          sequence number carried in the packet must be greater than the
          sequence number maintained by the server.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ACCEPT</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier,
          Provider Order Identifier, Nonce, Offered Connectivity Provisioning
          Document} must match an order with state set to "OfferProposed" or
          "ProcessingReceived". The sequence number carried in the packet must
          be greater than the sequence number maintained by the server.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">FAIL</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier,
          Provider Order Identifier} must match an order with state set to
          "AwaitingProcessing" and for which a request to grant more time to
          process an offer was requested. The sequence number carried in the
          packet must be greater than the sequence number maintained by the
          server.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">DECLINE</td>
              <td class="text-left" rowspan="1" colspan="1">{Source IP address, source port number, destination IP address,
          destination port number, Transaction-ID, Customer Order Identifier,
          Provider Order Identifier, Nonce} must match an order with state set
          to "OfferProposed" or "ProcessingReceived". The sequence number
          carried in the packet must be greater than the sequence number
          maintained by the server.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">UPDATE</td>
              <td class="text-left" rowspan="1" colspan="1">The source IP address passes existing access filters (if any), and
          {Customer Order Identifier, Provider Order Identifier, Nonce} must
          match an existing order with state "Completed".</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">WITHDRAW</td>
              <td class="text-left" rowspan="1" colspan="1">The source IP address passes existing access filters (if any), and
          {Customer Order Identifier, Provider Order Identifier, Nonce} must
          match an existing order with state "Completed".</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">ACTIVATE</td>
              <td class="text-left" rowspan="1" colspan="1">The source IP address passes existing access filters (if any), and
          {Customer Order Identifier, Provider Order Identifier, Nonce} must
          match an existing order with a state of "Completed" and its
          activation procedure set to explicit.</td>
            </tr>
          </tbody>
        </table>
</section>
</section>
</div>
<div id="behavior">
<section id="section-11">
      <h2 id="name-theory-of-operation">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-theory-of-operation" class="section-name selfRef">Theory of Operation</a>
      </h2>
<p id="section-11-1">Both the CPNP client and server proceed with message validation checks as
      specified in <a href="#validation" class="xref">Section 10</a>.<a href="#section-11-1" class="pilcrow">¶</a></p>
<section id="section-11.1">
        <h3 id="name-client-behavior">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-client-behavior" class="section-name selfRef">Client Behavior</a>
        </h3>
<div id="creation">
<section id="section-11.1.1">
          <h4 id="name-order-negotiation-cycle">
<a href="#section-11.1.1" class="section-number selfRef">11.1.1. </a><a href="#name-order-negotiation-cycle" class="section-name selfRef">Order Negotiation Cycle</a>
          </h4>
<p id="section-11.1.1-1">To place a PQO, the client first
          initiates a local quotation order object identified by a unique
          identifier assigned by the client (Client Order Identifier). The
          state of the quotation order is set to "Created". The client then
          generates a QUOTATION request that includes the assigned
          identifier, possibly an expected response time, a Transaction-ID,
          and a requested service (e.g., Requested CPD). The client may include additional Information Elements
          such as Customer Description or Negotiation Options.<a href="#section-11.1.1-1" class="pilcrow">¶</a></p>
<p id="section-11.1.1-2">The client may be configured to not enforce negotiation checks on
          EXPECTED_OFFER_TIME; if so, the client should either not include
          the EXPECTED_RESPONSE_TIME attribute in the PQO or it should set 
          the attribute to infinite.<a href="#section-11.1.1-2" class="pilcrow">¶</a></p>
<p id="section-11.1.1-3">Once the request is sent to the server, the state of the request
          is set to "PQOSent", and if a response time is 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
          session entry details used to generate the QUOTATION request. The
          CPNP client must listen on the same port number that it used to send
          the QUOTATION request.<a href="#section-11.1.1-3" class="pilcrow">¶</a></p>
<p id="section-11.1.1-4">If no answer is received from the server before the
          retransmission timer expires (i.e., RETRANS_TIMER, <a href="#timers" class="xref">Section 8.5</a>), the client retransmits the message until
          maximum retry is reached (e.g., three times). The same sequence number
          is used for retransmitted packets.<a href="#section-11.1.1-4" class="pilcrow">¶</a></p>
<p id="section-11.1.1-5">If a FAIL message is received, the client may decide to issue
          another (corrected) request towards the same server, cancel the
          local order, or contact another server. The behavior of the client
          depends on the error code returned by the server in the FAIL
          message.<a href="#section-11.1.1-5" class="pilcrow">¶</a></p>
<p id="section-11.1.1-6">If a PROCESSING message matching the CPNP session entry (<a href="#session" class="xref">Section 8.3</a>) is received, the client updates the CPNP
          session entry with the PROVIDER_ORDER_IDENTIFIER information. If
          the client does not accept the expected offer time that may have
          been indicated in the PROCESSING message, the client may decide to
          cancel the quotation order. If the client accepts the
          EXPECTED_OFFER_TIME, it changes the state of the order to
          "ServerProcessing" and sets a timer to the value of
          EXPECTED_OFFER_TIME. If no offer is made before the timer expires,
          the client changes the state of the order to "Cancelled".<a href="#section-11.1.1-6" class="pilcrow">¶</a></p>
<p id="section-11.1.1-7">As a response to a time extension request (conveyed in a
          PROCESSING message that included a new EXPECTED_OFFER_TIME), the
          client may either grant this extension by issuing an ACK message or reject
          the time extension by issuing a FAIL message with a status code set to
          "More Time Rejected".<a href="#section-11.1.1-7" class="pilcrow">¶</a></p>
<p id="section-11.1.1-8">If an OFFER message matching the CPNP session entry is received,
          the client checks if a PROCESSING message having the same
          PROVIDER_ORDER_IDENTIFIER has been received from the server. If
          a PROCESSING message was already received for the same order, but the
          PROVIDER_ORDER_IDENTIFIER does not match the identifier included
          in the OFFER message, the client silently ignores the message. If a
          PROCESSING message with the same PROVIDER_ORDER_IDENTIFIER was
          already received and matches the CPNP transaction identifier, the
          client changes the state of the order to "OfferReceived" and sets a
          timer to the value of VALIDITY_OFFER_TIME indicated in the OFFER
          message.<a href="#section-11.1.1-8" class="pilcrow">¶</a></p>
<p id="section-11.1.1-9">If an offer is received from the server (i.e., as documented in
          an OFFER message), the client may accept or reject the offer. The
          client accepts the offer by generating an ACCEPT message that
          confirms that the client agrees to subscribe to the offer documented
          in the OFFER message; the state of the order is passed to
          "AcceptSent". The transaction is terminated if an ACK message is
          received from the server. If no ACK is received from the server, the
          client proceeds with the retransmission of the ACCEPT message until
          the maximum retry is reached (<a href="#retrans" class="xref">Section 11.4</a>).<a href="#section-11.1.1-9" class="pilcrow">¶</a></p>
<p id="section-11.1.1-10">The client may also decide to reject the offer by sending a
          DECLINE message. The state of the order is set by the client to
          "Cancelled". If an offer is not acceptable to the client, the client
          may decide to contact a new server or submit another order to the
          same server. Guidelines to issue an updated order or terminate the
          negotiation are specific to the client.<a href="#section-11.1.1-10" class="pilcrow">¶</a></p>
<p id="section-11.1.1-11">An order can be activated (or deactivated) using the ACTIVATE
          message or other accepted activation means (<span><a href="https://www.rfc-editor.org/rfc/rfc7297#section-3.11" class="relref">Section 3.11</a> of [<a href="#RFC7297" class="xref">RFC7297</a>]</span>).<a href="#section-11.1.1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="corw">
<section id="section-11.1.2">
          <h4 id="name-order-withdrawal-cycle">
<a href="#section-11.1.2" class="section-number selfRef">11.1.2. </a><a href="#name-order-withdrawal-cycle" class="section-name selfRef">Order Withdrawal Cycle</a>
          </h4>
<p id="section-11.1.2-1">A client may withdraw a completed order. This is achieved by
          issuing a WITHDRAW message. This message must include the Customer Order
          Identifier, Provider Order Identifier, and Nonce returned during the order
          negotiation cycle, as specified in <a href="#creation" class="xref">Section 11.1.1</a>.<a href="#section-11.1.2-1" class="pilcrow">¶</a></p>
<p id="section-11.1.2-2">If no ACK is received from the server, the client proceeds with
          the retransmission of the message. If no ACK is received after the
          maximum retry is exhausted, the client should log the information
          and must send an alarm to the administrator. If there is no specific
          instruction from the administrator, the client should schedule
          another Withdrawal cycle. The client must not retry this Withdrawal
          cycle more frequently than every 300 seconds and must not retry more
          frequently than every 60 seconds.<a href="#section-11.1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cordu">
<section id="section-11.1.3">
          <h4 id="name-order-update-cycle">
<a href="#section-11.1.3" class="section-number selfRef">11.1.3. </a><a href="#name-order-update-cycle" class="section-name selfRef">Order Update Cycle</a>
          </h4>
<p id="section-11.1.3-1">A client may update a completed order. This is achieved by
          issuing an UPDATE message. This message must include the Customer Order
          Identifier, Provider Order Identifier, and Nonce returned during the
          order negotiation cycle specified in <a href="#creation" class="xref">Section 11.1.1</a>. The client must include in the UPDATE
          message an Updated CPD with the requested changes.<a href="#section-11.1.3-1" class="pilcrow">¶</a></p>
<p id="section-11.1.3-2">The subsequent message exchange is similar to what is documented in
          <a href="#creation" class="xref">Section 11.1.1</a>.<a href="#section-11.1.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<section id="section-11.2">
        <h3 id="name-server-behavior">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-server-behavior" class="section-name selfRef">Server Behavior</a>
        </h3>
<div id="handling">
<section id="section-11.2.1">
          <h4 id="name-order-processing">
<a href="#section-11.2.1" class="section-number selfRef">11.2.1. </a><a href="#name-order-processing" class="section-name selfRef">Order Processing</a>
          </h4>
<p id="section-11.2.1-1">Upon receipt of a QUOTATION message from a client, the server
          sets a CPNP session, stores the Transaction-ID, and generates a Provider
          Order Identifier. Once preliminary validation checks are completed 
          (<a href="#validation" class="xref">Section 10</a>), the server may return a
          PROCESSING message to inform the client that the quotation order is
          received and it is under processing; the server may include an
          expected offer time to notify the client by when an offer will be
          proposed. An order with state "AwaitingProcessing" is created by the
          server. The server runs its decision-making process to decide which
          offer it can make to honor the received order. The offer should be
          made before the expected offer time expires.<a href="#section-11.2.1-1" class="pilcrow">¶</a></p>
<p id="section-11.2.1-2">If the server cannot make an offer, it sends backs a FAIL message
          with the appropriate error code (<a href="#fail" class="xref">Section 9.2.10</a>).<a href="#section-11.2.1-2" class="pilcrow">¶</a></p>
<p id="section-11.2.1-3">If the server requires more negotiation time, it must send a
          PROCESSING message with a new EXPECTED_OFFER_TIME. The client may
          grant this extension by issuing an ACK message or reject the time
          extension 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
          answer before the initial expected offer time; otherwise, the client
          will decline the quotation order.<a href="#section-11.2.1-3" class="pilcrow">¶</a></p>
<p id="section-11.2.1-4">If the server can honor the request, or if it can make an offer that
          meets only some of the requirements, it creates an OFFER message.
          The server must indicate the Transaction-ID, the Customer Order
          Identifier as indicated in the QUOTATION message, and the Provider
          Order Identifier generated for this order. The server must also
          include the Nonce and the offered service document (e.g., Offered
          CPD). The server includes an offer
          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
          validity time is initiated.<a href="#section-11.2.1-4" class="pilcrow">¶</a></p>
<p id="section-11.2.1-5">If the server determines that additional network resources from
          another Network Provider are needed to accommodate a quotation
          order, it will create child PQO(s) and will behave as a CPNP client
          to negotiate child PQO(s) with possible partnering Providers (see
          <a href="#child" class="xref">Figure 7</a>).<a href="#section-11.2.1-5" class="pilcrow">¶</a></p>
<p id="section-11.2.1-6">If no PROCESSING, ACCEPT, or DECLINE message is received before
          the expiry of the RETRANS_TIMER, the server resends the same offer
          to the client. This procedure is repeated until maximum retry is
          reached.<a href="#section-11.2.1-6" class="pilcrow">¶</a></p>
<p id="section-11.2.1-7">If an ACCEPT message is received before the offered validity time
          expires, the server proceeds with validation checks as specified in
          <a href="#validation" class="xref">Section 10</a>. The state of the corresponding
          order is passed to "AcceptReceived". The server sends back an ACK
          message to terminate the order processing cycle.<a href="#section-11.2.1-7" class="pilcrow">¶</a></p>
<p id="section-11.2.1-8">If a CANCEL or a DECLINE message is received, the server proceeds with
          the cancellation of the order. The state of the order is then passed
          to "Cancelled".<a href="#section-11.2.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sordw">
<section id="section-11.2.2">
          <h4 id="name-order-withdrawal">
<a href="#section-11.2.2" class="section-number selfRef">11.2.2. </a><a href="#name-order-withdrawal" class="section-name selfRef">Order Withdrawal</a>
          </h4>
<p id="section-11.2.2-1">A client may withdraw a completed order by issuing a WITHDRAW
          message. Upon receipt of a WITHDRAW message, the server proceeds
          with the validation checks, as specified in <a href="#validation" class="xref">Section 10</a>:<a href="#section-11.2.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11.2.2-2.1">If the checks fail, a FAIL message is sent back to the client
              with the appropriate error code (e.g., 1 (Message Validation
              Error), 2 (Authentication Required), or 3 (Authorization
              Failed)).<a href="#section-11.2.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-11.2.2-2.2">If the checks succeed, the server clears the clauses of the
              CPD, changes the state of the
              order to "Cancelled", and sends back an ACK message with an
              Empty CPD.<a href="#section-11.2.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="sordu">
<section id="section-11.2.3">
          <h4 id="name-order-update">
<a href="#section-11.2.3" class="section-number selfRef">11.2.3. </a><a href="#name-order-update" class="section-name selfRef">Order Update</a>
          </h4>
<p id="section-11.2.3-1">A client may update an order by issuing an UPDATE message. Upon
          receipt of an UPDATE message, the server proceeds with the
          validation checks as specified in <a href="#validation" class="xref">Section 10</a>:<a href="#section-11.2.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11.2.3-2.1">If the checks fail, a FAIL message is sent back to the client
              with the appropriate error code (e.g., 1 (Message Validation
              Error), 2 (Authentication Required), 3 (Authorization Failed),
              or 6 (Network Presence Error)).<a href="#section-11.2.3-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-11.2.3-2.2">The exchange of subsequent messages is similar to what is
              specified in <a href="#creation" class="xref">Section 11.1.1</a>. The server should
              generate a new Nonce value to be included in the offer made to
              the client.<a href="#section-11.2.3-2.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
<div id="sq_nu">
<section id="section-11.3">
        <h3 id="name-sequence-numbers">
<a href="#section-11.3" class="section-number selfRef">11.3. </a><a href="#name-sequence-numbers" class="section-name selfRef">Sequence Numbers</a>
        </h3>
<p id="section-11.3-1">In each transaction, sequence numbers are used to protect the
        transaction against replay attacks. Each communicating partner of the
        transaction maintains two sequence numbers, one for incoming packets
        and one for outgoing packets. When a partner receives a message, it
        will check whether the sequence number in the message is larger than
        the incoming sequence number maintained locally. If not, the message
        will be discarded. If the message is proved to be legitimate, the
        value of the incoming sequence number maintained locally will be
        replaced by the value of the sequence number in the message. When a
        partner sends out a message, it will insert the value of the outgoing
        sequence number into the message and increase the outgoing sequence
        number maintained locally by 1.<a href="#section-11.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="retrans">
<section id="section-11.4">
        <h3 id="name-message-retransmission">
<a href="#section-11.4" class="section-number selfRef">11.4. </a><a href="#name-message-retransmission" class="section-name selfRef">Message Retransmission</a>
        </h3>
<p id="section-11.4-1">If a transaction partner sends out a message and does not receive
        any expected reply before the retransmission timer expires (i.e.,
        RETRANS_TIMER), a transaction partner will try to retransmit the
        message. The procedure is reiterated until a maximum retry is reached
        (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
        retransmission timer will be disabled since no additional feedback is
        expected.<a href="#section-11.4-1" class="pilcrow">¶</a></p>
<p id="section-11.4-2">In addition, if the partner receives a retransmission of the last
        incoming packet it handled, the partner can resend the same answer to
        the incoming packet with a limited frequency.  If an answer cannot be 
        generated right after the request is received, the partner needs to
        generate a PROCESSING message as the answer.<a href="#section-11.4-2" class="pilcrow">¶</a></p>
<p id="section-11.4-3">To optimize message retransmission, a partner could also store the
        last incoming packet and the associated answer. Note that the times of
        retransmission could be decided by the local policy, and retransmission
        will not cause any change of sequence numbers.<a href="#section-11.4-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="og">
<section id="section-12">
      <h2 id="name-some-operational-guidelines">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-some-operational-guidelines" class="section-name selfRef">Some Operational Guidelines</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-cpnp-server-logging">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-cpnp-server-logging" class="section-name selfRef">CPNP Server Logging</a>
        </h3>
<p id="section-12.1-1">The CPNP server should be configurable to log various events and
        associated information. Such information may include the following:<a href="#section-12.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-12.1-2.1">Client's IP address<a href="#section-12.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-12.1-2.2">Any event change (e.g., new quotation order, offer sent, order
            confirmation, order cancellation, order withdrawal, etc.)<a href="#section-12.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-12.1-2.3">Timestamp<a href="#section-12.1-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-12.1-3">The exact logging details are deployment specific.<a href="#section-12.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-12.2">
        <h3 id="name-business-guidelines-and-obj">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-business-guidelines-and-obj" class="section-name selfRef">Business Guidelines and Objectives</a>
        </h3>
<p id="section-12.2-1">The CPNP server can operate in the following modes:<a href="#section-12.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-12.2-2">
          <dt id="section-12.2-2.1">Fully automated mode: </dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.2">The CPNP server
            is provisioned with a set of business guidelines and objectives
            that will be used as an input to the decision-making process. The
            CPNP server will service received orders that fall into these
            business guidelines; otherwise, requests will be escalated to an
            administrator that will formally validate or invalidate an order
            request. The set of policies to be configured to the CPNP server
            are specific to each administrative entity managing a CPNP
            server.<a href="#section-12.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-12.2-2.3">Administrative-based mode: </dt>
          <dd style="margin-left: 1.5em" id="section-12.2-2.4">This mode
            assumes some or all of the CPNP server's operations are subject to a
            formal administrative validation. CPNP events will trigger
            appropriate validation requests that will be forwarded to the
            contact person(s) or department that is responsible for
            validating the orders. Administrative validation messages are
            relayed using another protocol (e.g., SMTP) or a dedicated
            tool.<a href="#section-12.2-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-12.2-3">Business guidelines are local to each administrative entity.
        How validation requests are presented to an administrator are out of
        scope of this document; each administrative entity may decide the
        appropriate mechanism to enable for that purpose.<a href="#section-12.2-3" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="Security">
<section id="section-13">
      <h2 id="name-security-considerations">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-13-1">Means to defend the server against denial-of-service attacks must be
      enabled. For example, access control lists can be enforced on the
      client, the server, or the network in between to allow a trusted client
      to communicate with a trusted server.<a href="#section-13-1" class="pilcrow">¶</a></p>
<p id="section-13-2">The client and the server must be mutually authenticated.
      Authenticated encryption must be used for data confidentiality and
      message integrity.<a href="#section-13-2" class="pilcrow">¶</a></p>
<p id="section-13-3">The protocol does not provide security mechanisms to protect the
      confidentiality and integrity of the packets transported between the
      client and the server. An underlying security protocol such as (e.g.,
      Datagram Transport Layer Security (DTLS) <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span>,
      Transport Layer Security (TLS) <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>) must be
      used to protect the integrity and confidentiality of protocol messages.
      In this case, if it is possible to provide automated key management 
      (<span><a href="https://www.rfc-editor.org/rfc/rfc4107#section-2.1" class="relref">Section 2.1</a> of [<a href="#RFC4107" class="xref">RFC4107</a>]</span>)
      and associate each transaction with a different key, inter-transaction
      replay attacks can naturally be addressed. If the client and the server
      use a single key, an additional mechanism should be provided to protect against
      inter-transaction replay attacks between them. Clients must implement
      DTLS record replay detection (<span><a href="https://www.rfc-editor.org/rfc/rfc6347#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC6347" class="xref">RFC6347</a>]</span>) or an equivalent mechanism to protect against
      replay attacks.<a href="#section-13-3" class="pilcrow">¶</a></p>
<p id="section-13-4">DTLS and TLS with a cipher suite offering confidentiality protection
      and the guidance given in <span>[<a href="#RFC7525" class="xref">RFC7525</a>]</span> must be
      followed to avoid attacks on (D)TLS.<a href="#section-13-4" class="pilcrow">¶</a></p>
<p id="section-13-5">The client must silently discard CPNP responses received from unknown
      CPNP servers. The use of a randomly generated Transaction-ID makes it
      hard to forge a response from a server with a spoofed IP address
      belonging to a legitimate CPNP server. Furthermore, CPNP demands that
      messages from the server must include the correct identifiers of the
      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
      maintain the local identifier they assigned and the one assigned by the
      peer for a given order. Means to detect swapping of these identifiers
      (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 not assign a Provider agreement identifier that is equal
      to a Customer agreement identifier used by the CPNP client.<a href="#section-13-5" class="pilcrow">¶</a></p>
<p id="section-13-6">The Provider must enforce the means to protect privacy-related
      information included in the documents (see <a href="#cpd" class="xref">Section 8.7</a>)
      exchanged in CPNP messages <span>[<a href="#RFC6462" class="xref">RFC6462</a>]</span>. In
      particular, this information must not be revealed to external parties
      without the consent of Customers. Providers should enforce policies to
      make Customer fingerprinting difficult to achieve (e.g., in a recursion
      request). For more discussion about privacy, refer to <span>[<a href="#RFC6462" class="xref">RFC6462</a>]</span>
        <span>[<a href="#RFC6973" class="xref">RFC6973</a>]</span>.<a href="#section-13-6" class="pilcrow">¶</a></p>
<p id="section-13-7">The Nonce and the Transaction-ID attributes provide sufficient
      randomness and can effectively tolerate attacks raised by off-path
      adversaries, who do not have the capability of eavesdropping and
      intercepting the packets transported between the client and the server.
      Only authorized clients must be able to modify accepted CPNP orders. The
      use of a randomly generated Nonce by the server makes it hard to modify
      an agreement on behalf of a malicious third party.<a href="#section-13-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="IANA">
<section id="section-14">
      <h2 id="name-iana-considerations">
<a href="#section-14" class="section-number selfRef">14. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-14-1">This document has no IANA actions.<a href="#section-14-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-15">
      <h2 id="name-references">
<a href="#section-15" class="section-number selfRef">15. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-15.1">
        <h3 id="name-normative-references">
<a href="#section-15.1" class="section-number selfRef">15.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC3339">[RFC3339]</dt>
        <dd>
<span class="refAuthor">Klyne, G.</span><span class="refAuthor"> and C. Newman</span>, <span class="refTitle">"Date and Time on the Internet: Timestamps"</span>, <span class="seriesInfo">RFC 3339</span>, <span class="seriesInfo">DOI 10.17487/RFC3339</span>, <time datetime="2002-07" class="refDate">July 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3339">https://www.rfc-editor.org/info/rfc3339</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4086">[RFC4086]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span><span class="refAuthor">, Schiller, J.</span><span class="refAuthor">, and S. Crocker</span>, <span class="refTitle">"Randomness Requirements for Security"</span>, <span class="seriesInfo">BCP 106</span>, <span class="seriesInfo">RFC 4086</span>, <span class="seriesInfo">DOI 10.17487/RFC4086</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4086">https://www.rfc-editor.org/info/rfc4086</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5511">[RFC5511]</dt>
        <dd>
<span class="refAuthor">Farrel, A.</span>, <span class="refTitle">"Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"</span>, <span class="seriesInfo">RFC 5511</span>, <span class="seriesInfo">DOI 10.17487/RFC5511</span>, <time datetime="2009-04" class="refDate">April 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5511">https://www.rfc-editor.org/info/rfc5511</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6347">[RFC6347]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span><span class="refAuthor"> and N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security Version 1.2"</span>, <span class="seriesInfo">RFC 6347</span>, <span class="seriesInfo">DOI 10.17487/RFC6347</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7297">[RFC7297]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Jacquenet, C.</span><span class="refAuthor">, and N. Wang</span>, <span class="refTitle">"IP Connectivity Provisioning Profile (CPP)"</span>, <span class="seriesInfo">RFC 7297</span>, <span class="seriesInfo">DOI 10.17487/RFC7297</span>, <time datetime="2014-07" class="refDate">July 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7297">https://www.rfc-editor.org/info/rfc7297</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7525">[RFC7525]</dt>
        <dd>
<span class="refAuthor">Sheffer, Y.</span><span class="refAuthor">, Holz, R.</span><span class="refAuthor">, and P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-15.2">
        <h3 id="name-informative-references">
<a href="#section-15.2" class="section-number selfRef">15.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="AGAVE">[AGAVE]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Georgatsos, P.</span><span class="refAuthor">, Wang, N.</span><span class="refAuthor">, Griffin, D.</span><span class="refAuthor">, Pavlou, G.</span><span class="refAuthor">, Howarth, M.</span><span class="refAuthor">, and A. Elizondo</span>, <span class="refTitle">"The AGAVE Approach for Network Virtualization: Differentiated Services Delivery"</span>, <span class="refContent">Annals of Telecommunication, Volume 64, 277-288</span>, <span class="seriesInfo">DOI 10.1007/s12243-009-0103-4</span>, <time datetime="2009-04" class="refDate">April 2009</time>, <span>&lt;<a href="https://rd.springer.com/article/10.1007/s12243-009-0103-4">https://rd.springer.com/article/10.1007/s12243-009-0103-4</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.nguyen-rap-cops-sls">[COPS-SLS]</dt>
        <dd>
<span class="refAuthor">Nguyen, T.</span>, <span class="refTitle">"COPS Usage for SLS negotiation (COPS-SLS)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-nguyen-rap-cops-sls-03</span>, <time datetime="2002-07-05" class="refDate">5 July 2002</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-nguyen-rap-cops-sls-03">https://tools.ietf.org/html/draft-nguyen-rap-cops-sls-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.itsumo-dsnp">[DSNP]</dt>
        <dd>
<span class="refAuthor">Chen, J.</span>, <span class="refTitle">"Dynamic Service Negotiation Protocol (DSNP)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-itsumo-dsnp-03</span>, <time datetime="2006-03-02" class="refDate">2 March 2006</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-itsumo-dsnp-03">https://tools.ietf.org/html/draft-itsumo-dsnp-03</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="ETICS">[ETICS]</dt>
        <dd>
<span class="refAuthor">EU FP7 ETICS Project</span>, <span class="refTitle">"Economics and Technologies of Inter-Carrier Services"</span>, <time datetime="2014-01" class="refDate">January 2014</time>, <span>&lt;<a href="https://cordis.europa.eu/project/id/248567">https://cordis.europa.eu/project/id/248567</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-opsawg-l2nm">[L2VPN-NETWORK-YANG]</dt>
        <dd>
<span class="refAuthor">Barguil, S.</span><span class="refAuthor">, Dios, O. G. D.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Munoz, L. A.</span><span class="refAuthor">, Jalil, L.</span><span class="refAuthor">, and J. Ma</span>, <span class="refTitle">"A Layer 2 VPN Network YANG Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-opsawg-l2nm-00</span>, <time datetime="2020-07-02" class="refDate">2 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-00">https://tools.ietf.org/html/draft-ietf-opsawg-l2nm-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-opsawg-l3sm-l3nm">[L3VPN-NETWORK-YANG]</dt>
        <dd>
<span class="refAuthor">Barguil, S.</span><span class="refAuthor">, Dios, O. G. D.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Munoz, L. A.</span><span class="refAuthor">, and A. Aguado</span>, <span class="refTitle">"A Layer 3 VPN Network YANG Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-opsawg-l3sm-l3nm-05</span>, <time datetime="2020-10-16" class="refDate">16 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05">https://tools.ietf.org/html/draft-ietf-opsawg-l3sm-l3nm-05</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.boucadair-lisp-idr-ms-discovery">[LISP-MS-DISCOVERY]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor"> and C. Jacquenet</span>, <span class="refTitle">"LISP Mapping Service Discovery at Large"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-boucadair-lisp-idr-ms-discovery-01</span>, <time datetime="2016-03-09" class="refDate">9 March 2016</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-boucadair-lisp-idr-ms-discovery-01">https://tools.ietf.org/html/draft-boucadair-lisp-idr-ms-discovery-01</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.geng-netslices-architecture">[NETSLICES-ARCH]</dt>
        <dd>
<span class="refAuthor">Geng, L.</span><span class="refAuthor">, Dong, J.</span><span class="refAuthor">, Bryant, S.</span><span class="refAuthor">, Makhijani, K.</span><span class="refAuthor">, Galis, A.</span><span class="refAuthor">, Foy, X. D.</span><span class="refAuthor">, and S. Kuklinski</span>, <span class="refTitle">"Network Slicing Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-geng-netslices-architecture-02</span>, <time datetime="2017-07-03" class="refDate">3 July 2017</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-geng-netslices-architecture-02">https://tools.ietf.org/html/draft-geng-netslices-architecture-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2782">[RFC2782]</dt>
        <dd>
<span class="refAuthor">Gulbrandsen, A.</span><span class="refAuthor">, Vixie, P.</span><span class="refAuthor">, and L. Esibov</span>, <span class="refTitle">"A DNS RR for specifying the location of services (DNS SRV)"</span>, <span class="seriesInfo">RFC 2782</span>, <span class="seriesInfo">DOI 10.17487/RFC2782</span>, <time datetime="2000-02" class="refDate">February 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2782">https://www.rfc-editor.org/info/rfc2782</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3084">[RFC3084]</dt>
        <dd>
<span class="refAuthor">Chan, K.</span><span class="refAuthor">, Seligson, J.</span><span class="refAuthor">, Durham, D.</span><span class="refAuthor">, Gai, S.</span><span class="refAuthor">, McCloghrie, K.</span><span class="refAuthor">, Herzog, S.</span><span class="refAuthor">, Reichmeyer, F.</span><span class="refAuthor">, Yavatkar, R.</span><span class="refAuthor">, and A. Smith</span>, <span class="refTitle">"COPS Usage for Policy Provisioning (COPS-PR)"</span>, <span class="seriesInfo">RFC 3084</span>, <span class="seriesInfo">DOI 10.17487/RFC3084</span>, <time datetime="2001-03" class="refDate">March 2001</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3084">https://www.rfc-editor.org/info/rfc3084</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4026">[RFC4026]</dt>
        <dd>
<span class="refAuthor">Andersson, L.</span><span class="refAuthor"> and T. Madsen</span>, <span class="refTitle">"Provider Provisioned Virtual Private Network (VPN) Terminology"</span>, <span class="seriesInfo">RFC 4026</span>, <span class="seriesInfo">DOI 10.17487/RFC4026</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4026">https://www.rfc-editor.org/info/rfc4026</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4107">[RFC4107]</dt>
        <dd>
<span class="refAuthor">Bellovin, S.</span><span class="refAuthor"> and R. Housley</span>, <span class="refTitle">"Guidelines for Cryptographic Key Management"</span>, <span class="seriesInfo">BCP 107</span>, <span class="seriesInfo">RFC 4107</span>, <span class="seriesInfo">DOI 10.17487/RFC4107</span>, <time datetime="2005-06" class="refDate">June 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4107">https://www.rfc-editor.org/info/rfc4107</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4176">[RFC4176]</dt>
        <dd>
<span class="refAuthor">El Mghazli, Y., Ed.</span><span class="refAuthor">, Nadeau, T.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, Chan, K.</span><span class="refAuthor">, and A. Gonguet</span>, <span class="refTitle">"Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management"</span>, <span class="seriesInfo">RFC 4176</span>, <span class="seriesInfo">DOI 10.17487/RFC4176</span>, <time datetime="2005-10" class="refDate">October 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4176">https://www.rfc-editor.org/info/rfc4176</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6125">[RFC6125]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and J. Hodges</span>, <span class="refTitle">"Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 6125</span>, <span class="seriesInfo">DOI 10.17487/RFC6125</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6241">[RFC6241]</dt>
        <dd>
<span class="refAuthor">Enns, R., Ed.</span><span class="refAuthor">, Bjorklund, M., Ed.</span><span class="refAuthor">, Schoenwaelder, J., Ed.</span><span class="refAuthor">, and A. Bierman, Ed.</span>, <span class="refTitle">"Network Configuration Protocol (NETCONF)"</span>, <span class="seriesInfo">RFC 6241</span>, <span class="seriesInfo">DOI 10.17487/RFC6241</span>, <time datetime="2011-06" class="refDate">June 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6241">https://www.rfc-editor.org/info/rfc6241</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6462">[RFC6462]</dt>
        <dd>
<span class="refAuthor">Cooper, A.</span>, <span class="refTitle">"Report from the Internet Privacy Workshop"</span>, <span class="seriesInfo">RFC 6462</span>, <span class="seriesInfo">DOI 10.17487/RFC6462</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6462">https://www.rfc-editor.org/info/rfc6462</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6574">[RFC6574]</dt>
        <dd>
<span class="refAuthor">Tschofenig, H.</span><span class="refAuthor"> and J. Arkko</span>, <span class="refTitle">"Report from the Smart Object Workshop"</span>, <span class="seriesInfo">RFC 6574</span>, <span class="seriesInfo">DOI 10.17487/RFC6574</span>, <time datetime="2012-04" class="refDate">April 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6574">https://www.rfc-editor.org/info/rfc6574</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6770">[RFC6770]</dt>
        <dd>
<span class="refAuthor">Bertrand, G., Ed.</span><span class="refAuthor">, Stephan, E.</span><span class="refAuthor">, Burbridge, T.</span><span class="refAuthor">, Eardley, P.</span><span class="refAuthor">, Ma, K.</span><span class="refAuthor">, and G. Watson</span>, <span class="refTitle">"Use Cases for Content Delivery Network Interconnection"</span>, <span class="seriesInfo">RFC 6770</span>, <span class="seriesInfo">DOI 10.17487/RFC6770</span>, <time datetime="2012-11" class="refDate">November 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6770">https://www.rfc-editor.org/info/rfc6770</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6793">[RFC6793]</dt>
        <dd>
<span class="refAuthor">Vohra, Q.</span><span class="refAuthor"> and E. Chen</span>, <span class="refTitle">"BGP Support for Four-Octet Autonomous System (AS) Number Space"</span>, <span class="seriesInfo">RFC 6793</span>, <span class="seriesInfo">DOI 10.17487/RFC6793</span>, <time datetime="2012-12" class="refDate">December 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6793">https://www.rfc-editor.org/info/rfc6793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6830">[RFC6830]</dt>
        <dd>
<span class="refAuthor">Farinacci, D.</span><span class="refAuthor">, Fuller, V.</span><span class="refAuthor">, Meyer, D.</span><span class="refAuthor">, and D. Lewis</span>, <span class="refTitle">"The Locator/ID Separation Protocol (LISP)"</span>, <span class="seriesInfo">RFC 6830</span>, <span class="seriesInfo">DOI 10.17487/RFC6830</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6830">https://www.rfc-editor.org/info/rfc6830</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6973">[RFC6973]</dt>
        <dd>
<span class="refAuthor">Cooper, A.</span><span class="refAuthor">, Tschofenig, H.</span><span class="refAuthor">, Aboba, B.</span><span class="refAuthor">, Peterson, J.</span><span class="refAuthor">, Morris, J.</span><span class="refAuthor">, Hansen, M.</span><span class="refAuthor">, and R. Smith</span>, <span class="refTitle">"Privacy Considerations for Internet Protocols"</span>, <span class="seriesInfo">RFC 6973</span>, <span class="seriesInfo">DOI 10.17487/RFC6973</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6973">https://www.rfc-editor.org/info/rfc6973</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7049">[RFC7049]</dt>
        <dd>
<span class="refAuthor">Bormann, C.</span><span class="refAuthor"> and P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">RFC 7049</span>, <span class="seriesInfo">DOI 10.17487/RFC7049</span>, <time datetime="2013-10" class="refDate">October 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7049">https://www.rfc-editor.org/info/rfc7049</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7149">[RFC7149]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor"> and C. Jacquenet</span>, <span class="refTitle">"Software-Defined Networking: A Perspective from within a Service Provider Environment"</span>, <span class="seriesInfo">RFC 7149</span>, <span class="seriesInfo">DOI 10.17487/RFC7149</span>, <time datetime="2014-03" class="refDate">March 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7149">https://www.rfc-editor.org/info/rfc7149</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7215">[RFC7215]</dt>
        <dd>
<span class="refAuthor">Jakab, L.</span><span class="refAuthor">, Cabellos-Aparicio, A.</span><span class="refAuthor">, Coras, F.</span><span class="refAuthor">, Domingo-Pascual, J.</span><span class="refAuthor">, and D. Lewis</span>, <span class="refTitle">"Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations"</span>, <span class="seriesInfo">RFC 7215</span>, <span class="seriesInfo">DOI 10.17487/RFC7215</span>, <time datetime="2014-04" class="refDate">April 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7215">https://www.rfc-editor.org/info/rfc7215</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7491">[RFC7491]</dt>
        <dd>
<span class="refAuthor">King, D.</span><span class="refAuthor"> and A. Farrel</span>, <span class="refTitle">"A PCE-Based Architecture for Application-Based Network Operations"</span>, <span class="seriesInfo">RFC 7491</span>, <span class="seriesInfo">DOI 10.17487/RFC7491</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7491">https://www.rfc-editor.org/info/rfc7491</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8040">[RFC8040]</dt>
        <dd>
<span class="refAuthor">Bierman, A.</span><span class="refAuthor">, Bjorklund, M.</span><span class="refAuthor">, and K. Watsen</span>, <span class="refTitle">"RESTCONF Protocol"</span>, <span class="seriesInfo">RFC 8040</span>, <span class="seriesInfo">DOI 10.17487/RFC8040</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8040">https://www.rfc-editor.org/info/rfc8040</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8299">[RFC8299]</dt>
        <dd>
<span class="refAuthor">Wu, Q., Ed.</span><span class="refAuthor">, Litkowski, S.</span><span class="refAuthor">, Tomotaki, L.</span><span class="refAuthor">, and K. Ogaki</span>, <span class="refTitle">"YANG Data Model for L3VPN Service Delivery"</span>, <span class="seriesInfo">RFC 8299</span>, <span class="seriesInfo">DOI 10.17487/RFC8299</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8299">https://www.rfc-editor.org/info/rfc8299</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8309">[RFC8309]</dt>
        <dd>
<span class="refAuthor">Wu, Q.</span><span class="refAuthor">, Liu, W.</span><span class="refAuthor">, and A. Farrel</span>, <span class="refTitle">"Service Models Explained"</span>, <span class="seriesInfo">RFC 8309</span>, <span class="seriesInfo">DOI 10.17487/RFC8309</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8309">https://www.rfc-editor.org/info/rfc8309</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8329">[RFC8329]</dt>
        <dd>
<span class="refAuthor">Lopez, D.</span><span class="refAuthor">, Lopez, E.</span><span class="refAuthor">, Dunbar, L.</span><span class="refAuthor">, Strassner, J.</span><span class="refAuthor">, and R. Kumar</span>, <span class="refTitle">"Framework for Interface to Network Security Functions"</span>, <span class="seriesInfo">RFC 8329</span>, <span class="seriesInfo">DOI 10.17487/RFC8329</span>, <time datetime="2018-02" class="refDate">February 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8329">https://www.rfc-editor.org/info/rfc8329</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8466">[RFC8466]</dt>
        <dd>
<span class="refAuthor">Wen, B.</span><span class="refAuthor">, Fioccola, G., Ed.</span><span class="refAuthor">, Xie, C.</span><span class="refAuthor">, and L. Jalil</span>, <span class="refTitle">"A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery"</span>, <span class="seriesInfo">RFC 8466</span>, <span class="seriesInfo">DOI 10.17487/RFC8466</span>, <time datetime="2018-10" class="refDate">October 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8466">https://www.rfc-editor.org/info/rfc8466</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8597">[RFC8597]</dt>
        <dd>
<span class="refAuthor">Contreras, LM.</span><span class="refAuthor">, Bernardos, CJ.</span><span class="refAuthor">, Lopez, D.</span><span class="refAuthor">, Boucadair, M.</span><span class="refAuthor">, and P. Iovanna</span>, <span class="refTitle">"Cooperating Layered Architecture for Software-Defined Networking (CLAS)"</span>, <span class="seriesInfo">RFC 8597</span>, <span class="seriesInfo">DOI 10.17487/RFC8597</span>, <time datetime="2019-05" class="refDate">May 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8597">https://www.rfc-editor.org/info/rfc8597</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RNAP">[RNAP]</dt>
        <dd>
<span class="refAuthor">Wang, X.</span>, <span class="refTitle">"A Resource Negotiation and Pricing Protocol (RNAP)"</span>, <span>&lt;<a href="http://www.cs.columbia.edu/~xinwang/public/projects/protocol.html">http://www.cs.columbia.edu/~xinwang/public/projects/protocol.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SNAP">[SNAP]</dt>
        <dd>
<span class="refAuthor">Czajkowski, K.</span><span class="refAuthor">, Foster, I.</span><span class="refAuthor">, Kesselman, C.</span><span class="refAuthor">, Sander, V.</span><span class="refAuthor">, and S. Tuecke</span>, <span class="refTitle">"SNAP: A Protocol for Negotiating Service Level Agreements and Coordinating Resource Management in Distributed Systems"</span>, <span class="seriesInfo">DOI 10.1.1.19.5907</span>, <time datetime="2002" class="refDate">2002</time>, <span>&lt;<a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5907">http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.19.5907</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SrNP">[SrNP]</dt>
        <dd>
<span class="refAuthor">Georgatsos, P.</span><span class="refAuthor"> and G. Giannakopoulos</span>, <span class="refTitle">"Service Negotiation Protocol (SrNP)"</span>, <span>&lt;<a href="https://www.ist-tequila.org/presentations/srnp-pipcm.pdf">https://www.ist-tequila.org/presentations/srnp-pipcm.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.contreras-teas-slice-nbi">[TEAS-SLICE-NBI]</dt>
      <dd>
<span class="refAuthor">Contreras, L. M.</span><span class="refAuthor">, Homma, S.</span><span class="refAuthor">, and J. A. Ordonez-Lucena</span>, <span class="refTitle">"Considerations for defining a Transport Slice NBI"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-contreras-teas-slice-nbi-02</span>, <time datetime="2020-07-13" class="refDate">13 July 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-contreras-teas-slice-nbi-02">https://tools.ietf.org/html/draft-contreras-teas-slice-nbi-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">Thanks to <span class="contact-name">Diego R. Lopez</span>, 
      <span class="contact-name">Adrian Farrel</span>, <span class="contact-name">Éric Vyncke</span>, 
      <span class="contact-name">Eric Kline</span>, and <span class="contact-name">Benjamin Kaduk</span> for the comments.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">Thanks to those that reviewed this document for publication
      in the Independent Stream.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">Special thanks to <span class="contact-name">Luis Miguel Contreras Murillo</span> for the detailed
      review.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mohamed Boucadair (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left">
<span class="postal-code">35000</span> <span class="locality">Rennes</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mohamed.boucadair@orange.com" class="email">mohamed.boucadair@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Christian Jacquenet</span></div>
<div dir="auto" class="left"><span class="org">Orange</span></div>
<div dir="auto" class="left">
<span class="postal-code">35000</span> <span class="locality">Rennes</span>
</div>
<div dir="auto" class="left"><span class="country-name">France</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:christian.jacquenet@orange.com" class="email">christian.jacquenet@orange.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Dacheng Zhang</span></div>
<div dir="auto" class="left"><span class="org">Huawei Technologies</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:dacheng.zhang@huawei.com" class="email">dacheng.zhang@huawei.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Panos Georgatsos</span></div>
<div dir="auto" class="left"><span class="org">Centre for Research and Innovation Hellas</span></div>
<div dir="auto" class="left"><span class="street-address">78, Filikis Etairias str.</span></div>
<div dir="auto" class="left">
<span class="postal-code">38334</span> <span class="locality">Volos</span>
</div>
<div dir="auto" class="left"><span class="country-name">Greece</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+302421306070" class="tel">+302421306070</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:pgeorgat@gmail.com" class="email">pgeorgat@gmail.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>