File: rfc8797.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 (2093 lines) | stat: -rw-r--r-- 79,637 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 8797: Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1</title>
<meta content="Charles Lever" name="author">
<meta content="
       
This document specifies the format of
Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data
exchanged between RPC-over-RDMA version 1 peers
as part of establishing a connection.
The addition of the Private Data payload specified in this document
is an optional extension
that does not alter the RPC-over-RDMA version 1 protocol.
This document updates RFC 8166.
 
    " name="description">
<meta content="xml2rfc 2.46.0" name="generator">
<meta content="NFS-over-RDMA" name="keyword">
<meta content="8797" name="rfc.number">
<link href="rfc8797.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 {
  background-color: #f9f9f9;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8797" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rpcrdma-cm-pvt-data-08" 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 8797</td>
<td class="center">RPC-over-RDMA CM Private Data</td>
<td class="right">June 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Lever</td>
<td class="center">Standards Track</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">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8797" class="eref">8797</a></dd>
<dt class="label-updates">Updates:</dt>
<dd class="updates">
<a href="https://www.rfc-editor.org/rfc/rfc8166" class="eref">8166</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-06" class="published">June 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">C. Lever</div>
<div class="org">Oracle</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8797</h1>
<h1 id="title">Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data for RPC-over-RDMA Version 1</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
This document specifies the format of
Remote Direct Memory Access - Connection Manager (RDMA-CM) Private Data
exchanged between RPC-over-RDMA version 1 peers
as part of establishing a connection.
The addition of the Private Data payload specified in this document
is an optional extension
that does not alter the RPC-over-RDMA version 1 protocol.
This document updates RFC 8166.<a href="#section-abstract-1" 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 is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in 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/rfc8797">https://www.rfc-editor.org/info/rfc8797</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. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<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="compact ulEmpty toc">
<li class="compact ulEmpty 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="compact ulEmpty 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-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-advertised-transport-proper" class="xref">Advertised Transport Properties</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-inline-threshold-size" class="xref">Inline Threshold Size</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-remote-invalidation" class="xref">Remote Invalidation</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty 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-private-data-message-format" class="xref">Private Data Message Format</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-using-the-r-field" class="xref">Using the R Field</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-send-and-receive-size-value" class="xref">Send and Receive Size Values</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty 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-interoperability-considerat" class="xref">Interoperability Considerations</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty toc" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-interoperability-with-rpc-o" class="xref">Interoperability with RPC-over-RDMA Version 1 Implementations</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty toc" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-interoperability-amongst-rd" class="xref">Interoperability amongst RDMA Transports</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty 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-updating-the-message-format" class="xref">Updating the Message Format</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty 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-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty 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-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty 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-guidance-for-designated-exp" class="xref">Guidance for Designated Experts</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty 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-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="compact ulEmpty toc">
<li class="compact ulEmpty 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-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact ulEmpty 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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact ulEmpty toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="section_A4741DA2-FF86-4A9D-907B-8A73D53C7148">
<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">
The RPC-over-RDMA version 1 transport protocol
<span>[<a href="#RFC8166" class="xref">RFC8166</a>]</span>
enables payload data transfer using
Remote Direct Memory Access (RDMA)
for upper-layer protocols based on Remote Procedure Calls (RPCs)
<span>[<a href="#RFC5531" class="xref">RFC5531</a>]</span>.
The terms "Remote Direct Memory Access" (RDMA) and
"Direct Data Placement" (DDP) are introduced in
<span>[<a href="#RFC5040" class="xref">RFC5040</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
The two most immediate shortcomings
of RPC-over-RDMA version 1 are as follows:<a href="#section-1-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-1-3">
        <li id="section-1-3.1">
          <p id="section-1-3.1.1">
Setting up an RDMA data transfer (via RDMA Read or Write) can be costly.
The small default size of messages transmitted using RDMA Send
forces the use of RDMA Read or Write operations
even for relatively small messages and data payloads.<a href="#section-1-3.1.1" class="pilcrow">¶</a></p>
<p id="section-1-3.1.2">
The original specification of RPC-over-RDMA version 1 provided
an out-of-band protocol for passing inline threshold values
between connected peers
<span>[<a href="#RFC5666" class="xref">RFC5666</a>]</span>.
However,
<span>[<a href="#RFC8166" class="xref">RFC8166</a>]</span>
eliminated support for this protocol, making it unavailable for this purpose.<a href="#section-1-3.1.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-1-3.2">
Unlike most other contemporary RDMA-enabled storage protocols,
there is no facility in RPC-over-RDMA version 1
that enables the use of remote invalidation
<span>[<a href="#RFC5042" class="xref">RFC5042</a>]</span>.<a href="#section-1-3.2" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-1-4">
Each RPC-over-RDMA version 1 Transport Header follows the
External Data Representation (XDR) definition
<span>[<a href="#RFC4506" class="xref">RFC4506</a>]</span>
specified in <span>[<a href="#RFC8166" class="xref">RFC8166</a>]</span>.
However, RPC-over-RDMA version 1
has no means of extending this definition
in such a way that interoperability with existing implementations is preserved.
As a result, an out-of-band mechanism is needed
to help relieve these constraints
for existing RPC-over-RDMA version 1 implementations.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">
This document specifies a simple, non-XDR-based message format
designed to be passed between RPC-over-RDMA version 1 peers
at the time each RDMA transport connection is first established.
The mechanism assumes that the underlying RDMA transport has a
Private Data field that is passed between peers at connection time,
such as is present in the Marker PDU Aligned Framing (MPA) protocol 
(described in <span><a href="https://www.rfc-editor.org/rfc/rfc5044#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC5044" class="xref">RFC5044</a>]</span>
and extended in <span>[<a href="#RFC6581" class="xref">RFC6581</a>]</span>) or the InfiniBand Connection Manager
<span>[<a href="#IBA" class="xref">IBA</a>]</span>.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">
To enable current RPC-over-RDMA version 1 implementations
to interoperate with implementations that support
the message format described in this document,
implementation of the Private Data exchange is <span class="bcp14">OPTIONAL</span>.
When Private Data has been successfully exchanged,
peers may choose to perform extended RDMA semantics.
However, this exchange 
does not alter the XDR definition specified in
<span>[<a href="#RFC8166" class="xref">RFC8166</a>]</span>.<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">
The message format is intended to be further extensible
within the normal scope of such IETF work
(see
<a href="#section_96A18D5A-2AE4-490D-B140-B964302BF1DF" class="xref">Section 6</a>
for further details).
<a href="#section_8701C122-F206-4F87-8FA6-62F1CD648A14" class="xref">Section 8</a>
of this document defines an IANA registry for this purpose.
In addition, interoperation between
implementations of RPC-over-RDMA version 1 that present this message format to peers
and those that do not recognize this message format is guaranteed.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="section_6E4898D3-A2A9-47FA-9CBD-069328E610E4">
<section id="section-2">
      <h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
      </h2>
