File: rfc8939.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 (2745 lines) | stat: -rw-r--r-- 135,704 bytes
<!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 8939: Deterministic Networking (DetNet) Data Plane: IP</title>
<meta content="Balázs Varga" name="author">
<meta content="János Farkas" name="author">
<meta content="Lou Berger" name="author">
<meta content="Don Fedyk" name="author">
<meta content="Stewart Bryant" name="author">
<meta content="
       
        This document specifies the Deterministic Networking (DetNet)
        data plane operation for IP hosts and routers that provide DetNet
        service to IP-encapsulated data. No DetNet-specific encapsulation is
        defined to support IP flows; instead, the existing IP-layer and
        higher-layer protocol header information is used to support flow
        identification and DetNet service delivery.  This document builds on
        the DetNet architecture (RFC 8655) and data plane framework
        (RFC 8938).
       
    " name="description">
<meta content="xml2rfc 3.5.0" name="generator">
<meta content="Application" name="keyword">
<meta content="Endpoint" name="keyword">
<meta content="Service Sub-layer" name="keyword">
<meta content="Forwarding Sub-layer" name="keyword">
<meta content="8939" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.5.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="rfc8939.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/rfc8939" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-detnet-ip-07" 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 8939</td>
<td class="center">DetNet Data Plane: IP</td>
<td class="right">November 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Varga, et al.</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/rfc8939" class="eref">8939</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-11" class="published">November 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">B. Varga, <span class="editor">Ed.</span>
</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">J. Farkas</div>
<div class="org">Ericsson</div>
</div>
<div class="author">
      <div class="author-name">L. Berger</div>
<div class="org">LabN Consulting, L.L.C.</div>
</div>
<div class="author">
      <div class="author-name">D. Fedyk</div>
<div class="org">LabN Consulting, L.L.C.</div>
</div>
<div class="author">
      <div class="author-name">S. Bryant</div>
<div class="org">Futurewei Technologies</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8939</h1>
<h1 id="title">Deterministic Networking (DetNet) Data Plane: IP</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 Deterministic Networking (DetNet)
        data plane operation for IP hosts and routers that provide DetNet
        service to IP-encapsulated data. No DetNet-specific encapsulation is
        defined to support IP flows; instead, the existing IP-layer and
        higher-layer protocol header information is used to support flow
        identification and DetNet service delivery.  This document builds on
        the DetNet architecture (RFC 8655) and data plane framework
        (RFC 8938).<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/rfc8939">https://www.rfc-editor.org/info/rfc8939</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="toc compact ulEmpty">
<li class="toc compact ulEmpty" 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="toc compact ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><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>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-terms-used-in-this-document" class="xref">Terms Used in This Document</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-abbreviations" class="xref">Abbreviations</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" 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-overview-of-the-detnet-ip-d" class="xref">Overview of the DetNet IP Data Plane</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" 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-detnet-ip-data-plane-consid" class="xref">DetNet IP Data Plane Considerations</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" 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-end-system-specific-conside" class="xref">End-System-Specific Considerations</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" 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-detnet-domain-specific-cons" class="xref">DetNet Domain-Specific Considerations</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-forwarding-sub-layer-consid" class="xref">Forwarding Sub-Layer Considerations</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.4.2.3.2.1">
                    <p id="section-toc.1-1.4.2.3.2.1.1"><a href="#section-4.3.1" class="xref">4.3.1</a>.  <a href="#name-class-of-service" class="xref">Class of Service</a><a href="#section-toc.1-1.4.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.3.2.2">
                    <p id="section-toc.1-1.4.2.3.2.2.1"><a href="#section-4.3.2" class="xref">4.3.2</a>.  <a href="#name-quality-of-service" class="xref">Quality of Service</a><a href="#section-toc.1-1.4.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.3.2.3">
                    <p id="section-toc.1-1.4.2.3.2.3.1"><a href="#section-4.3.3" class="xref">4.3.3</a>.  <a href="#name-path-selection" class="xref">Path Selection</a><a href="#section-toc.1-1.4.2.3.2.3.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-detnet-flow-aggregation" class="xref">DetNet Flow Aggregation</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-bidirectional-traffic" class="xref">Bidirectional Traffic</a><a href="#section-toc.1-1.4.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" 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-detnet-ip-data-plane-proced" class="xref">DetNet IP Data Plane Procedures</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" 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-detnet-ip-flow-identificati" class="xref">DetNet IP Flow Identification Procedures</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc compact ulEmpty">
<li class="toc compact ulEmpty" id="section-toc.1-1.5.2.1.2.1">
                    <p id="section-toc.1-1.5.2.1.2.1.1"><a href="#section-5.1.1" class="xref">5.1.1</a>.  <a href="#name-ip-header-information" class="xref">IP Header Information</a><a href="#section-toc.1-1.5.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.1.2.2">
                    <p id="section-toc.1-1.5.2.1.2.2.1"><a href="#section-5.1.2" class="xref">5.1.2</a>.  <a href="#name-other-protocol-header-infor" class="xref">Other Protocol Header Information</a><a href="#section-toc.1-1.5.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="toc compact ulEmpty" 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-forwarding-procedures" class="xref">Forwarding Procedures</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="toc compact ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-detnet-ip-traffic-treatment" class="xref">DetNet IP Traffic Treatment Procedures</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="toc compact ulEmpty" 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-management-and-control-info" class="xref">Management and Control Information Summary</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" 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="toc compact ulEmpty" 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>
</li>
          <li class="toc compact ulEmpty" 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="toc compact ulEmpty">
<li class="toc compact ulEmpty" 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="toc compact ulEmpty" 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="toc compact ulEmpty" 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-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" 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-contributors" class="xref">Contributors</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
          <li class="toc compact ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sec_intro">
<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">
        Deterministic Networking (DetNet) is a service that can be offered by
        a network to DetNet flows.
        DetNet provides these flows with extremely low packet loss rates and
        assured maximum end-to-end
        delivery latency.  General background and concepts of DetNet can
        be found in the DetNet architecture <span>[<a href="#RFC8655" class="xref">RFC8655</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
        This document specifies the DetNet data plane operation for IP hosts
        and routers that provide DetNet service to IP-encapsulated data.  No
        DetNet-specific encapsulation is defined to support IP flows; instead,
        the existing IP-layer and higher-layer protocol header information is used to
        support flow identification and DetNet service delivery. Common data plane
        procedures and control information for all DetNet data planes
        can be found in <span>[<a href="#RFC8938" class="xref">RFC8938</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
        The DetNet architecture models the DetNet-related data plane functions
        as two sub-layers: a service sub-layer and a forwarding sub-layer.
        The service sub-layer is used to provide DetNet service protection
        (e.g., by the Packet Replication Function (PRF) and Packet Elimination
        Function (PEF)) and reordering. The forwarding sub-layer is used to
        provide congestion protection (low loss, assured latency, and limited
        out-of-order delivery).  The service sub-layer generally requires
        additional header fields to provide its service; for example, see
        <span>[<a href="#DetNet-MPLS" class="xref">DetNet-MPLS</a>]</span>.  Since no
        DetNet-specific fields are added to support DetNet IP flows, only the
        forwarding sub-layer functions are supported using the DetNet IP
        defined by this document.  Service protection can be provided on a
        per-sub-network basis using technologies such as MPLS <span>[<a href="#DetNet-MPLS" class="xref">DetNet-MPLS</a>]</span> and Ethernet,
        as specified by the IEEE 802.1 TSN (Time-Sensitive Networking) task
        group (referred to in this document simply as "IEEE 802.1 TSN").
        See <span>[<a href="#IEEE802.1TSNTG" class="xref">IEEE802.1TSNTG</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
        This document provides an overview of the DetNet IP data plane in
        <a href="#sec_dt_dp" class="xref">Section 3</a> and considerations that
        apply to providing
        DetNet services via the DetNet IP data plane in <a href="#dn-gen-encap-solution" class="xref">Section 4</a>. <a href="#ip-procs" class="xref">Section 5</a>
        provides the procedures for hosts and routers that support IP-based
        DetNet services. <a href="#ip-flow-id-info" class="xref">Section 6</a> summarizes the set of
                information that is needed to identify an individual DetNet flow.<a href="#section-1-4" class="pilcrow">¶</a></p>
</section>
</div>
<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>
<section id="section-2.1">
        <h3 id="name-terms-used-in-this-document">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-terms-used-in-this-document" class="section-name selfRef">Terms Used in This Document</a>
        </h3>
<p id="section-2.1-1">
          This document uses the terminology and concepts established in
          the DetNet architecture <span>[<a href="#RFC8655" class="xref">RFC8655</a>]</span>,
          and it is assumed that the reader is
          familiar with that document and its terminology.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-2.2">
        <h3 id="name-abbreviations">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-abbreviations" class="section-name selfRef">Abbreviations</a>
        </h3>
<p id="section-2.2-1">
          The following abbreviations are used in this document:<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2.2-2">
          <dt id="section-2.2-2.1">CoS</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.2">Class of Service<a href="#section-2.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.3">DetNet</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.4">Deterministic Networking<a href="#section-2.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.5">DN</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.6">DetNet<a href="#section-2.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.7">Diffserv</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.8">Differentiated Services<a href="#section-2.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.9">DSCP</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.10">Differentiated Services Code Point<a href="#section-2.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.11">L2</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.12">Layer 2<a href="#section-2.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.13">L3</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.14">Layer 3<a href="#section-2.2-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.15">LSP</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.16">Label Switched Path<a href="#section-2.2-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.17">MPLS</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.18">Multiprotocol Label Switching<a href="#section-2.2-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.19">PEF</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.20">Packet Elimination Function<a href="#section-2.2-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.21">PREOF</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.22">Packet Replication, Elimination, and Ordering Functions<a href="#section-2.2-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.23">PRF</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.24">Packet Replication Function<a href="#section-2.2-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.25">QoS</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.26">Quality of Service<a href="#section-2.2-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.27">TSN</dt>
          <dd style="margin-left: 7.0em" id="section-2.2-2.28">Time-Sensitive Networking. TSN is a task group of the IEEE
            802.1 Working Group.<a href="#section-2.2-2.28" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
<section id="section-2.3">
        <h3 id="name-requirements-language">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-2.3-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.3-1" class="pilcrow">¶</a></p>
</section>
</section>
<div id="sec_dt_dp">
<section id="section-3">
      <h2 id="name-overview-of-the-detnet-ip-d">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-overview-of-the-detnet-ip-d" class="section-name selfRef">Overview of the DetNet IP Data Plane</a>
      </h2>
<p id="section-3-1">
        This document describes how IP is used by DetNet nodes, i.e., hosts and
        routers, to identify DetNet flows and provide a DetNet service using an IP
        data plane. From a data plane perspective, an end-to-end IP model is
        followed.  As mentioned above, existing IP-layer and higher-layer
        protocol header information is used to support flow identification and
        DetNet
        service delivery. Common data plane procedures and control information
        for all DetNet data planes can be found in <span>[<a href="#RFC8938" class="xref">RFC8938</a>]</span>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
        The DetNet IP data plane primarily uses 6-tuple-based flow identification, where
        "6-tuple" refers to information carried in IP-layer and higher-layer protocol
        headers.  The 6-tuple referred to in this document is the same as
        that defined in <span>[<a href="#RFC3290" class="xref">RFC3290</a>]</span>. Specifically, the 6-tuple is
        destination address, source address, IP protocol, source port,
        destination port, and
        DSCP.  General background on the use of IP headers and 5-tuples
        to identify flows and support Quality of Service (QoS) can be found in
        <span>[<a href="#RFC3670" class="xref">RFC3670</a>]</span>.  <span>[<a href="#RFC7657" class="xref">RFC7657</a>]</span> also provides
        useful background on the delivery of Diffserv and tuple-based flow
        identification. Note that a 6-tuple is composed of a 5-tuple
        plus the addition of a DSCP component.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
            For some of the protocols, 5-tuples and 6-tuples cannot be used, because 
                the port information is not available (e.g., ICMP, IPsec, and
                Encapsulating Security Payload (ESP)). This is
                also the case for flow aggregates. In such cases, using
                fewer fields is appropriate, such as a 3-tuple (2 IP
                addresses, IP protocol) or even a 
                2-tuple (all IP traffic between two IP addresses).<a href="#section-3-3" class="pilcrow">¶</a></p>
<p id="section-3-4">
        The DetNet IP data plane also allows for optional matching on
        the IPv6 Flow Label field,
        as defined in <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
            Non-DetNet and DetNet IP packets have the same protocol
            header format on the wire. 
            Generally, the fields used in flow identification are forwarded 
            unmodified. However, standard modification of the
            DSCP field <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span> is not precluded.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">
        DetNet flow aggregation may be enabled via the use of
        wildcards, masks, lists, prefixes, and ranges. IP tunnels may also be
        used to support flow aggregation. In these cases, it is
        expected that DetNet-aware intermediate nodes will provide
        DetNet service on the aggregate through resource
        allocation and congestion control mechanisms.<a href="#section-3-6" class="pilcrow">¶</a></p>
<p id="section-3-7">
        The specific procedures that are required to be implemented by a
        DetNet node supporting this document can be found in <a href="#ip-procs" class="xref">Section 5</a>.  The DetNet Controller Plane, as defined in
        <span>[<a href="#RFC8655" class="xref">RFC8655</a>]</span>, is responsible for providing each node
        with the information needed to identify and handle each DetNet flow.<a href="#section-3-7" class="pilcrow">¶</a></p>
<span id="name-a-simple-detnet-enabled-ip-"></span><div id="fig_ip_detnet_simple">
<figure id="figure-1">
        <div class="artwork art-text alignLeft" id="section-3-8.1">
<pre>
 DetNet IP       Relay                        Relay       DetNet IP
 End System      Node                         Node        End System

+----------+                                             +----------+
|   Appl.  |&lt;------------ End-to-End Service -----------&gt;|   Appl.  |
+----------+  ............                 ...........   +----------+
| Service  |&lt;-: Service  :-- DetNet flow --: Service  :-&gt;| Service  |
+----------+  +----------+                 +----------+  +----------+
|Forwarding|  |Forwarding|                 |Forwarding|  |Forwarding|
+--------.-+  +-.------.-+                 +-.---.----+  +-------.--+
         : Link :       \      ,-----.      /     \   ,-----.   /
         +......+        +----[  Sub- ]----+       +-[  Sub- ]-+
                              [Network]              [Network]
                               `-----'                `-----'

         |&lt;--------------------- DetNet IP ---------------------&gt;|
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-a-simple-detnet-enabled-ip-" class="selfRef">A Simple DetNet-Enabled IP Network</a>
        </figcaption></figure>
</div>
<p id="section-3-9">
        <a href="#fig_ip_detnet_simple" class="xref">Figure 1</a> illustrates a
        DetNet-enabled IP
        network.  The DetNet-enabled end systems originate IP-encapsulated
        traffic that is identified within the DetNet domain as DetNet
        flows based on IP header information. 
                Relay nodes understand the
        forwarding requirements of the DetNet flow and ensure that node,
        interface, and sub-network resources are allocated to ensure DetNet
        service requirements. The dotted line around the Service component of
        the Relay Nodes indicates that the transit routers are
        DetNet service aware but do not perform any DetNet service sub-layer
        function, e.g., PREOF.<a href="#section-3-9" class="pilcrow">¶</a></p>
<aside id="section-3-10">
        <p id="section-3-10.1">
        Note: The sub-network can represent a TSN, MPLS network, or other
        network technology that can carry DetNet IP traffic.<a href="#section-3-10.1" class="pilcrow">¶</a></p>
</aside>
<span id="name-non-detnet-aware-ip-end-sys"></span><div id="fig_non_detnet_ip">
<figure id="figure-2">
        <div class="artwork art-text alignLeft" id="section-3-11.1">
<pre>
 IP              Edge                        Edge         IP
 End System      Node                        Node         End System

+----------+   +.........+                 +.........+   +----------+
|   Appl.  |&lt;--:Svc Proxy:-- E2E Service---:Svc Proxy:--&gt;|   Appl.  |
+----------+   +.........+                 +.........+   +----------+
|    IP    |&lt;--:IP : :Svc:---- IP flow ----:Svc: :IP :--&gt;|    IP    |
+----------+   +---+ +---+                 +---+ +---+   +----------+
|Forwarding|   |Fwd| |Fwd|                 |Fwd| |Fwd|   |Forwarding|
+--------.-+   +-.-+ +-.-+                 +-.-+ +-.-+   +---.------+
         :  Link :      \      ,-----.      /     /  ,-----.  \
         +.......+       +----[  Sub- ]----+     +--[  Sub- ]--+
                              [network]             [network]
                               `-----'               `-----'

      |&lt;--- IP ---&gt;| |&lt;------ DetNet IP ------&gt;| |&lt;--- IP ---&gt;|
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-non-detnet-aware-ip-end-sys" class="selfRef">Non-DetNet-Aware IP End Systems with DetNet IP Domain</a>
        </figcaption></figure>
</div>
<p id="section-3-12">
        <a href="#fig_non_detnet_ip" class="xref">Figure 2</a> illustrates a variant of <a href="#fig_ip_detnet_simple" class="xref">Figure 1</a> where the end systems are not DetNet
        aware.  In this case, edge nodes sit at the boundary of the DetNet
        domain and provide DetNet service proxies for the end applications by
        initiating and terminating DetNet service for the application's IP
        flows.  The existing header information or an approach such as described
        in <a href="#aggregation" class="xref">Section 4.4</a> can be used to support DetNet flow
        identification.<a href="#section-3-12" class="pilcrow">¶</a></p>
<p id="section-3-13">
        Note that Figures <a href="#fig_ip_detnet_simple" class="xref">1</a> and <a href="#fig_non_detnet_ip" class="xref">2</a> can be collapsed,
        so IP DetNet
        end systems can communicate over a DetNet IP network with IP end systems.<a href="#section-3-13" class="pilcrow">¶</a></p>
<p id="section-3-14">
        As non-DetNet and DetNet IP packets have the same protocol header
        format on the wire, from
        a data plane perspective, the only difference is that there is
        flow-associated DetNet information on each DetNet node that
        defines the flow-related characteristics and required forwarding
        behavior.  As shown above, edge nodes provide a Service Proxy
        function that "associates" one or more IP flows with the
        appropriate DetNet flow-specific information and ensures that
        the flow receives the proper traffic treatment within the domain.<a href="#section-3-14" class="pilcrow">¶</a></p>
<aside id="section-3-15">
        <p id="section-3-15.1">
        Note: The operation of IEEE 802.1 TSN end systems over DetNet-enabled
        IP networks is not described in this document. TSN
        over MPLS is described in <span>[<a href="#I-D.ietf-detnet-tsn-vpn-over-mpls" class="xref">DetNet-TSN-over-MPLS</a>]</span>.<a href="#section-3-15.1" class="pilcrow">¶</a></p>
</aside>
</section>
</div>
<div id="dn-gen-encap-solution">
<section id="section-4">
      <h2 id="name-detnet-ip-data-plane-consid">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-detnet-ip-data-plane-consid" class="section-name selfRef">DetNet IP Data Plane Considerations</a>
      </h2>
<p id="section-4-1">
        This section provides considerations related to
        providing DetNet service to flows that are identified
        based on their header information.<a href="#section-4-1" class="pilcrow">¶</a></p>
<section id="section-4.1">
        <h3 id="name-end-system-specific-conside">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-end-system-specific-conside" class="section-name selfRef">End-System-Specific Considerations</a>
        </h3>
<p id="section-4.1-1">
          Data flows requiring DetNet service are generated and terminated on
          end systems.  This document deals only with IP end systems. 
          The protocols used by an IP end system are specific to an application,
          and end systems peer with other end systems.  
          DetNet's use of 6-tuple IP flow
          identification means that DetNet must be aware of not only the
          format of the IP header, but also of the next protocol value carried
          within an IP packet (see <a href="#nxt-proto-field" class="xref">Section 5.1.1.3</a>).<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">
          For DetNet-unaware IP end systems, service-level proxy functions are
          needed inside the DetNet domain.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">
          When IP end systems are DetNet aware, no application-level or
          service-level proxy functions are needed inside the DetNet domain.
          End systems need to ensure that DetNet service requirements are met
          when processing packets associated to a DetNet flow.  When
          sending packets, this means that packets are
          appropriately shaped on transmission and receive appropriate traffic
          treatment on the connected sub-network; see Sections <a href="#QoS" class="xref">4.3.2</a> and <a href="#dn_dom_spec_cons" class="xref">4.2</a> for more details.  When receiving packets,
          this means that there are appropriate local node resources,
          e.g., buffers, to receive and process the packets of that DetNet flow.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">
          An important additional consideration for DetNet-aware end
          systems is avoiding IP fragmentation.  Full 6-tuple flow
          identification is not possible on IP fragments, as fragments
          don't include the transport headers or their port
          information. As such, it is important that applications and/or
          end systems use an IP packet size that will avoid
          fragmentation within the network when sending DetNet flows.
          The maximum size can be learned via Path MTU Discovery <span>[<a href="#RFC1191" class="xref">RFC1191</a>]</span> <span>[<a href="#RFC8201" class="xref">RFC8201</a>]</span> or via the Controller Plane.  Note that Path MTU
          Discovery relies on
          ICMP, which may not follow the same path as an individual
          DetNet flow.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">
          In order to maximize reuse of existing mechanisms,
          DetNet-aware applications and end systems <span class="bcp14">SHOULD NOT</span> mix
          DetNet and non-DetNet traffic within a single 5-tuple.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
<div id="dn_dom_spec_cons">
<section id="section-4.2">
        <h3 id="name-detnet-domain-specific-cons">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-detnet-domain-specific-cons" class="section-name selfRef">DetNet Domain-Specific Considerations</a>
        </h3>
<p id="section-4.2-1">
          As a general rule, DetNet IP domains need to be able to forward any
          DetNet flow identified by the IP 6-tuple. Doing otherwise would limit 
          the number of 6-tuple flow ID combinations that could be
          used by the end systems. From a practical standpoint, this
          means that all nodes along the end-to-end path of DetNet flows need
          to agree on what fields are used for flow identification.
          Possible consequences of not having such an agreement include
          some flows interfering with other flows, and
          the traffic treatment expected for a service not being
          provided.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
          From a connection-type perspective, two scenarios are identified:<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4.2-3">
          <li id="section-4.2-3.1">
              DN attached: the end system is directly connected to an edge
              node or the end system is behind a sub-network.  (See ES1 and
              ES2 in <a href="#fig_es_con_types" class="xref">Figure 3</a>.)<a href="#section-4.2-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.2-3.2">
              DN integrated: the end system is part of the DetNet domain. (See ES3
              in <a href="#fig_es_con_types" class="xref">Figure 3</a>.)<a href="#section-4.2-3.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-4.2-4">
          L3 (IP) end systems may use any of these connection types.  A DetNet
          domain allows communication between any end systems using the
          same encapsulation format, independent of their connection type and
          DetNet capability. DN-attached end systems have no knowledge about
          the DetNet domain and its encapsulation format.  See <a href="#fig_es_con_types" class="xref">Figure 3</a> for L3 end system connection examples.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<span id="name-connection-types-of-l3-end-"></span><div id="fig_es_con_types">
<figure id="figure-3">
          <div class="artwork art-text alignCenter" id="section-4.2-5.1">
<pre>
                                   ____+----+
           +----+        _____    /    | ES3|
           | ES1|____   /     \__/     +----+___
           +----+    \ /                        \
                      +                          |
              ____     \                        _/
+----+     __/    \     +__  DetNet IP domain  /
| ES2|____/  L2/L3 |___/   \         __     __/
+----+    \_______/         \_______/  \___/
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-connection-types-of-l3-end-" class="selfRef">Connection Types of L3 End Systems</a>
          </figcaption></figure>
</div>
<p id="section-4.2-6">
            Within a DetNet domain, the DetNet-enabled IP routers are
            interconnected by links and sub-networks to support end-to-end
            delivery of DetNet flows.  From a DetNet architecture perspective,
            these routers are DetNet relays, as they must be DetNet service
            aware.  Such routers identify DetNet flows based on the IP 6-tuple
            and ensure that the traffic treatment required by the DetNet service is
            provided on both the node and any attached sub-network.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<p id="section-4.2-7">
            This solution provides DetNet functions end to end, but it does so
            on a per-link and per-sub-network basis.  Congestion protection, latency
            control,
            and resource allocation (queuing, policing,
            shaping) are supported using the underlying
            link/sub-network-specific mechanisms.  However, service protection
            (PRF and PEF) is not
            provided end to end at the DetNet layer.  
Instead, service protection can be
            provided on a per-link (underlying
  L2 link) and per-sub-network basis.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">
              The DetNet service flow is mapped to the
              link/sub-network-specific resources using an underlying
              system-specific
              means. This implies that each DetNet-aware node on the path looks
              into the forwarded DetNet service flow packet and utilizes,
              for example, a 6-tuple to find out the required mapping within
              a node.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
<p id="section-4.2-9">
          As noted earlier, service protection must be implemented within 
          each link/sub-network independently, using the domain-specific 
          mechanisms. This is due to the lack of unified end-to-end 
          sequencing information that could be used by the intermediate 
          nodes.
          Therefore, service protection (if enabled) cannot be provided
          end to end, only within sub-networks. This is shown for a scenario
          with three sub-networks in <a href="#fig_pref_in_subnets" class="xref">Figure 4</a>,
          where each sub-network can provide service protection between
              its borders. "R" and "E" denote replication and elimination
                          points within the sub-network.<a href="#section-4.2-9" class="pilcrow">¶</a></p>
<span id="name-replication-and-elimination"></span><div id="fig_pref_in_subnets">
<figure id="figure-4">
          <div class="artwork art-text alignCenter" id="section-4.2-10.1">
<pre>
     &lt;-------------------- DetNet IP ------------------------&gt;
                                 ______
                       ____     /      \__
            ____      /     \__/          \___   ______
+----+   __/    +====+                       +==+      \     +----+
|src |__/ Sub-N1 )   |                       |  \ Sub-N3\____| dst|
+----+  \_______/    \      Sub-network 2    |   \______/    +----+
                      \_                    _/
                        \         __     __/
                         \_______/  \___/


          +---+        +---------E--------+      +-----+
+----+    |   |        |         |        |      |     |      +----+
|src |----R   E--------R     +---+        E------R     E------+ dst|
+----+    |   |        |     |            |      |     |      +----+
          +---+        +-----R------------+      +-----+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-replication-and-elimination" class="selfRef">Replication and Elimination in Sub-networks for DetNet IP
          Networks</a>
          </figcaption></figure>
</div>
<p id="section-4.2-11">
              If end-to-end service protection is desired,  it can be
              implemented -- for example, by the DetNet end systems using
              Layer 4
              (L4) transport protocols or application protocols. However, these
              protocols are out of the scope of this document.<a href="#section-4.2-11" class="pilcrow">¶</a></p>
<p id="section-4.2-12">
          Note that not mixing DetNet and non-DetNet traffic within
          a single 5-tuple, as described above, enables simpler
          5-tuple filters to be used (or reused) at the edges of a DetNet
          network to prevent non-congestion-responsive DetNet
          traffic from escaping the DetNet
          domain.<a href="#section-4.2-12" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.3">
        <h3 id="name-forwarding-sub-layer-consid">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-forwarding-sub-layer-consid" class="section-name selfRef">Forwarding Sub-Layer Considerations</a>
        </h3>
<section id="section-4.3.1">
          <h4 id="name-class-of-service">
<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-class-of-service" class="section-name selfRef">Class of Service</a>
          </h4>
<p id="section-4.3.1-1">
            Class of Service (CoS) for DetNet flows carried in IPv4 and IPv6
            is provided using the standard
          DSCP field <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span> and related mechanisms.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
<p id="section-4.3.1-2">
          One additional consideration for DetNet nodes that support CoS
          services is that they must ensure that the CoS service classes do
          not impact the congestion protection and latency control mechanisms
          used to provide DetNet QoS.  This requirement is similar to the
          requirement for MPLS Label Switching Routers (LSRs) that CoS LSPs
          cannot impact the resources allocated to TE
          LSPs <span>[<a href="#RFC3473" class="xref">RFC3473</a>]</span>.<a href="#section-4.3.1-2" class="pilcrow">¶</a></p>
</section>
<div id="QoS">
<section id="section-4.3.2">
          <h4 id="name-quality-of-service">
<a href="#section-4.3.2" class="section-number selfRef">4.3.2. </a><a href="#name-quality-of-service" class="section-name selfRef">Quality of Service</a>
          </h4>
<p id="section-4.3.2-1">
          Quality of Service (QoS) for DetNet service flows carried in IP must be provided locally by
          the DetNet-aware hosts and routers supporting DetNet flows.  Such
          support leverages the underlying network layer such as
          802.1 TSN.  The node-internal traffic control mechanisms used to
          deliver QoS for
          IP-encapsulated DetNet flows are outside the scope of this
          document. From an encapsulation perspective, the combination of the 6-tuple
          (the typical 5-tuple enhanced with the DSCP) and optionally
          the flow label uniquely identifies a DetNet IP flow.<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
<p id="section-4.3.2-2">
          Packets that are identified as part of a DetNet IP flow
          but that have not been the subject of a completed reservation
          can disrupt the QoS offered to properly reserved DetNet flows
          by using resources allocated to the reserved flows.
          Therefore, the network nodes of a DetNet network <span class="bcp14">MUST</span> ensure
          that no DetNet-allocated resource, e.g., queue or shaper, is
          used by such flows.
          There are multiple methods that may be
          used by an implementation to defend service delivery to
          reserved DetNet flows, including but not limited to:<a href="#section-4.3.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.3.2-3.1">
              Treating packets associated with an incomplete reservation
              as non-DetNet traffic.<a href="#section-4.3.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.3.2-3.2">
              Discarding packets associated with an incomplete
              reservation.<a href="#section-4.3.2-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.3.2-3.3">
              Re-marking packets associated with an incomplete
              reservation.  Re-marking can be accomplished by changing
              the value of the DSCP field to a value that
              results in the packet no longer matching any other
              reserved DetNet IP flow.<a href="#section-4.3.2-3.3" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="path">
<section id="section-4.3.3">
          <h4 id="name-path-selection">
<a href="#section-4.3.3" class="section-number selfRef">4.3.3. </a><a href="#name-path-selection" class="section-name selfRef">Path Selection</a>
          </h4>
<p id="section-4.3.3-1">
          While path selection algorithms and mechanisms are out of the
          scope of the DetNet data plane definition, it is important to
          highlight the implications of DetNet IP flow identification on
          path selection and next hops.  As mentioned above, the DetNet
          IP data plane identifies flows using 6-tuple header
          information as well as the optional (flow label) header
          field. DetNet generally allows for both flow-specific traffic
          treatment and flow-specific next hops.<a href="#section-4.3.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3.3-2">
          In non-DetNet IP forwarding, it is generally assumed that the
          same series of next hops, i.e., the same path, will be used
          for a particular 5-tuple or, in some cases (e.g., <span>[<a href="#RFC5120" class="xref">RFC5120</a>]</span>), for a particular 6-tuple.
          Using different
          next hops for different 5-tuples does not take any special
          consideration for DetNet-aware applications.<a href="#section-4.3.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3.3-3">
          Care should be taken when using different next hops for the
          same 5-tuple.  As discussed in <span>[<a href="#RFC7657" class="xref">RFC7657</a>]</span>,
          unexpected behavior can occur when a single 5-tuple
          application flow experiences reordering due to being split
          across multiple next hops.  Understanding of the application
          and transport protocol impact of using different next hops for
          the same 5-tuple is required.  Again, this only indirectly impacts path
          selection for DetNet flows and this document.<a href="#section-4.3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
<div id="aggregation">
<section id="section-4.4">
        <h3 id="name-detnet-flow-aggregation">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-detnet-flow-aggregation" class="section-name selfRef">DetNet Flow Aggregation</a>
        </h3>
<p id="section-4.4-1">
         As described in <span>[<a href="#RFC8938" class="xref">RFC8938</a>]</span>, the ability to
         aggregate individual flows and their associated resource
         control into a larger aggregate is an important technique for
         improving scaling by reducing the state per hop.  DetNet IP
         data plane aggregation can take place within a single node,
         when that node maintains state about both the aggregated and
         individual flows.  It can also take place between nodes, when
         one node maintains state about only flow aggregates while the
         other node maintains state on all or a portion of the component
         flows.  In either case, the management or control function that
         provisions the aggregate flows must ensure that adequate
         resources are allocated and configured to provide the combined
         service requirements of the individual flows.  As DetNet is
         concerned about latency and jitter, more than just bandwidth
         needs to be considered.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
          From a single node perspective, the aggregation of IP flows
          impacts DetNet IP data plane flow identification and resource
          allocation.  As discussed above, IP flow identification uses
          the IP 6-tuple for flow identification.  DetNet IP flows can
          be aggregated using any of the 6-tuple fields and optionally also by 
          the flow label.  The use of prefixes, wildcards,
          lists, and value ranges allows a DetNet node to identify
          aggregate DetNet flows.  From a resource allocation
          perspective, DetNet nodes ought to provide service to an 
          aggregate rather than on a component flow basis.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">
          It is the responsibility of the DetNet Controller Plane to
          properly provision the use of these aggregation mechanisms.
          This includes ensuring that aggregated flows have compatible
          (e.g., the same or very similar) QoS and/or CoS characteristics;
          see <a href="#QoS" class="xref">Section 4.3.2</a>.  It also includes
          ensuring that per-component-flow service requirements are satisfied
          by the aggregate; see <a href="#ip-svc" class="xref">Section 5.3</a>.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">
         The DetNet Controller Plane <span class="bcp14">MUST</span> ensure that
         non-congestion-responsive DetNet traffic is not forwarded
         outside a DetNet domain.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-4.5">
        <h3 id="name-bidirectional-traffic">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-bidirectional-traffic" class="section-name selfRef">Bidirectional Traffic</a>
        </h3>
<p id="section-4.5-1">
          While the DetNet IP data plane must support bidirectional
          DetNet flows, there are no special bidirectional features within
          the data plane.  The special case of co-routed bidirectional
          DetNet flows is
          solely represented at the management and control plane levels,
          without specific support or knowledge within the DetNet data
          plane.  Fate sharing and associated or co-routed
          bidirectional flows can be managed at the control level.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">
          Control and management mechanisms need to support
          bidirectional flows, but the specification of such mechanisms
          is out of the scope of this document. An example control plane
          solution for MPLS can be found in <span>[<a href="#RFC7551" class="xref">RFC7551</a>]</span>.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="ip-procs">
<section id="section-5">
      <h2 id="name-detnet-ip-data-plane-proced">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-detnet-ip-data-plane-proced" class="section-name selfRef">DetNet IP Data Plane Procedures</a>
      </h2>
<p id="section-5-1">
        This section provides DetNet IP data plane procedures. These
        procedures have been divided into the following areas: flow
        identification, forwarding, and traffic treatment.  Flow
        identification includes those procedures related to matching
        IP-layer
        and higher-layer protocol header information to DetNet flow
        (state) information and service requirements. Flow
        identification is also sometimes called "traffic classification";
        for example, see <span>[<a href="#RFC5777" class="xref">RFC5777</a>]</span>.  Forwarding
        includes
        those procedures related to next-hop selection and
        delivery. Traffic treatment includes those procedures related to
        providing an identified flow with the required DetNet service.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
        DetNet IP data plane establishment and operational procedures
        also have requirements on the control and management systems
        for DetNet flows, and these are referred to in this section.
        Specifically, this section identifies a
        number of information elements that require support via the
        management and control interfaces supported by a DetNet node.
        The specific mechanism used for such support is out of the scope
        of this document.  A summary of the requirements for management- and
        control-related information is included.  Conformance
        language is not used in the summary, since it applies to future
        mechanisms such as those that may be provided in YANG models
        <span>[<a href="#I-D.ietf-detnet-yang" class="xref">DetNet-YANG</a>]</span>.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="ip-flow-id">
<section id="section-5.1">
        <h3 id="name-detnet-ip-flow-identificati">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-detnet-ip-flow-identificati" class="section-name selfRef">DetNet IP Flow Identification Procedures</a>
        </h3>
<p id="section-5.1-1">
          IP-layer and higher-layer protocol header information is used to identify
          DetNet flows. All DetNet implementations that support this document
          <span class="bcp14">MUST</span> identify individual DetNet flows based on the
          set of information identified in this section. Note that additional
          requirements for flow identification, e.g., to support
          other higher-layer protocols, may be defined in the future.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">
          The configuration and control information used to identify an
          individual DetNet flow <span class="bcp14">MUST</span> be ordered by an implementation.
          Implementations <span class="bcp14">MUST</span> support a fixed order when identifying
          flows and <span class="bcp14">MUST</span> identify a DetNet flow by the first set of
          matching flow information.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
<p id="section-5.1-3">
          Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
          identification when the implementation is acting as a
          DetNet end system, a relay node, or an edge node.<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<div id="ip-hdr">
<section id="section-5.1.1">
          <h4 id="name-ip-header-information">
<a href="#section-5.1.1" class="section-number selfRef">5.1.1. </a><a href="#name-ip-header-information" class="section-name selfRef">IP Header Information</a>
          </h4>
<p id="section-5.1.1-1">
            Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
            identification based on IP header information.  The IPv4
            header is defined in <span>[<a href="#RFC0791" class="xref">RFC0791</a>]</span>, and the IPv6
            is defined in <span>[<a href="#RFC8200" class="xref">RFC8200</a>]</span>.<a href="#section-5.1.1-1" class="pilcrow">¶</a></p>
<section id="section-5.1.1.1">
            <h5 id="name-source-address-field">
<a href="#section-5.1.1.1" class="section-number selfRef">5.1.1.1. </a><a href="#name-source-address-field" class="section-name selfRef">Source Address Field</a>
            </h5>
<p id="section-5.1.1.1-1">
              Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
              identification based on the Source Address field of an IP
              packet. Implementations <span class="bcp14">SHOULD</span> support longest prefix
              matching for this field (see <span>[<a href="#RFC1812" class="xref">RFC1812</a>]</span> and
              <span>[<a href="#RFC7608" class="xref">RFC7608</a>]</span>). Note that a prefix length of
              zero (0) effectively means that the field is ignored.<a href="#section-5.1.1.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.1.2">
            <h5 id="name-destination-address-field">
<a href="#section-5.1.1.2" class="section-number selfRef">5.1.1.2. </a><a href="#name-destination-address-field" class="section-name selfRef">Destination Address Field</a>
            </h5>
<p id="section-5.1.1.2-1">
              Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
              identification based on the Destination Address field of an IP
              packet. Implementations <span class="bcp14">SHOULD</span> support longest prefix
              matching for this field (see <span>[<a href="#RFC1812" class="xref">RFC1812</a>]</span> and
              <span>[<a href="#RFC7608" class="xref">RFC7608</a>]</span>). Note that a prefix length of
              zero (0) effectively means that the field is ignored.<a href="#section-5.1.1.2-1" class="pilcrow">¶</a></p>
<aside id="section-5.1.1.2-2">
              <p id="section-5.1.1.2-2.1">
              Note: Any IP address value is allowed, including an IP
              multicast destination address.<a href="#section-5.1.1.2-2.1" class="pilcrow">¶</a></p>
</aside>
</section>
<div id="nxt-proto-field">
<section id="section-5.1.1.3">
            <h5 id="name-ipv4-protocol-and-ipv6-next">
<a href="#section-5.1.1.3" class="section-number selfRef">5.1.1.3. </a><a href="#name-ipv4-protocol-and-ipv6-next" class="section-name selfRef">IPv4 Protocol and IPv6 Next Header Fields</a>
            </h5>
<p id="section-5.1.1.3-1">
              Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
              identification based on the IPv4 Protocol field when
              processing IPv4 packets and the IPv6 Next Header field
              when processing IPv6 packets. This includes 
              the next protocol
              values defined in <a href="#nxt-proto" class="xref">Section 5.1.2</a> and any other
              value, including zero.
              Implementations <span class="bcp14">SHOULD</span> allow for these fields to be
              ignored for a specific DetNet flow.<a href="#section-5.1.1.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-5.1.1.4">
            <h5 id="name-ipv4-type-of-service-and-ip">
<a href="#section-5.1.1.4" class="section-number selfRef">5.1.1.4. </a><a href="#name-ipv4-type-of-service-and-ip" class="section-name selfRef">IPv4 Type of Service and IPv6 Traffic Class Fields</a>
            </h5>
<p id="section-5.1.1.4-1">
              These fields are used to support differentiated services
              <span>[<a href="#RFC2474" class="xref">RFC2474</a>]</span> <span>[<a href="#RFC2475" class="xref">RFC2475</a>]</span>.
              Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
              identification based on the DSCP field in the IPv4 Type of
              Service field when processing IPv4 packets and the DSCP
              field in the IPv6 Traffic Class field when processing IPv6
              packets.  Implementations <span class="bcp14">MUST</span> support list-based matching
              of DSCP values, where the list is composed of possible
              field values that are to be considered when identifying a
              specific DetNet flow.  Implementations <span class="bcp14">SHOULD</span> allow for
              this field to be ignored for a specific DetNet flow.<a href="#section-5.1.1.4-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.1.5">
            <h5 id="name-ipv6-flow-label-field">
<a href="#section-5.1.1.5" class="section-number selfRef">5.1.1.5. </a><a href="#name-ipv6-flow-label-field" class="section-name selfRef">IPv6 Flow Label Field</a>
            </h5>
<p id="section-5.1.1.5-1">
              Implementations of this document <span class="bcp14">SHOULD</span> support identification of
              DetNet flows based on the IPv6 Flow Label field. Implementations
              that support matching based on this field <span class="bcp14">MUST</span> allow for it
              to be ignored for a specific DetNet flow.  When this field
              is used to identify a specific DetNet flow, implementations <span class="bcp14">MAY</span>
              exclude the IPv6 Next Header field and next header information as
              part of DetNet flow identification.<a href="#section-5.1.1.5-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="nxt-proto">
<section id="section-5.1.2">
          <h4 id="name-other-protocol-header-infor">
<a href="#section-5.1.2" class="section-number selfRef">5.1.2. </a><a href="#name-other-protocol-header-infor" class="section-name selfRef">Other Protocol Header Information</a>
          </h4>
<p id="section-5.1.2-1">
            Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
            identification based on header information identified in this
            section. Support for TCP, UDP, ICMP, and IPsec flows is defined.
            Future documents are expected to define support for other
            protocols.<a href="#section-5.1.2-1" class="pilcrow">¶</a></p>
<section id="section-5.1.2.1">
            <h5 id="name-tcp-and-udp">
<a href="#section-5.1.2.1" class="section-number selfRef">5.1.2.1. </a><a href="#name-tcp-and-udp" class="section-name selfRef">TCP and UDP</a>
            </h5>
<p id="section-5.1.2.1-1">
              DetNet flow identification for TCP <span>[<a href="#RFC0793" class="xref">RFC0793</a>]</span> and UDP <span>[<a href="#RFC0768" class="xref">RFC0768</a>]</span> is
              achieved based on the Source and Destination
              Port fields carried in each protocol's header.  These
              fields share a common format and common DetNet
              flow identification procedures.<a href="#section-5.1.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1.2.1-2">
              The rules defined in this section only apply when the
              IPv4 Protocol or IPv6 Next Header field contains the
              IANA-defined value for UDP or TCP.<a href="#section-5.1.2.1-2" class="pilcrow">¶</a></p>
<section id="section-5.1.2.1.1">
              <h6 id="name-source-port-field">
<a href="#section-5.1.2.1.1" class="section-number selfRef">5.1.2.1.1. </a><a href="#name-source-port-field" class="section-name selfRef">Source Port Field</a>
              </h6>
<p id="section-5.1.2.1.1-1">
                Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
                identification based on the Source Port field of a TCP or
                UDP packet. Implementations <span class="bcp14">MUST</span> support flow
                identification based on a particular value carried in the
                field, i.e., an exact value.  Implementations <span class="bcp14">SHOULD</span> support
                range-based port matching. Implementation <span class="bcp14">MUST</span> also allow
                for the field to be ignored for a specific DetNet flow.<a href="#section-5.1.2.1.1-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.2.1.2">
              <h6 id="name-destination-port-field">
<a href="#section-5.1.2.1.2" class="section-number selfRef">5.1.2.1.2. </a><a href="#name-destination-port-field" class="section-name selfRef">Destination Port Field</a>
              </h6>
<p id="section-5.1.2.1.2-1">
                Implementations of this document <span class="bcp14">MUST</span> support DetNet flow
                identification based on the Destination Port field of a TCP or
                UDP packet. Implementations <span class="bcp14">MUST</span> support flow
                identification based on a particular value carried in the
                field, i.e., an exact value.  Implementations <span class="bcp14">SHOULD</span> support
                range-based port matching. Implementation <span class="bcp14">MUST</span> also allow
                for the field to be ignored for a specific DetNet flow.<a href="#section-5.1.2.1.2-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-5.1.2.2">
            <h5 id="name-icmp">
<a href="#section-5.1.2.2" class="section-number selfRef">5.1.2.2. </a><a href="#name-icmp" class="section-name selfRef">ICMP</a>
            </h5>
<p id="section-5.1.2.2-1">
              DetNet flow identification for ICMP  <span>[<a href="#RFC0792" class="xref">RFC0792</a>]</span> is achieved based on the 
              protocol number in the IP header. Note that ICMP type is not included in the 
              flow definition.<a href="#section-5.1.2.2-1" class="pilcrow">¶</a></p>
</section>
<section id="section-5.1.2.3">
            <h5 id="name-ipsec-ah-and-esp">
<a href="#section-5.1.2.3" class="section-number selfRef">5.1.2.3. </a><a href="#name-ipsec-ah-and-esp" class="section-name selfRef">IPsec AH and ESP</a>
            </h5>
<p id="section-5.1.2.3-1">
              IPsec Authentication Header (AH) <span>[<a href="#RFC4302" class="xref">RFC4302</a>]</span>
              and Encapsulating Security Payload (ESP) <span>[<a href="#RFC4303" class="xref">RFC4303</a>]</span> share a common format for the Security
              Parameters Index (SPI) field.  Implementations <span class="bcp14">MUST</span>
              support flow identification based on a particular value
              carried in the field, i.e., an exact value.  Implementations
              <span class="bcp14">SHOULD</span>
              also allow for the field to be ignored for a specific
              DetNet flow.<a href="#section-5.1.2.3-1" class="pilcrow">¶</a></p>
<p id="section-5.1.2.3-2">
              The rules defined in this section only apply when the
              IPv4 Protocol or IPv6 Next Header field contains the
              IANA-defined value for AH or ESP.<a href="#section-5.1.2.3-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
</section>
</div>
<div id="ip-fwd">
<section id="section-5.2">
        <h3 id="name-forwarding-procedures">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-forwarding-procedures" class="section-name selfRef">Forwarding Procedures</a>
        </h3>
<p id="section-5.2-1">
          General requirements for IP nodes are defined in <span>[<a href="#RFC1122" class="xref">RFC1122</a>]</span>, <span>[<a href="#RFC1812" class="xref">RFC1812</a>]</span>, and <span>[<a href="#RFC8504" class="xref">RFC8504</a>]</span>
          and are not modified by this document. The
          typical next-hop selection process is impacted by DetNet.
          Specifically, implementations of this document <span class="bcp14">SHALL</span> use
          management and control information to select the one or more
          outgoing interfaces and next hops to be used for a packet
          associated with a DetNet flow. Specific management and control
          information will be defined in future documents, e.g., <span>[<a href="#I-D.ietf-detnet-yang" class="xref">DetNet-YANG</a>]</span>.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
          The use of multiple paths or links, e.g., ECMP, to support a
          single DetNet flow is <span class="bcp14">NOT RECOMMENDED</span>. ECMP <span class="bcp14">MAY</span> be used for
          non-DetNet flows within a DetNet domain.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">
          The above implies that management and control functions will
          be defined to support this requirement, e.g., see <span>[<a href="#I-D.ietf-detnet-yang" class="xref">DetNet-YANG</a>]</span>.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ip-svc">
<section id="section-5.3">
        <h3 id="name-detnet-ip-traffic-treatment">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-detnet-ip-traffic-treatment" class="section-name selfRef">DetNet IP Traffic Treatment Procedures</a>
        </h3>
<p id="section-5.3-1">
          Implementations of this document must ensure that a DetNet flow
          receives the traffic treatment that is provisioned for it via
          configuration or the Controller Plane, e.g., via <span>[<a href="#I-D.ietf-detnet-yang" class="xref">DetNet-YANG</a>]</span>.
          General information on DetNet service can be found in <span>[<a href="#I-D.ietf-detnet-flow-information-model" class="xref">DetNet-Flow-Info</a>]</span>.  Typical
          mechanisms used to provide different treatment to different flows
          include the allocation of system resources (such as queues and
          buffers) and provisioning of related parameters (such as shaping and
          policing). Support can also be provided via an underlying network
          technology such as MPLS <span>[<a href="#I-D.ietf-detnet-ip-over-mpls" class="xref">DetNet-IP-over-MPLS</a>]</span> or
          IEEE 802.1 TSN <span>[<a href="#I-D.ietf-detnet-ip-over-tsn" class="xref">DetNet-IP-over-TSN</a>]</span>.  
                  Other mechanisms than the ones used in the TSN case are outside the 
                  scope of this document.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="ip-flow-id-info">
<section id="section-6">
      <h2 id="name-management-and-control-info">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-management-and-control-info" class="section-name selfRef">Management and Control Information Summary</a>
      </h2>
<p id="section-6-1">
            The following summarizes the set of information that is needed to
            identify individual and aggregated DetNet flows:<a href="#section-6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.1">IPv4 and IPv6 Source Address field.<a href="#section-6-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.2">IPv4 and IPv6 source address prefix length, where a zero
              (0) value effectively means that the Source Address field is
              ignored.<a href="#section-6-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.3">IPv4 and IPv6 Destination Address field.<a href="#section-6-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.4">IPv4 and IPv6 destination address prefix length, where a
              zero (0) value effectively means that the Destination Address field is
              ignored.<a href="#section-6-2.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.5">IPv4 Protocol field. A limited set of values is allowed,
              and the ability to ignore this field is desirable.<a href="#section-6-2.5" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.6">IPv6 Next Header field. A limited set of values is allowed,
              and the ability to ignore this field is desirable.<a href="#section-6-2.6" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.7">
          <p id="section-6-2.7.1">For the IPv4 Type of Service and IPv6 Traffic Class fields:<a href="#section-6-2.7.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6-2.7.2.1">Whether or not the DSCP field is used in flow identification.
                                Use of the DSCP field for flow identification is optional.<a href="#section-6-2.7.2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-6-2.7.2.2">If the DSCP field is used to identify a flow, then the flow
                                identification information (for that flow) includes a list of
                                DSCPs used by that flow.<a href="#section-6-2.7.2.2" class="pilcrow">¶</a>
</li>
          </ul>
</li>
        <li class="normal" id="section-6-2.8">IPv6 Flow Label field. This field can be optionally used
              for matching.  When used, this field can be used instead of matching against 
                          the Next Header field.<a href="#section-6-2.8" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.9">TCP and UDP Source Port. Support for both exact and wildcard matching is
              required. Port ranges can optionally be used.<a href="#section-6-2.9" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.10">TCP and UDP Destination Port. Support for both exact and wildcard matching is
              required. Port ranges can optionally be used.<a href="#section-6-2.10" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.11">IPsec Header SPI field. Exact matching is
              required. Support for wildcard matching is
              recommended.<a href="#section-6-2.11" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-6-2.12">For end systems, an optional maximum IP packet size
              that should be used for that outgoing DetNet IP flow.<a href="#section-6-2.12" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-6-3">
            This information <span class="bcp14">MUST</span> be provisioned per DetNet flow via
            configuration, e.g., via the Controller Plane or the management plane.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">
            An implementation <span class="bcp14">MUST</span> support ordering of the
            set of information used to identify an
            individual DetNet flow.  This can, for example, be
            used to provide a DetNet service for a specific UDP flow, with
            unique Source and Destination Port field values, while
            providing a different service for the aggregate of all other
            flows with that same UDP Destination Port value.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
            It is the responsibility of the DetNet Controller Plane to
            properly provision both flow identification information and
            the flow-specific resources needed to provide the traffic
            treatment needed to meet each flow's service requirements.
            This applies for aggregated and individual flows.<a href="#section-6-5" class="pilcrow">¶</a></p>
</section>
</div>
<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">
       Detailed security considerations for DetNet are cataloged in
       <span>[<a href="#DetNet-Security" class="xref">DetNet-Security</a>]</span>, and more general security considerations
       are described in <span>[<a href="#RFC8655" class="xref">RFC8655</a>]</span>. This section
       exclusively considers security considerations that are specific to the DetNet
       IP data plane.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
       Security aspects that are unique to DetNet are those whose aim is to
       provide the specific QoS aspects of DetNet, which are
       primarily to deliver data flows with extremely low packet loss rates
       and bounded end-to-end delivery latency.
       Achieving such loss rates and bounded latency may not be possible
       in the face of a highly capable adversary, such as the one
       envisioned by the Internet Threat Model of BCP 72 <span>[<a href="#RFC3552" class="xref">RFC3552</a>]</span> that can
       arbitrarily drop or delay any or all traffic.  In order to
       present meaningful security considerations, we consider a
       somewhat weaker attacker who does not control the physical links
       of the DetNet domain but may have the ability to control a
       network node within the boundary of the DetNet domain.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
        The primary consideration for the DetNet data plane is to maintain
        integrity of data and delivery of the associated DetNet service traversing
        the DetNet network.
        Since no DetNet-specific fields are available in the DetNet IP
        data plane,
        the integrity and confidentiality of application flows can be protected through whatever means are
        provided by the underlying technology. For example, encryption may be
        used, such as that provided by IPsec <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span> for IP
        flows and/or by an underlying sub-network using
        MACsec
        <span>[<a href="#IEEE802.1AE-2018" class="xref">IEEE802.1AE-2018</a>]</span> for IP over
        Ethernet (Layer 2) flows.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">
        From a data plane perspective, this document does not add or modify any
        header information.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">
        At the management and control level, DetNet flows are identified on a
        per-flow basis, which may provide Controller Plane
        attackers with additional information about the data flows (when
        compared to Controller Planes that do not include per-flow identification).
        This is an inherent property of DetNet that has security
        implications that should be considered when determining if DetNet is
        a suitable technology for any given use case.<a href="#section-7-5" class="pilcrow">¶</a></p>
<p id="section-7-6">
        To provide uninterrupted availability of the DetNet service,
        provisions can be made against DoS attacks and delay attacks. To
        protect against DoS attacks, excess traffic due to malicious or
        malfunctioning devices can be prevented or mitigated -- for example,
        through the use of existing mechanisms such as policing and shaping
        applied at the input of a DetNet domain or within an edge IEEE 802.1
        TSN domain. To prevent DetNet packets from being delayed by an entity
        external to a DetNet domain, DetNet technology definitions can allow
        for the mitigation of man-in-the-middle attacks -- for example,
        through the use of authentication and authorization of devices within the
        DetNet domain.<a href="#section-7-6" class="pilcrow">¶</a></p>
</section>
<div id="iana">
<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">
        This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</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="RFC0768">[RFC0768]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"User Datagram Protocol"</span>, <span class="seriesInfo">STD 6</span>, <span class="seriesInfo">RFC 768</span>, <span class="seriesInfo">DOI 10.17487/RFC0768</span>, <time datetime="1980-08" class="refDate">August 1980</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc768">https://www.rfc-editor.org/info/rfc768</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0791">[RFC0791]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 791</span>, <span class="seriesInfo">DOI 10.17487/RFC0791</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc791">https://www.rfc-editor.org/info/rfc791</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0792">[RFC0792]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Control Message Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 792</span>, <span class="seriesInfo">DOI 10.17487/RFC0792</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc792">https://www.rfc-editor.org/info/rfc792</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0793">[RFC0793]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Transmission Control Protocol"</span>, <span class="seriesInfo">STD 7</span>, <span class="seriesInfo">RFC 793</span>, <span class="seriesInfo">DOI 10.17487/RFC0793</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc793">https://www.rfc-editor.org/info/rfc793</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1812">[RFC1812]</dt>
        <dd>
<span class="refAuthor">Baker, F., Ed.</span>, <span class="refTitle">"Requirements for IP Version 4 Routers"</span>, <span class="seriesInfo">RFC 1812</span>, <span class="seriesInfo">DOI 10.17487/RFC1812</span>, <time datetime="1995-06" class="refDate">June 1995</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1812">https://www.rfc-editor.org/info/rfc1812</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="RFC2474">[RFC2474]</dt>
        <dd>
<span class="refAuthor">Nichols, K.</span><span class="refAuthor">, Blake, S.</span><span class="refAuthor">, Baker, F.</span><span class="refAuthor">, and D. Black</span>, <span class="refTitle">"Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers"</span>, <span class="seriesInfo">RFC 2474</span>, <span class="seriesInfo">DOI 10.17487/RFC2474</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2474">https://www.rfc-editor.org/info/rfc2474</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4301">[RFC4301]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span><span class="refAuthor"> and K. Seo</span>, <span class="refTitle">"Security Architecture for the Internet Protocol"</span>, <span class="seriesInfo">RFC 4301</span>, <span class="seriesInfo">DOI 10.17487/RFC4301</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4301">https://www.rfc-editor.org/info/rfc4301</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4302">[RFC4302]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span>, <span class="refTitle">"IP Authentication Header"</span>, <span class="seriesInfo">RFC 4302</span>, <span class="seriesInfo">DOI 10.17487/RFC4302</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4302">https://www.rfc-editor.org/info/rfc4302</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4303">[RFC4303]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span>, <span class="refTitle">"IP Encapsulating Security Payload (ESP)"</span>, <span class="seriesInfo">RFC 4303</span>, <span class="seriesInfo">DOI 10.17487/RFC4303</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4303">https://www.rfc-editor.org/info/rfc4303</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7608">[RFC7608]</dt>
        <dd>
<span class="refAuthor">Boucadair, M.</span><span class="refAuthor">, Petrescu, A.</span><span class="refAuthor">, and F. Baker</span>, <span class="refTitle">"IPv6 Prefix Length Recommendation for Forwarding"</span>, <span class="seriesInfo">BCP 198</span>, <span class="seriesInfo">RFC 7608</span>, <span class="seriesInfo">DOI 10.17487/RFC7608</span>, <time datetime="2015-07" class="refDate">July 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7608">https://www.rfc-editor.org/info/rfc7608</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>
<dt id="RFC8200">[RFC8200]</dt>
        <dd>
<span class="refAuthor">Deering, S.</span><span class="refAuthor"> and R. Hinden</span>, <span class="refTitle">"Internet Protocol, Version 6 (IPv6) Specification"</span>, <span class="seriesInfo">STD 86</span>, <span class="seriesInfo">RFC 8200</span>, <span class="seriesInfo">DOI 10.17487/RFC8200</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8200">https://www.rfc-editor.org/info/rfc8200</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8655">[RFC8655]</dt>
        <dd>
<span class="refAuthor">Finn, N.</span><span class="refAuthor">, Thubert, P.</span><span class="refAuthor">, Varga, B.</span><span class="refAuthor">, and J. Farkas</span>, <span class="refTitle">"Deterministic Networking Architecture"</span>, <span class="seriesInfo">RFC 8655</span>, <span class="seriesInfo">DOI 10.17487/RFC8655</span>, <time datetime="2019-10" class="refDate">October 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8655">https://www.rfc-editor.org/info/rfc8655</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8938">[RFC8938]</dt>
      <dd>
<span class="refAuthor">Varga, B., Ed.</span><span class="refAuthor">, Farkas, J.</span><span class="refAuthor">, Berger, L.</span><span class="refAuthor">, Malis, A.</span><span class="refAuthor">, and S. Bryant</span>, <span class="refTitle">"Deterministic Networking (DetNet) Data Plane Framework"</span>, <span class="seriesInfo">RFC 8938</span>, <span class="seriesInfo">DOI 10.17487/RFC8938</span>, <time datetime="2020-11" class="refDate">November 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc8938">https://www.rfc-editor.org/rfc/rfc8938</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="I-D.ietf-detnet-flow-information-model">[DetNet-Flow-Info]</dt>
        <dd>
<span class="refAuthor">Varga, B.</span><span class="refAuthor">, Farkas, J.</span><span class="refAuthor">, Cummings, R.</span><span class="refAuthor">, Jiang, Y.</span><span class="refAuthor">, and D. Fedyk</span>, <span class="refTitle">"DetNet Flow Information Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-flow-information-model-11</span>, <time datetime="2020-10-21" class="refDate">21 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-11">https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-11</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-detnet-ip-over-mpls">[DetNet-IP-over-MPLS]</dt>
        <dd>
<span class="refAuthor">Varga, B., Ed.</span><span class="refAuthor">, Berger, L.</span><span class="refAuthor">, Fedyk, D.</span><span class="refAuthor">, Bryant, S.</span><span class="refAuthor">, and J. Korhonen</span>, <span class="refTitle">"DetNet Data Plane: IP over MPLS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-ip-over-mpls-09</span>, <time datetime="2020-10-11" class="refDate">11 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-09">https://tools.ietf.org/html/draft-ietf-detnet-ip-over-mpls-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-detnet-ip-over-tsn">[DetNet-IP-over-TSN]</dt>
        <dd>
<span class="refAuthor">Varga, B., Ed.</span><span class="refAuthor">, Farkas, J.</span><span class="refAuthor">, Malis, A.</span><span class="refAuthor">, and S. Bryant</span>, <span class="refTitle">"DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-ip-over-tsn-04</span>, <time datetime="2020-11-02" class="refDate">2 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-ip-over-tsn-04">https://tools.ietf.org/html/draft-ietf-detnet-ip-over-tsn-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DetNet-MPLS">[DetNet-MPLS]</dt>
        <dd>
<span class="refAuthor">Varga, B., Ed.</span><span class="refAuthor">, Farkas, J.</span><span class="refAuthor">, Berger, L.</span><span class="refAuthor">, Malis, A.</span><span class="refAuthor">, Bryant, S.</span><span class="refAuthor">, and J. Korhonen</span>, <span class="refTitle">"DetNet Data Plane: MPLS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-mpls-13</span>, <time datetime="2020-10-11" class="refDate">11 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-mpls-13">https://tools.ietf.org/html/draft-ietf-detnet-mpls-13</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DetNet-Security">[DetNet-Security]</dt>
        <dd>
<span class="refAuthor">Grossman, E., Ed.</span><span class="refAuthor">, Mizrahi, T.</span><span class="refAuthor">, and A. Hacker</span>, <span class="refTitle">"Deterministic Networking (DetNet) Security Considerations"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-security-12</span>, <time datetime="2020-10-02" class="refDate">2 October 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-security-12">https://tools.ietf.org/html/draft-ietf-detnet-security-12</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-detnet-tsn-vpn-over-mpls">[DetNet-TSN-over-MPLS]</dt>
        <dd>
<span class="refAuthor">Varga, B., Ed.</span><span class="refAuthor">, Farkas, J.</span><span class="refAuthor">, Malis, A.</span><span class="refAuthor">, Bryant, S.</span><span class="refAuthor">, and D. Fedyk</span>, <span class="refTitle">"DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-tsn-vpn-over-mpls-04</span>, <time datetime="2020-11-02" class="refDate">2 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-over-mpls-04">https://tools.ietf.org/html/draft-ietf-detnet-tsn-vpn-over-mpls-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-detnet-yang">[DetNet-YANG]</dt>
        <dd>
<span class="refAuthor">Geng, X.</span><span class="refAuthor">, Chen, M.</span><span class="refAuthor">, Ryoo, Y.</span><span class="refAuthor">, Fedyk, D.</span><span class="refAuthor">, Rahman, R.</span><span class="refAuthor">, and Z. Li</span>, <span class="refTitle">"Deterministic Networking (DetNet) Configuration YANG Model"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-detnet-yang-09</span>, <time datetime="2020-11-16" class="refDate">16 November 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-detnet-yang-09">https://tools.ietf.org/html/draft-ietf-detnet-yang-09</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEE802.1AE-2018">[IEEE802.1AE-2018]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"IEEE Standard for Local and metropolitan area networks-Media Access Control (MAC) Security"</span>, <span class="seriesInfo">IEEE 802.1AE-2018</span>, <span class="seriesInfo">DOI 10.1109/IEEESTD.2018.8585421</span>, <time datetime="2018-12" class="refDate">December 2018</time>, <span>&lt;<a href="https://ieeexplore.ieee.org/document/8585421">https://ieeexplore.ieee.org/document/8585421</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IEEE802.1TSNTG">[IEEE802.1TSNTG]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"Time-Sensitive Networking (TSN) Task Group"</span>, <span>&lt;<a href="https://1.ieee802.org/tsn/">https://1.ieee802.org/tsn/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1122">[RFC1122]</dt>
        <dd>
<span class="refAuthor">Braden, R., Ed.</span>, <span class="refTitle">"Requirements for Internet Hosts - Communication Layers"</span>, <span class="seriesInfo">STD 3</span>, <span class="seriesInfo">RFC 1122</span>, <span class="seriesInfo">DOI 10.17487/RFC1122</span>, <time datetime="1989-10" class="refDate">October 1989</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1122">https://www.rfc-editor.org/info/rfc1122</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC1191">[RFC1191]</dt>
        <dd>
<span class="refAuthor">Mogul, J.</span><span class="refAuthor"> and S. Deering</span>, <span class="refTitle">"Path MTU discovery"</span>, <span class="seriesInfo">RFC 1191</span>, <span class="seriesInfo">DOI 10.17487/RFC1191</span>, <time datetime="1990-11" class="refDate">November 1990</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1191">https://www.rfc-editor.org/info/rfc1191</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2475">[RFC2475]</dt>
        <dd>
<span class="refAuthor">Blake, S.</span><span class="refAuthor">, Black, D.</span><span class="refAuthor">, Carlson, M.</span><span class="refAuthor">, Davies, E.</span><span class="refAuthor">, Wang, Z.</span><span class="refAuthor">, and W. Weiss</span>, <span class="refTitle">"An Architecture for Differentiated Services"</span>, <span class="seriesInfo">RFC 2475</span>, <span class="seriesInfo">DOI 10.17487/RFC2475</span>, <time datetime="1998-12" class="refDate">December 1998</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2475">https://www.rfc-editor.org/info/rfc2475</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3290">[RFC3290]</dt>
        <dd>
<span class="refAuthor">Bernet, Y.</span><span class="refAuthor">, Blake, S.</span><span class="refAuthor">, Grossman, D.</span><span class="refAuthor">, and A. Smith</span>, <span class="refTitle">"An Informal Management Model for Diffserv Routers"</span>, <span class="seriesInfo">RFC 3290</span>, <span class="seriesInfo">DOI 10.17487/RFC3290</span>, <time datetime="2002-05" class="refDate">May 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3290">https://www.rfc-editor.org/info/rfc3290</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3473">[RFC3473]</dt>
        <dd>
<span class="refAuthor">Berger, L., Ed.</span>, <span class="refTitle">"Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"</span>, <span class="seriesInfo">RFC 3473</span>, <span class="seriesInfo">DOI 10.17487/RFC3473</span>, <time datetime="2003-01" class="refDate">January 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3473">https://www.rfc-editor.org/info/rfc3473</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3552">[RFC3552]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span><span class="refAuthor"> and B. Korver</span>, <span class="refTitle">"Guidelines for Writing RFC Text on Security Considerations"</span>, <span class="seriesInfo">BCP 72</span>, <span class="seriesInfo">RFC 3552</span>, <span class="seriesInfo">DOI 10.17487/RFC3552</span>, <time datetime="2003-07" class="refDate">July 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3552">https://www.rfc-editor.org/info/rfc3552</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3670">[RFC3670]</dt>
        <dd>
<span class="refAuthor">Moore, B.</span><span class="refAuthor">, Durham, D.</span><span class="refAuthor">, Strassner, J.</span><span class="refAuthor">, Westerinen, A.</span><span class="refAuthor">, and W. Weiss</span>, <span class="refTitle">"Information Model for Describing Network Device QoS Datapath Mechanisms"</span>, <span class="seriesInfo">RFC 3670</span>, <span class="seriesInfo">DOI 10.17487/RFC3670</span>, <time datetime="2004-01" class="refDate">January 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3670">https://www.rfc-editor.org/info/rfc3670</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5120">[RFC5120]</dt>
        <dd>
<span class="refAuthor">Przygienda, T.</span><span class="refAuthor">, Shen, N.</span><span class="refAuthor">, and N. Sheth</span>, <span class="refTitle">"M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)"</span>, <span class="seriesInfo">RFC 5120</span>, <span class="seriesInfo">DOI 10.17487/RFC5120</span>, <time datetime="2008-02" class="refDate">February 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5120">https://www.rfc-editor.org/info/rfc5120</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5777">[RFC5777]</dt>
        <dd>
<span class="refAuthor">Korhonen, J.</span><span class="refAuthor">, Tschofenig, H.</span><span class="refAuthor">, Arumaithurai, M.</span><span class="refAuthor">, Jones, M., Ed.</span><span class="refAuthor">, and A. Lior</span>, <span class="refTitle">"Traffic Classification and Quality of Service (QoS) Attributes for Diameter"</span>, <span class="seriesInfo">RFC 5777</span>, <span class="seriesInfo">DOI 10.17487/RFC5777</span>, <time datetime="2010-02" class="refDate">February 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5777">https://www.rfc-editor.org/info/rfc5777</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7551">[RFC7551]</dt>
        <dd>
<span class="refAuthor">Zhang, F., Ed.</span><span class="refAuthor">, Jing, R.</span><span class="refAuthor">, and R. Gandhi, Ed.</span>, <span class="refTitle">"RSVP-TE Extensions for Associated Bidirectional Label Switched Paths (LSPs)"</span>, <span class="seriesInfo">RFC 7551</span>, <span class="seriesInfo">DOI 10.17487/RFC7551</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7551">https://www.rfc-editor.org/info/rfc7551</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7657">[RFC7657]</dt>
        <dd>
<span class="refAuthor">Black, D., Ed.</span><span class="refAuthor"> and P. Jones</span>, <span class="refTitle">"Differentiated Services (Diffserv) and Real-Time Communication"</span>, <span class="seriesInfo">RFC 7657</span>, <span class="seriesInfo">DOI 10.17487/RFC7657</span>, <time datetime="2015-11" class="refDate">November 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7657">https://www.rfc-editor.org/info/rfc7657</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8201">[RFC8201]</dt>
        <dd>
<span class="refAuthor">McCann, J.</span><span class="refAuthor">, Deering, S.</span><span class="refAuthor">, Mogul, J.</span><span class="refAuthor">, and R. Hinden, Ed.</span>, <span class="refTitle">"Path MTU Discovery for IP version 6"</span>, <span class="seriesInfo">STD 87</span>, <span class="seriesInfo">RFC 8201</span>, <span class="seriesInfo">DOI 10.17487/RFC8201</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8201">https://www.rfc-editor.org/info/rfc8201</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8504">[RFC8504]</dt>
      <dd>
<span class="refAuthor">Chown, T.</span><span class="refAuthor">, Loughney, J.</span><span class="refAuthor">, and T. Winters</span>, <span class="refTitle">"IPv6 Node Requirements"</span>, <span class="seriesInfo">BCP 220</span>, <span class="seriesInfo">RFC 8504</span>, <span class="seriesInfo">DOI 10.17487/RFC8504</span>, <time datetime="2019-01" class="refDate">January 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8504">https://www.rfc-editor.org/info/rfc8504</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="acks">
<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">
        The authors wish to thank <span class="contact-name">Pat Thaler</span>, <span class="contact-name">Norman Finn</span>, <span class="contact-name">Loa Andersson</span>, <span class="contact-name">David Black</span>,
        <span class="contact-name">Rodney Cummings</span>, <span class="contact-name">Ethan         Grossman</span>, <span class="contact-name">Tal Mizrahi</span>, <span class="contact-name">David Mozes</span>, <span class="contact-name">Craig Gunther</span>,
        <span class="contact-name">George Swallow</span>, <span class="contact-name">Yuanlong         Jiang</span>, and <span class="contact-name">Carlos J. Bernardos</span> for their
        various contributions to this work. <span class="contact-name">David Black</span> served as
        technical advisor to the DetNet working group during the
        development of this document and provided many valuable
        comments. IESG comments were provided by <span class="contact-name">Murray Kucherawy</span>, 
        <span class="contact-name">Roman Danyliw</span>, <span class="contact-name">Alvaro         Retana</span>, <span class="contact-name">Benjamin Kaduk</span>, <span class="contact-name">Rob Wilton</span>, and
        <span class="contact-name">Érik Vyncke</span>.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="contrib">
<section id="section-appendix.b">
      <h2 id="name-contributors">
<a href="#name-contributors" class="section-name selfRef">Contributors</a>
      </h2>
<p id="section-appendix.b-1">
The editor of this document wishes to thank and acknowledge the following
people who contributed substantially to the content of this document and
should be considered coauthors:<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Jouni Korhonen</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jouni.nospam@gmail.com" class="email">jouni.nospam@gmail.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Andrew G. Malis</span></div>
<div dir="auto" class="left"><span class="org">Malis Consulting</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:agmalis@gmail.com" class="email">agmalis@gmail.com</a>
</div>
</address>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.c">
      <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">Balázs Varga (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="locality">Budapest</span></div>
<div dir="auto" class="left"><span class="street-address">Magyar Tudosok krt. 11.</span></div>
<div dir="auto" class="left"><span class="postal-code">1117</span></div>
<div dir="auto" class="left"><span class="country-name">Hungary</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:balazs.a.varga@ericsson.com" class="email">balazs.a.varga@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">János Farkas</span></div>
<div dir="auto" class="left"><span class="org">Ericsson</span></div>
<div dir="auto" class="left"><span class="locality">Budapest</span></div>
<div dir="auto" class="left"><span class="street-address">Magyar Tudosok krt. 11.</span></div>
<div dir="auto" class="left"><span class="postal-code">1117</span></div>
<div dir="auto" class="left"><span class="country-name">Hungary</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:janos.farkas@ericsson.com" class="email">janos.farkas@ericsson.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Lou Berger</span></div>
<div dir="auto" class="left"><span class="org">LabN Consulting, L.L.C.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:lberger@labn.net" class="email">lberger@labn.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Don Fedyk</span></div>
<div dir="auto" class="left"><span class="org">LabN Consulting, L.L.C.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:dfedyk@labn.net" class="email">dfedyk@labn.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stewart Bryant</span></div>
<div dir="auto" class="left"><span class="org">Futurewei Technologies</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:sb@stewartbryant.com" class="email">sb@stewartbryant.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>