<p id="section-2-1">The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
       "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>",
       "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>",
       "<span class="bcp14">SHOULD NOT</span>",
       "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
       "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document
       are to be interpreted as described in BCP 14
       <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only
       when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="section_D6ED5D4A-E123-4DDD-B65F-733F2B377679">
<section id="section-3">
      <h2 id="name-advertised-transport-proper">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-advertised-transport-proper" class="section-name selfRef">Advertised Transport Properties</a>
      </h2>
<div id="section_0F60CBDD-8A7E-4B41-B193-18C04201DB3E">
<section id="section-3.1">
        <h3 id="name-inline-threshold-size">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-inline-threshold-size" class="section-name selfRef">Inline Threshold Size</a>
        </h3>
<p id="section-3.1-1">
<span><a href="https://www.rfc-editor.org/rfc/rfc8166#section-3.3.2" class="relref">Section 3.3.2</a> of [<a href="#RFC8166" class="xref">RFC8166</a>]</span>
defines the term "inline threshold".
An inline threshold is the maximum number of bytes that
can be transmitted using one RDMA Send and one RDMA Receive.
There are a pair of inline thresholds for a connection:
a client-to-server threshold and a server-to-client threshold.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2">
If an incoming RDMA message exceeds the size
of a receiver's inline threshold,
the Receive operation fails
and
the RDMA provider typically terminates the connection.
To convey an RPC message larger than the receiver's inline threshold
without risking receive failure,
a sender must use explicit RDMA data transfer operations,
which are more expensive than an RDMA Send.
See Sections <a href="https://www.rfc-editor.org/rfc/rfc8166#section-3.3" class="relref">3.3</a> and <a href="https://www.rfc-editor.org/rfc/rfc8166#section-3.5" class="relref">3.5</a> of <span>[<a href="#RFC8166" class="xref">RFC8166</a>]</span>
for a complete discussion.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.1-3">
The default value of inline thresholds for RPC-over-RDMA version 1
connections is 1024 bytes (as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8166#section-3.3.3" class="relref">Section 3.3.3</a> of [<a href="#RFC8166" class="xref">RFC8166</a>]</span>).
This value is adequate for nearly all NFS version 3 procedures.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">
NFS version 4 COMPOUND operations
<span>[<a href="#RFC7530" class="xref">RFC7530</a>]</span>
are larger on average
than NFS version 3 procedures
<span>[<a href="#RFC1813" class="xref">RFC1813</a>]</span>,
forcing clients to use explicit RDMA operations
for frequently issued requests such as LOOKUP and GETATTR.
The use of RPCSEC_GSS security also increases the average size
of RPC messages,
due to the larger size of RPCSEC_GSS credential material
included in RPC headers
<span>[<a href="#RFC7861" class="xref">RFC7861</a>]</span>.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">
If a sender and receiver could somehow agree on larger inline thresholds,
frequently used RPC transactions avoid the cost of explicit RDMA operations.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="section_F82BDC05-F8A6-478C-A02C-BC308EE75A18">
<section id="section-3.2">
        <h3 id="name-remote-invalidation">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-remote-invalidation" class="section-name selfRef">Remote Invalidation</a>
        </h3>
<p id="section-3.2-1">
After an RDMA data transfer operation completes,
an RDMA consumer can request
that its peer's RDMA Network Interface Card (RNIC)
invalidate the Steering Tag (STag)
associated with the data transfer
<span>[<a href="#RFC5042" class="xref">RFC5042</a>]</span>.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">
An RDMA consumer requests remote invalidation by posting
an RDMA Send with Invalidate operation
in place of an RDMA Send operation.
Each RDMA Send with Invalidate carries one STag to invalidate.
The receiver of an RDMA Send with Invalidate performs the
requested invalidation and then reports that invalidation
as part of the completion of a waiting Receive operation.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">
If both peers support remote invalidation,
an RPC-over-RDMA responder might use remote invalidation
when replying to an RPC request that provided chunks.
Because one of the chunks has already been invalidated,
finalizing the results of the RPC is made simpler and faster.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<p id="section-3.2-4">
However, there are some important caveats that contraindicate
the blanket use of remote invalidation:<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-5.1">
Remote invalidation is not supported by all RNICs.<a href="#section-3.2-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-5.2">
Not all RPC-over-RDMA responder implementations can generate
RDMA Send with Invalidate operations.<a href="#section-3.2-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-5.3">
Not all RPC-over-RDMA requester implementations can recognize
when remote invalidation has occurred.<a href="#section-3.2-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-5.4">
On one connection in different RPC-over-RDMA transactions,
or in a single RPC-over-RDMA transaction,
an RPC-over-RDMA requester can expose a mixture of STags
that may be invalidated remotely
and some that must not be.
No indication is provided at the RDMA layer as to which is which.<a href="#section-3.2-5.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.2-6">
A responder therefore must not employ remote invalidation unless it is
aware of support for it in its own RDMA stack, and on the requester.
And, without altering the XDR structure of RPC-over-RDMA version 1 messages,
it is not possible to support remote invalidation with requesters
that include an STag that must not be invalidated
remotely in an RPC with STags that may be invalidated. Likewise, it
is not possible to support remote invalidation with requesters that
mix RPCs with STags that may be invalidated with RPCs with STags that
must not be invalidated on the same connection.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
<p id="section-3.2-7">
There are some NFS/RDMA client implementations whose STags
are always safe to invalidate remotely.
For such clients, indicating to the responder that remote
invalidation is always safe can enable such invalidation
without the need for additional protocol elements to be defined.<a href="#section-3.2-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="section_99541DF3-E579-42B6-9C7A-D020926798F6">
<section id="section-4">
      <h2 id="name-private-data-message-format">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-private-data-message-format" class="section-name selfRef">Private Data Message Format</a>
      </h2>
<p id="section-4-1">
With an InfiniBand lower layer, for example,
RDMA connection setup uses a Connection Manager (CM)
when establishing a Reliable Connection
<span>[<a href="#IBA" class="xref">IBA</a>]</span>.
When an RPC-over-RDMA version 1 transport connection is established,
the client (which actively establishes connections)
and the server (which passively accepts connections)
populate the CM Private Data field exchanged
as part of CM connection establishment.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
The transport properties exchanged via this mechanism
are fixed for the life of the connection.
Each new connection presents an opportunity
for a fresh exchange.
An implementation of the extension described in this document
<span class="bcp14">MUST</span> be prepared for the settings to change upon a reconnection.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
For RPC-over-RDMA version 1, the CM Private Data field
is formatted as described below. RPC clients and servers use the same format.
If the capacity of the Private Data field is too small
to contain this message format
or
the underlying RDMA transport is not managed by a CM,
the CM Private Data field cannot be used on behalf of RPC-over-RDMA version 1.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
The first eight octets of the CM Private Data field
are to be formatted as follows:<a href="#section-4-4" class="pilcrow">¶</a></p>
<div class="artwork art-text alignLeft" id="section-4-5">
<pre>
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Format Identifier                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Version    |  Reserved   |R|   Send Size   | Receive Size  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+</pre><a href="#section-4-5" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4-6">
        <dt id="section-4-6.1">Format Identifier:</dt>
        <dd id="section-4-6.2">
This field contains a fixed 32-bit value that identifies
the content of the Private Data field as an RPC-over-RDMA
version 1 CM Private Data message.
In RPC-over-RDMA version 1 Private Data,
the value of this field is always 0xf6ab0e18, in network byte order.
The use of this field is further expanded upon in
<a href="#section_0BD80E15-13FF-4210-A1D8-E0AE531821A4" class="xref">Section 5.2</a>.<a href="#section-4-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.3">Version:</dt>
        <dd id="section-4-6.4">
This 8-bit field contains a message format version number.
The value "1" in this field indicates that exactly eight octets are present,
that they appear in the order described in this section,
and that each has the meaning defined in this section.
Further considerations about the use of this field are discussed in
<a href="#section_96A18D5A-2AE4-490D-B140-B964302BF1DF" class="xref">Section 6</a>.<a href="#section-4-6.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.5">Reserved:</dt>
        <dd id="section-4-6.6">
This 7-bit field is unused.
Senders <span class="bcp14">MUST</span> set these bits to zero,
and
receivers <span class="bcp14">MUST</span> ignore their value.<a href="#section-4-6.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.7">R:</dt>
        <dd id="section-4-6.8">
This 1-bit field indicates that
the sender supports remote invalidation.
The field is set and interpreted as described in
<a href="#section_1D624044-49CC-4464-9BEF-59EA2473ACBF" class="xref">Section 4.1</a>.<a href="#section-4-6.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.9">Send Size:</dt>
        <dd id="section-4-6.10">
This 8-bit field contains an encoded value
corresponding to the maximum number of bytes
this peer is prepared to transmit in a single RDMA Send
on this connection.
The value is encoded as described in
<a href="#section_689BD9D4-9C3C-41C7-81F3-8BBE283D252B" class="xref">Section 4.2</a>.<a href="#section-4-6.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.11">Receive Size:</dt>
        <dd id="section-4-6.12">
This 8-bit field contains an encoded value
corresponding to the maximum number of bytes
this peer is prepared to receive with a single RDMA Receive
on this connection.
The value is encoded as described in
<a href="#section_689BD9D4-9C3C-41C7-81F3-8BBE283D252B" class="xref">Section 4.2</a>.<a href="#section-4-6.12" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<div id="section_1D624044-49CC-4464-9BEF-59EA2473ACBF">
<section id="section-4.1">
        <h3 id="name-using-the-r-field">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-using-the-r-field" class="section-name selfRef">Using the R Field</a>
        </h3>
<p id="section-4.1-1">
The R field indicates limited support for remote invalidation
as described in
<a href="#section_F82BDC05-F8A6-478C-A02C-BC308EE75A18" class="xref">Section 3.2</a>.
When both connection peers have set this bit flag in their CM Private Data,
the responder <span class="bcp14">MAY</span> use RDMA Send with Invalidate operations
when transmitting RPC Replies.
Each RDMA Send with Invalidate <span class="bcp14">MUST</span> invalidate an STag
associated only with the Transaction ID (XID) in the rdma_xid field
of the RPC-over-RDMA Transport Header it carries.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
When either peer on a connection clears this flag,
the responder <span class="bcp14">MUST</span> use only RDMA Send when transmitting RPC Replies.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="section_689BD9D4-9C3C-41C7-81F3-8BBE283D252B">
<section id="section-4.2">
        <h3 id="name-send-and-receive-size-value">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-send-and-receive-size-value" class="section-name selfRef">Send and Receive Size Values</a>
        </h3>
<p id="section-4.2-1">
Inline threshold sizes from 1024 to 262144 octets
can be represented in the Send Size and Receive Size fields.
The inline threshold values provide a pair of
1024-octet-aligned maximum message lengths that
guarantee that Send and Receive operations
do not fail due to length errors.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
The minimum inline threshold for RPC-over-RDMA version 1
is 1024 octets (see <span><a href="https://www.rfc-editor.org/rfc/rfc8166#section-3.3.3" class="relref">Section 3.3.3</a> of [<a href="#RFC8166" class="xref">RFC8166</a>]</span>).
The values in the Send Size and Receive Size fields represent
the unsigned number of additional kilo-octets of length
beyond the first 1024 octets.
Thus, a sender computes the encoded value by
dividing its actual buffer size, in octets, by 1024
and
subtracting one from the result.
A receiver decodes an incoming Size value by performing
the inverse set of operations:
it adds one to the encoded value
and then
multiplies that result by 1024.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">
The client uses the smaller of its own send size and
the server's reported receive size
as the client-to-server inline threshold.
The server uses the smaller of its own send size and
the client's reported receive size
as the server-to-client inline threshold.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="section_58229D50-C3E7-48D1-A82F-7720AC8A9F8B">
<section id="section-5">
      <h2 id="name-interoperability-considerat">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-interoperability-considerat" class="section-name selfRef">Interoperability Considerations</a>
      </h2>
<p id="section-5-1">
The extension described in this document is designed to allow
RPC-over-RDMA version implementations that use CM Private Data
to interoperate fully with
RPC-over-RDMA version 1 implementations that do not exchange this information.
Implementations that use this extension must also interoperate
fully with RDMA implementations that use CM Private Data for other purposes.
Realizing these goals requires that implementations of this extension
follow the practices described in the rest of this section.<a href="#section-5-1" class="pilcrow">¶</a></p>
<div id="section_9A3B285D-D557-4028-ACB0-60EA1C9C93BE">
<section id="section-5.1">
        <h3 id="name-interoperability-with-rpc-o">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-interoperability-with-rpc-o" class="section-name selfRef">Interoperability with RPC-over-RDMA Version 1 Implementations</a>
        </h3>
<p id="section-5.1-1">
When a peer does not receive a CM Private Data message
that conforms to
<a href="#section_99541DF3-E579-42B6-9C7A-D020926798F6" class="xref">Section 4</a>,
it needs to act as if the remote peer supports only the
default RPC-over-RDMA version 1 settings,
as defined in
<span>[<a href="#RFC8166" class="xref">RFC8166</a>]</span>.
In other words, the peer <span class="bcp14">MUST</span> behave as if a Private Data
message was received in which (1) bit 15 of the Flags field is zero
and (2) both Size fields contain the value zero.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="section_0BD80E15-13FF-4210-A1D8-E0AE531821A4">
<section id="section-5.2">
        <h3 id="name-interoperability-amongst-rd">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-interoperability-amongst-rd" class="section-name selfRef">Interoperability amongst RDMA Transports</a>
        </h3>
<p id="section-5.2-1">
The Format Identifier field defined in
<a href="#section_99541DF3-E579-42B6-9C7A-D020926798F6" class="xref">Section 4</a>
is provided to enable implementations to distinguish the Private Data defined
in this document from Private Data inserted at other layers, such as the
additional Private Data defined by the MPAv2 protocol described in
<span>[<a href="#RFC6581" class="xref">RFC6581</a>]</span>, and others.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
As part of connection establishment,
the buffer containing the received Private Data is searched for the Format Identifier word.
The offset of the Format Identifier is not restricted to any alignment.
If the RPC-over-RDMA version 1 CM Private Data Format Identifier
is not present,
an RPC-over-RDMA version 1 receiver <span class="bcp14">MUST</span>
behave as if no RPC-over-RDMA version 1 CM Private Data
has been provided.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">
Once the RPC-over-RDMA version 1 CM Private Data Format Identifier
is found,
the receiver parses the subsequent octets as
RPC-over-RDMA version 1 CM Private Data.
As additional assurance that the content is valid
RPC-over-RDMA version 1 CM Private Data,
the receiver should check that
the format version number field contains a valid and recognized version number
and
the size of the content does not overrun the length of the buffer.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="section_96A18D5A-2AE4-490D-B140-B964302BF1DF">
<section id="section-6">
      <h2 id="name-updating-the-message-format">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-updating-the-message-format" class="section-name selfRef">Updating the Message Format</a>
      </h2>
<p id="section-6-1">
Although the message format described in this document
provides the ability for the client and server
to exchange particular information about
the local RPC-over-RDMA implementation,
it is possible that there will be a future need
to exchange additional properties.
This would make it necessary to extend or otherwise modify
the format described in this document.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
Any modification faces the problem of interoperating properly
with implementations of RPC-over-RDMA version 1
that are unaware of the existence of the new format.
These include implementations that do not recognize
the exchange of CM Private Data
as well as
those that recognize only the format described in this document.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
Given the message format described in this document,
these interoperability constraints could be met by the following
sorts of new message formats:<a href="#section-6-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-4.1">
A format that uses a different value for the first four bytes of the format,
as provided for in the registry described in
<a href="#section_8701C122-F206-4F87-8FA6-62F1CD648A14" class="xref">Section 8</a>.<a href="#section-6-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-4.2">
A format that uses the same value for the Format Identifier field
and a value other than one (1) in the Version field.<a href="#section-6-4.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-5">
Although it is possible to reorganize
the last three of the eight bytes in the existing format,
extended formats are unlikely to do so.
New formats would take the form of extensions
of the format described in this document with added fields
starting at byte eight of the format
or changes to the definition of bits in the Reserved field.<a href="#section-6-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="section_19F962AD-CDE5-4216-BE3A-44BD238458EC">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">
The reader is directed to the Security Considerations section of
<span>[<a href="#RFC8166" class="xref">RFC8166</a>]</span>
for background and further discussion.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
The RPC-over-RDMA version 1 protocol framework depends
on the semantics of the Reliable Connected (RC) queue pair (QP)
type, as defined in
Section 9.7.7 of <span>[<a href="#IBA" class="xref">IBA</a>]</span>.
The integrity of CM Private Data
and
the authenticity of its source
are ensured by the exclusive use of RC QPs.
Any attempt to interfere with or hijack data in transit
on an RC connection
results in the RDMA provider terminating the connection.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
The Security Considerations section of
<span>[<a href="#RFC5042" class="xref">RFC5042</a>]</span>
refers the reader to further relevant discussion
of generic RDMA transport security.
That document recommends IPsec as
the default transport-layer security solution.
When deployed with the Remote Direct Memory Access Protocol (RDMAP) <span>[<a href="#RFC5040" class="xref">RFC5040</a>]</span>, DDP <span>[<a href="#RFC5041" class="xref">RFC5041</a>]</span>, and MPA <span>[<a href="#RFC5044" class="xref">RFC5044</a>]</span>, IPsec establishes a protected channel before any
operations are exchanged; thus, it protects the exchange of Private Data.
However, IPsec is not available for InfiniBand or RDMA over Converged Ethernet (RoCE) deployments.
Those fabrics rely on
physical security
and
cyclic redundancy checks
to protect network traffic.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">
Exchanging the information
contained in the message format defined in this document
does not expose upper-layer payloads to an attacker.
Furthermore, the behavior changes that occur
as a result of exchanging the Private Data
described in the current document
do not introduce any new risk of exposure
of upper-layer payload data.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">
Improperly setting one of the fields in version 1
Private Data can result in an increased risk of disconnection
(i.e., self-imposed Denial of Service).
A similar risk can arise
if non-RPC-over-RDMA CM Private Data
inadvertently contains the Format Identifier that
identifies this protocol's data structure.
Additional checking of incoming Private Data,
as described in
<a href="#section_0BD80E15-13FF-4210-A1D8-E0AE531821A4" class="xref">Section 5.2</a>,
can help reduce this risk.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">
In addition to describing the structure of a new format version,
any document that extends the Private Data format described
in the current document must discuss security considerations
of new data items exchanged between connection peers.
Such documents should also explore the risks
of erroneously identifying non-RPC-over-RDMA CM Private Data
as the new format.<a href="#section-7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="section_8701C122-F206-4F87-8FA6-62F1CD648A14">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">
IANA has created the "RDMA-CM Private Data Identifiers" subregistry within the  
"Remote Direct Data Placement" protocol category group.
This is a subregistry of 32-bit numbers that identify
the upper-layer protocol associated with data that appears in
the application-specific RDMA-CM Private Data area.
The fields in this subregistry include the following:
Format Identifier,
Length (format length, in octets),
Description,
and
Reference.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">
The initial contents of this registry are a single entry:<a href="#section-8-2" class="pilcrow">¶</a></p>
<span id="name-new-rdma-cm-private-data-id"></span><div id="table_336556D8-B52A-476E-8E9E-FDF4A4C7ED66">
<table class="left" id="table-1">
        <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-new-rdma-cm-private-data-id" class="selfRef">New "RDMA-CM Private Data Identifiers" Registry</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Format Identifier</th>
            <th class="text-left" rowspan="1" colspan="1">Length</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
            <th class="text-left" rowspan="1" colspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">0xf6ab0e18</td>
            <td class="text-left" rowspan="1" colspan="1">8</td>
            <td class="text-left" rowspan="1" colspan="1">RPC-over-RDMA version 1 CM Private Data</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 8797</td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-8-4">
IANA is to assign subsequent new entries in this registry using
the Specification Required policy as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8126#section-4.6" class="relref">Section 4.6</a> of [<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-8-4" class="pilcrow">¶</a></p>
<div id="section_DB1C2628-A2D2-4EE7-8CD6-592F832C8C86">
<section id="section-8.1">
        <h3 id="name-guidance-for-designated-exp">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-guidance-for-designated-exp" class="section-name selfRef">Guidance for Designated Experts</a>
        </h3>
<p id="section-8.1-1">
The Designated Expert (DE), appointed by the IESG,
should ascertain the existence of suitable documentation that
defines the semantics and format of the Private Data,
and verify that the document is permanently and publicly available.
Documentation produced outside the IETF must not conflict
with work that is active or already published within the IETF.
The new Reference field should contain
a reference to that documentation.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">
The Description field should contain the name of the
upper-layer protocol
that generates and uses the Private Data.<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<p id="section-8.1-3">
The DE should assign a new Format Identifier so that
it does not conflict with existing entries in this registry
and so that
it is not likely to be mistaken
as part of the payload of other registered formats.<a href="#section-8.1-3" class="pilcrow">¶</a></p>
<p id="section-8.1-4">
The DE shall post the request to the NFSV4 Working Group mailing list
(or a successor to that list, if such a list exists)
for comment and review.
The DE shall approve or deny the request and publish notice
of the decision within 30 days.<a href="#section-8.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="IBA">[IBA]</dt>
        <dd>
<span class="refAuthor">InfiniBand Trade Association</span>, <span class="refTitle">"InfiniBand Architecture Specification Volume 1"</span>, <span class="seriesInfo">Release 1.3</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.infinibandta.org/">https://www.infinibandta.org/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4506">[RFC4506]</dt>
        <dd>
<span class="refAuthor">Eisler, M., Ed.</span>, <span class="refTitle">"XDR: External Data Representation Standard"</span>, <span class="seriesInfo">STD 67</span>, <span class="seriesInfo">RFC 4506</span>, <span class="seriesInfo">DOI 10.17487/RFC4506</span>, <time datetime="2006-05" class="refDate">May 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4506">https://www.rfc-editor.org/info/rfc4506</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5040">[RFC5040]</dt>
        <dd>
<span class="refAuthor">Recio, R.</span><span class="refAuthor">, Metzler, B.</span><span class="refAuthor">, Culley, P.</span><span class="refAuthor">, Hilland, J.</span><span class="refAuthor">, and D. Garcia</span>, <span class="refTitle">"A Remote Direct Memory Access Protocol Specification"</span>, <span class="seriesInfo">RFC 5040</span>, <span class="seriesInfo">DOI 10.17487/RFC5040</span>, <time datetime="2007-10" class="refDate">October 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5040">https://www.rfc-editor.org/info/rfc5040</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5042">[RFC5042]</dt>
        <dd>
<span class="refAuthor">Pinkerton, J.</span><span class="refAuthor"> and E. Deleganes</span>, <span class="refTitle">"Direct Data Placement Protocol (DDP) / Remote Direct Memory Access Protocol (RDMAP) Security"</span>, <span class="seriesInfo">RFC 5042</span>, <span class="seriesInfo">DOI 10.17487/RFC5042</span>, <time datetime="2007-10" class="refDate">October 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5042">https://www.rfc-editor.org/info/rfc5042</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8166">[RFC8166]</dt>
        <dd>
<span class="refAuthor">Lever, C., Ed.</span><span class="refAuthor">, Simpson, W.</span><span class="refAuthor">, and T. Talpey</span>, <span class="refTitle">"Remote Direct Memory Access Transport for Remote Procedure Call Version 1"</span>, <span class="seriesInfo">RFC 8166</span>, <span class="seriesInfo">DOI 10.17487/RFC8166</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8166">https://www.rfc-editor.org/info/rfc8166</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
      <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="RFC1813">[RFC1813]</dt>
        <dd>
<span class="refAuthor">Callaghan, B.</span><span class="refAuthor">, Pawlowski, B.</span><span class="refAuthor">, and P. Staubach</span>, <span class="refTitle">"NFS Version 3 Protocol Specification"</span>, <span class="seriesInfo">RFC 1813</span>, <span class="seriesInfo">DOI 10.17487/RFC1813</span>, <time datetime="1995-06" class="refDate">June 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1813">https://www.rfc-editor.org/info/rfc1813</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5041">[RFC5041]</dt>
        <dd>
<span class="refAuthor">Shah, H.</span><span class="refAuthor">, Pinkerton, J.</span><span class="refAuthor">, Recio, R.</span><span class="refAuthor">, and P. Culley</span>, <span class="refTitle">"Direct Data Placement over Reliable Transports"</span>, <span class="seriesInfo">RFC 5041</span>, <span class="seriesInfo">DOI 10.17487/RFC5041</span>, <time datetime="2007-10" class="refDate">October 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5041">https://www.rfc-editor.org/info/rfc5041</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5044">[RFC5044]</dt>
        <dd>
<span class="refAuthor">Culley, P.</span><span class="refAuthor">, Elzur, U.</span><span class="refAuthor">, Recio, R.</span><span class="refAuthor">, Bailey, S.</span><span class="refAuthor">, and J. Carrier</span>, <span class="refTitle">"Marker PDU Aligned Framing for TCP Specification"</span>, <span class="seriesInfo">RFC 5044</span>, <span class="seriesInfo">DOI 10.17487/RFC5044</span>, <time datetime="2007-10" class="refDate">October 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5044">https://www.rfc-editor.org/info/rfc5044</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5531">[RFC5531]</dt>
        <dd>
<span class="refAuthor">Thurlow, R.</span>, <span class="refTitle">"RPC: Remote Procedure Call Protocol Specification Version 2"</span>, <span class="seriesInfo">RFC 5531</span>, <span class="seriesInfo">DOI 10.17487/RFC5531</span>, <time datetime="2009-05" class="refDate">May 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5531">https://www.rfc-editor.org/info/rfc5531</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5666">[RFC5666]</dt>
        <dd>
<span class="refAuthor">Talpey, T.</span><span class="refAuthor"> and B. Callaghan</span>, <span class="refTitle">"Remote Direct Memory Access Transport for Remote Procedure Call"</span>, <span class="seriesInfo">RFC 5666</span>, <span class="seriesInfo">DOI 10.17487/RFC5666</span>, <time datetime="2010-01" class="refDate">January 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5666">https://www.rfc-editor.org/info/rfc5666</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6581">[RFC6581]</dt>
        <dd>
<span class="refAuthor">Kanevsky, A., Ed.</span><span class="refAuthor">, Bestler, C., Ed.</span><span class="refAuthor">, Sharp, R.</span><span class="refAuthor">, and S. Wise</span>, <span class="refTitle">"Enhanced Remote Direct Memory Access (RDMA) Connection Establishment"</span>, <span class="seriesInfo">RFC 6581</span>, <span class="seriesInfo">DOI 10.17487/RFC6581</span>, <time datetime="2012-04" class="refDate">April 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6581">https://www.rfc-editor.org/info/rfc6581</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7530">[RFC7530]</dt>
        <dd>
<span class="refAuthor">Haynes, T., Ed.</span><span class="refAuthor"> and D. Noveck, Ed.</span>, <span class="refTitle">"Network File System (NFS) Version 4 Protocol"</span>, <span class="seriesInfo">RFC 7530</span>, <span class="seriesInfo">DOI 10.17487/RFC7530</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7530">https://www.rfc-editor.org/info/rfc7530</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7861">[RFC7861]</dt>
      <dd>
<span class="refAuthor">Adamson, A.</span><span class="refAuthor"> and N. Williams</span>, <span class="refTitle">"Remote Procedure Call (RPC) Security Version 3"</span>, <span class="seriesInfo">RFC 7861</span>, <span class="seriesInfo">DOI 10.17487/RFC7861</span>, <time datetime="2016-11" class="refDate">November 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7861">https://www.rfc-editor.org/info/rfc7861</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="section_3910182B-831B-4CE3-9A51-B23F0C26A43B">
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1">
Thanks to
<span class="contact-name">Christoph Hellwig</span>
and
<span class="contact-name">Devesh Sharma</span>
for suggesting this approach,
and to
<span class="contact-name">Tom Talpey</span>
and
<span class="contact-name">David Noveck</span>
for their expert comments and review.
The author also wishes to thank
<span class="contact-name">Bill Baker</span>
and
<span class="contact-name">Greg Marsden</span>
for their support of this work.
Also, thanks to expert reviewers
<span class="contact-name">Sean Hefty</span>
and
<span class="contact-name">Dave Minturn</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">
Special thanks go to
document shepherd
<span class="contact-name">Brian Pawlowski</span>,
Transport Area Director
<span class="contact-name">Magnus Westerlund</span>,
NFSV4 Working Group Chairs
<span class="contact-name">David Noveck</span>
and
<span class="contact-name">Spencer Shepler</span>,
and
NFSV4 Working Group Secretary <span class="contact-name">Thomas Haynes</span>.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Charles Lever</span></div>
<div dir="auto" class="left"><span class="org">Oracle Corporation</span></div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:chuck.lever@oracle.com" class="email">chuck.lever@oracle.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>