File: rfc9223.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 (3976 lines) | stat: -rw-r--r-- 204,734 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 9223: Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)</title>
<meta content="Waqar Zia" name="author">
<meta content="Thomas Stockhammer" name="author">
<meta content="Lenaig Chaponniere" name="author">
<meta content="Giridhar Mandyam" name="author">
<meta content="Michael Luby" name="author">
<meta content="
       
   The Real-time Transport Object delivery over Unidirectional Transport
   (ROUTE) protocol is specified for robust delivery of Application Objects,
   including Application Objects with real-time delivery constraints, to
   receivers over a unidirectional transport.  Application Objects consist of
   data that has meaning to applications that use the ROUTE protocol for
   delivery of data to receivers; for example, it can be a file, a Dynamic
   Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a
   WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming
   applications. 
       
   The ROUTE protocol is suitable for unicast, broadcast, and multicast
   transport. Therefore, it can be run over UDP/IP, including multicast
   IP. The ROUTE protocol can leverage the features of the underlying
   protocol layer, e.g., to provide security, it can leverage IP security
   protocols such as IPsec. 
       
   This document specifies the ROUTE protocol such that it could be used
   by a variety of services for delivery of Application Objects by
   specifying their own profiles of this protocol (e.g., by adding or
   constraining some features). 
       
   This is not an IETF specification and does not have IETF consensus. 
    " name="description">
<meta content="xml2rfc 3.12.2" name="generator">
<meta content="Multicast" name="keyword">
<meta content="Broadcast" name="keyword">
<meta content="FEC" name="keyword">
<meta content="DASH" name="keyword">
<meta content="HLS" name="keyword">
<meta content="FLUTE" name="keyword">
<meta content="9223" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.2
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9223.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.ulBare, li.ulBare {
  margin-left: 0em !important;
}
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;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#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: auto;
  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";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9223" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-zia-route-06" 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 9223</td>
<td class="center">ROUTE</td>
<td class="right">April 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Zia, et al.</td>
<td class="center">Informational</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Independent Submission</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9223" class="eref">9223</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-04" class="published">April 2022</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">W. Zia</div>
<div class="org">Qualcomm CDMA Technologies GmbH</div>
</div>
<div class="author">
      <div class="author-name">T. Stockhammer</div>
<div class="org">Qualcomm CDMA Technologies GmbH</div>
</div>
<div class="author">
      <div class="author-name">L. Chaponniere</div>
<div class="org">Qualcomm Technologies Inc.</div>
</div>
<div class="author">
      <div class="author-name">G. Mandyam</div>
<div class="org">Qualcomm Technologies Inc.</div>
</div>
<div class="author">
      <div class="author-name">M. Luby</div>
<div class="org">BitRipple, Inc.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9223</h1>
<h1 id="title">Real-Time Transport Object Delivery over Unidirectional Transport (ROUTE)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   The Real-time Transport Object delivery over Unidirectional Transport
   (ROUTE) protocol is specified for robust delivery of Application Objects,
   including Application Objects with real-time delivery constraints, to
   receivers over a unidirectional transport.  Application Objects consist of
   data that has meaning to applications that use the ROUTE protocol for
   delivery of data to receivers; for example, it can be a file, a Dynamic
   Adaptive Streaming over HTTP (DASH) or HTTP Live Streaming (HLS) segment, a
   WAV audio clip, etc. The ROUTE protocol also supports low-latency streaming
   applications.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">
   The ROUTE protocol is suitable for unicast, broadcast, and multicast
   transport. Therefore, it can be run over UDP/IP, including multicast
   IP. The ROUTE protocol can leverage the features of the underlying
   protocol layer, e.g., to provide security, it can leverage IP security
   protocols such as IPsec.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">
   This document specifies the ROUTE protocol such that it could be used
   by a variety of services for delivery of Application Objects by
   specifying their own profiles of this protocol (e.g., by adding or
   constraining some features).<a href="#section-abstract-3" class="pilcrow">¶</a></p>
<p id="section-abstract-4">
   This is not an IETF specification and does not have IETF consensus.<a href="#section-abstract-4" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This is a contribution to the RFC Series, independently of any
            other RFC stream.  The RFC Editor has chosen to publish this
            document at its discretion and makes no statement about its value
            for implementation or deployment.  Documents approved for
            publication by the RFC Editor are not candidates for any level of
            Internet Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9223">https://www.rfc-editor.org/info/rfc9223</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) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-overview" class="xref">Overview</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-protocol-stack-for-route" class="xref">Protocol Stack for ROUTE</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-data-model" class="xref">Data Model</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.4">
                <p id="section-toc.1-1.1.2.4.1"><a href="#section-1.4" class="xref">1.4</a>.  <a href="#name-architecture-and-scope-of-s" class="xref">Architecture and Scope of Specification</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.5">
                <p id="section-toc.1-1.1.2.5.1"><a href="#section-1.5" class="xref">1.5</a>.  <a href="#name-conventions-used-in-this-do" class="xref">Conventions Used in This Document</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-route-packet-format" class="xref">ROUTE Packet Format</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-packet-structure-and-header" class="xref">Packet Structure and Header Fields</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-lct-header-extensions" class="xref">LCT Header Extensions</a></p>
</li>
              <li class="compact toc ulBare 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-fec-payload-id-for-source-f" class="xref">FEC Payload ID for Source Flows</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-fec-payload-id-for-repair-f" class="xref">FEC Payload ID for Repair Flows</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-session-metadata" class="xref">Session Metadata</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-generic-metadata" class="xref">Generic Metadata</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-session-metadata-for-source" class="xref">Session Metadata for Source Flows</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-session-metadata-for-repair" class="xref">Session Metadata for Repair Flows</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-delivery-object-mode" class="xref">Delivery Object Mode</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-file-mode" class="xref">File Mode</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-extensions-to-fdt" class="xref">Extensions to FDT</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-constraints-on-extended-fdt" class="xref">Constraints on Extended FDT</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare 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-entity-mode" class="xref">Entity Mode</a></p>
</li>
              <li class="compact toc ulBare 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-unsigned-package-mode" class="xref">Unsigned Package Mode</a></p>
</li>
              <li class="compact toc ulBare 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-signed-package-mode" class="xref">Signed Package Mode</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-sender-operation" class="xref">Sender Operation</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-usage-of-alc-and-lct-for-so" class="xref">Usage of ALC and LCT for Source Flow</a></p>
</li>
              <li class="compact toc ulBare 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-route-packetization-for-sou" class="xref">ROUTE Packetization for Source Flow</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-basic-route-packetization" class="xref">Basic ROUTE Packetization</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-route-packetization-for-cma" class="xref">ROUTE Packetization for CMAF Chunked Content</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare 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-timing-of-packet-emission" class="xref">Timing of Packet Emission</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-extended-fdt-encoding-for-f" class="xref">Extended FDT Encoding for File Mode Sending</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-fec-framework-consideration" class="xref">FEC Framework Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-fec-transport-object-constr" class="xref">FEC Transport Object Construction</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-super-object-construction" class="xref">Super-Object Construction</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.8">
                <p id="section-toc.1-1.5.2.8.1"><a href="#section-5.8" class="xref">5.8</a>.  <a href="#name-repair-packet-consideration" class="xref">Repair Packet Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.9">
                <p id="section-toc.1-1.5.2.9.1"><a href="#section-5.9" class="xref">5.9</a>.  <a href="#name-summary-fec-information" class="xref">Summary FEC Information</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-receiver-operation" class="xref">Receiver Operation</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-basic-application-object-re" class="xref">Basic Application Object Recovery for Source Flows</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-fast-stream-acquisition" class="xref">Fast Stream Acquisition</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-generating-extended-fdt-ins" class="xref">Generating Extended FDT-Instance for File Mode</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.1">
                    <p id="section-toc.1-1.6.2.3.2.1.1"><a href="#section-6.3.1" class="xref">6.3.1</a>.  <a href="#name-file-template-substitution-" class="xref">File Template Substitution for Content-Location Derivation</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.2">
                    <p id="section-toc.1-1.6.2.3.2.2.1"><a href="#section-6.3.2" class="xref">6.3.2</a>.  <a href="#name-filetransfer-length-derivat" class="xref">File@Transfer-Length Derivation</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3.2.3">
                    <p id="section-toc.1-1.6.2.3.2.3.1"><a href="#section-6.3.3" class="xref">6.3.3</a>.  <a href="#name-fdt-instanceexpires-derivat" class="xref">FDT-Instance@Expires Derivation</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-fec-application" class="xref">FEC Application</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-general-fec-application-gui" class="xref">General FEC Application Guidelines</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-toi-mapping" class="xref">TOI Mapping</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-delivery-object-reception-t" class="xref">Delivery Object Reception Timeout</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-example-fec-operation" class="xref">Example FEC Operation</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare 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-considerations-for-defining" class="xref">Considerations for Defining ROUTE Profiles</a></p>
</li>
          <li class="compact toc ulBare 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-route-concepts" class="xref">ROUTE Concepts</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare 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-route-modes-of-delivery" class="xref">ROUTE Modes of Delivery</a></p>
</li>
              <li class="compact toc ulBare 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-file-mode-optimizations" class="xref">File Mode Optimizations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.3">
                <p id="section-toc.1-1.9.2.3.1"><a href="#section-9.3" class="xref">9.3</a>.  <a href="#name-in-band-signaling-of-object" class="xref">In-Band Signaling of Object Transfer Length</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.4">
                <p id="section-toc.1-1.9.2.4.1"><a href="#section-9.4" class="xref">9.4</a>.  <a href="#name-repair-protocol-concepts" class="xref">Repair Protocol Concepts</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-interoperability-chart" class="xref">Interoperability Chart</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-security-and-privacy-consid" class="xref">Security and Privacy Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#section-13" class="xref">13</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.1">
                <p id="section-toc.1-1.13.2.1.1"><a href="#section-13.1" class="xref">13.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13.2.2">
                <p id="section-toc.1-1.13.2.2.1"><a href="#section-13.2" class="xref">13.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-B" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="sect-1">
<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>
<div id="sect-1.1">
<section id="section-1.1">
        <h3 id="name-overview">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
        </h3>
<p id="section-1.1-1">
   The Real-time Transport Object delivery over Unidirectional Transport
   (ROUTE) protocol can be used for robust delivery of
   Application Objects, including Application Objects with real-time
   delivery constraints, to receivers over a unidirectional transport.
   Unidirectional transport in this document has identical meaning to that in
   RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>, i.e., transport in the direction of receiver(s)
   from a sender. The robustness is enabled by a built-in mechanism, e.g.,
   signaling for loss detection, enabling loss recovery, and optionally
   integrating application-layer Forward Error Correction (FEC).<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
   Application Objects consist of data that has meaning to applications
   that use the ROUTE protocol for delivery of data to receivers, e.g.,
   an Application Object can be a file, an MPEG Dynamic Adaptive
   Streaming over HTTP (DASH) <span>[<a href="#DASH" class="xref">DASH</a>]</span> video segment, a WAV audio clip, an
   MPEG Common Media Application Format (CMAF) <span>[<a href="#CMAF" class="xref">CMAF</a>]</span> addressable
   resource, an MPEG-4 video clip, etc.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
   The ROUTE protocol is designed to enable delivery of sequences of
   related Application Objects in a timely manner to receivers, e.g., a
   sequence of DASH video segments associated to a Representation or a
   sequence of CMAF addressable resources associated to a CMAF Track.
   The applications of this protocol target services enabled on media
   consumption devices such as smartphones, tablets, television sets, and
   so on. Most of these applications are real-time in the sense that
   they are sensitive to and rely upon such timely reception of data.
   The ROUTE protocol also supports chunked delivery of real-time
   Application Objects to enable low-latency streaming applications
   (similar in its properties to chunked delivery using HTTP). The
   protocol also enables low-latency delivery of DASH and Apple HTTP
   Live Streaming (HLS) content with CMAF Chunks.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">
   Content not intended for rendering in real time as it is received
   (e.g., a downloaded application), a file comprising continuous or
   discrete media and belonging to an app-based feature, or a file
   containing (opaque) data to be consumed by a Digital Rights
   Management (DRM) system client can also be delivered by ROUTE.<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<p id="section-1.1-5">
   The ROUTE protocol supports a caching model where Application
   Objects are recovered into a cache at the receiver and may be made
   available to applications via standard HTTP requests from the cache.
   Many current day applications rely on using HTTP to access content;
   hence, this approach enables such applications in
   broadcast/multicast environments.<a href="#section-1.1-5" class="pilcrow">¶</a></p>
<p id="section-1.1-6">
   ROUTE is aligned with File Delivery over Unidirectional Transport (FLUTE)
   as defined in RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span> as well as
   the extensions defined in Multimedia Broadcast/Multicast Service (MBMS)
   <span>[<a href="#MBMS" class="xref">MBMS</a>]</span>, but it also makes use of some principles of
   FCAST (Object Delivery for the Asynchronous Layered Coding (ALC) and
   NACK-Oriented Reliable Multicast (NORM) Protocols) as defined in RFC 6968 <span>[<a href="#RFC6968" class="xref">RFC6968</a>]</span>; for example, object metadata and the
   object content may be sent together in a compound object.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<p id="section-1.1-7">
   The alignment to FLUTE is enabled since in addition to reusing
   several of the basic FLUTE protocol features, as referred to by this
   document, certain optimizations and restrictions are added that
   enable optimized support for real-time delivery of media data; hence,
   the name of the protocol. Among others, the source ROUTE protocol
   enables or enhances the following functionalities:<a href="#section-1.1-7" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-8.1">Real-time delivery of object-based media data<a href="#section-1.1-8.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-8.2">Flexible packetization, including enabling media-aware
      packetization as well as transport-aware packetization of delivery
      objects<a href="#section-1.1-8.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-8.3">Independence of Application Objects and delivery objects, i.e., a
      delivery object may be a part of a file or may be a group of
      files.<a href="#section-1.1-8.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.1-9">
   Advanced Television Systems Committee (ATSC) 3.0 specifies the ROUTE
   protocol integrated with an ATSC 3.0 services layer. That
   specification will be referred to as ATSC-ROUTE <span>[<a href="#ATSCA331" class="xref">ATSCA331</a>]</span> for the
   remainder of this document. Digital Video Broadcasting  (DVB) has specified a profile of ATSC-ROUTE
   in DVB Adaptive Media Streaming over IP Multicast (DVB-MABR)
   <span>[<a href="#DVBMABR" class="xref">DVBMABR</a>]</span>. This document specifies the Application Object delivery
   aspects (delivery protocol) for such services, as the corresponding
   delivery protocol could be used as a reference by a variety of
   services by specifying profiles of ROUTE in their respective fora,
   e.g., by adding new optional features atop or by restricting various
   optional features specified in this document in a specific service
   standard. Hence, in the context of this document, the aforementioned
   ATSC-ROUTE and DVB-MABR are the services using ROUTE. The definition
   of profiles by the services also have to give due consideration to
   compatibility issues, and some related guidelines are also provided
   in this document.<a href="#section-1.1-9" class="pilcrow">¶</a></p>
<p id="section-1.1-10">
   This document is not an IETF specification and does not have IETF
   consensus. It is provided here to aid the production of interoperable
   implementations.<a href="#section-1.1-10" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-1.2">
<section id="section-1.2">
        <h3 id="name-protocol-stack-for-route">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-protocol-stack-for-route" class="section-name selfRef">Protocol Stack for ROUTE</a>
        </h3>
<p id="section-1.2-1">
   ROUTE delivers Application Objects such as MPEG DASH or HLS segments
   and optionally the associated repair data, operating over UDP/IP
   networks, as depicted in <a href="#protocol-layering" class="xref">Table 1</a>. The session metadata signaling to
   realize a ROUTE session as specified in this document <span class="bcp14">MAY</span> be delivered
   out of band or in band as well. Since ROUTE delivers objects in an
   application cache at the receiver from where the application can
   access them using HTTP, an application like DASH may use its
   standardized unicast streaming mechanisms in conjunction with ROUTE
   over broadcast/multicast to augment the services.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<span id="name-protocol-layering"></span><div id="protocol-layering">
<table class="center" id="table-1">
          <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-protocol-layering" class="selfRef">Protocol Layering</a>
          </caption>
<tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">Application (DASH and HLS segments, CMAF Chunks, etc.)            
                </td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">ROUTE                                                            
                </td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">UDP                                                              
                </td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">IP                                                               
                </td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="sect-1.3">
<section id="section-1.3">
        <h3 id="name-data-model">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-data-model" class="section-name selfRef">Data Model</a>
        </h3>
<p id="section-1.3-1">
   The ROUTE data model is constituted by the following key concepts.<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1.3-2">
          <dt id="section-1.3-2.1">Application Object:</dt>
          <dd style="margin-left: 3.0em" id="section-1.3-2.2"> data that has meaning to the application that
   uses the ROUTE protocol for delivery of data to receivers, e.g., an
   Application Object can be a file, a DASH video segment, a WAV
   audio clip, an MPEG-4 video clip, etc.<a href="#section-1.3-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.3">Delivery Object:</dt>
          <dd style="margin-left: 3.0em" id="section-1.3-2.4"> an object on course of delivery to the application
   from the ROUTE sender to ROUTE receiver.<a href="#section-1.3-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.5">Transport Object:</dt>
          <dd style="margin-left: 3.0em" id="section-1.3-2.6"> an object identified by the Transport Object Identifier (TOI)
          in RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>. It
          <span class="bcp14">MAY</span> be either a source or a repair object, depending on if it is
          carried by a Source Flow or a Repair Flow, respectively.<a href="#section-1.3-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.7">Transport Session:</dt>
          <dd style="margin-left: 3.0em" id="section-1.3-2.8">a Layered Coding Transport (LCT) channel, as
   defined by RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>. A Transport Session <span class="bcp14">SHALL</span> be uniquely
   identified by a unique Transport Session Identifier (TSI) value in
   the LCT header. The TSI is scoped by the IP address of the sender,
   and the IP address of the sender together with the TSI uniquely
   identify the session. Transport Sessions are a subset of a ROUTE
   session. For media delivery, a Transport Session would typically
   carry a media component, for example, a DASH Representation. Within
   each Transport Session, one or more objects are carried, typically
   objects that are related, e.g., DASH segments associated to one
   Representation.<a href="#section-1.3-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.9">ROUTE Session:</dt>
          <dd style="margin-left: 3.0em" id="section-1.3-2.10">an ensemble or multiplex of one or more
   Transport Sessions. Each ROUTE session is associated with an IP
   address/port combination. A ROUTE session typically carries one or more media
   components of streaming media e.g., Representations associated with a DASH
   Media Presentation.<a href="#section-1.3-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.11">Source Flow:</dt>
          <dd style="margin-left: 3.0em" id="section-1.3-2.12">a Transport Session carrying source data. Source Flow is
   independent of the Repair Flow, i.e., the Source Flow <span class="bcp14">MAY</span> be used by
   a ROUTE receiver without the ROUTE Repair Flows.<a href="#section-1.3-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.3-2.13">Repair Flow:</dt>
          <dd style="margin-left: 3.0em" id="section-1.3-2.14">a Transport Session carrying repair data for one
   or more Source Flows.<a href="#section-1.3-2.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-1.4">
<section id="section-1.4">
        <h3 id="name-architecture-and-scope-of-s">
<a href="#section-1.4" class="section-number selfRef">1.4. </a><a href="#name-architecture-and-scope-of-s" class="section-name selfRef">Architecture and Scope of Specification</a>
        </h3>
<p id="section-1.4-1">
   The scope of the ROUTE protocol is to enable robust and real-time transport of
   delivery objects using LCT packets. This architecture is depicted in
   <a href="#architecture-diagram" class="xref">Figure 1</a>.<a href="#section-1.4-1" class="pilcrow">¶</a></p>
<p id="section-1.4-2">
   The normative aspects of the ROUTE protocol focus on the following
   aspects:<a href="#section-1.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.4-3.1">The format of the LCT packets that carry the transport objects.<a href="#section-1.4-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.4-3.2">The robust transport of the delivery object using a repair
      protocol based on Forward Error Correction (FEC).<a href="#section-1.4-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.4-3.3">The definition and possible carriage of object metadata along with
      the delivery objects. Metadata may be conveyed in LCT packets
      and/or separate objects.<a href="#section-1.4-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.4-3.4">The ROUTE session, LCT channel, and delivery object description
      provided as service metadata signaling to enable the reception of
      objects.<a href="#section-1.4-3.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.4-3.5">The normative aspects (formats, semantics) of the delivery
          objects conveyed as a content manifest to be delivered along with
          the objects to optimize the performance for specific applications
          e.g., real-time delivery. The objects and manifest are made
          available to the application through an Application Object cache.
          The interface of this cache to the application is not specified in
          this document; however, it will typically be enabled by the
          application acting as an HTTP client and the cache as the HTTP
          server.<a href="#section-1.4-3.5" class="pilcrow">¶</a>
</li>
        </ul>
<span id="name-architecture-functional-blo"></span><div id="architecture-diagram">
<figure id="figure-1">
          <div class="alignLeft art-text artwork" id="section-1.4-4.1">
<pre>
                                             Application Objects
Application                                  to application
Objects from                                          ^
an application    +--------------------------------------------+
     +            |  ROUTE Receiver                   |        |
     |            |                            +------+------+ |
     |            |                            | Application | |
     |            |                            | Object Cache| |
     |            |                            +------+------+ |
     |    LCT over|    +---------------+              ^        |
     v    UDP/IP  |    | Source object |  +---------+ |        |
+----+---+        | +-&gt;+ recovery      +--+  Repair +-+        |
| ROUTE  |        | |  +---------------+  +----+----+          |
| Sender +----------+                          ^               |
+----+---+        | |                          |               |
     |            | |  +---------------+       |               |
     |            | |  | Repair object |       |               |
     |            | +-&gt;+ recovery      +-------+               |
     +-----------&gt;+    +---------------+                       |
       ROUTE      |                                            |
       Metadata   +--------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-architecture-functional-blo" class="selfRef">Architecture/Functional Block Diagram</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sect-1.6">
<section id="section-1.5">
        <h3 id="name-conventions-used-in-this-do">
<a href="#section-1.5" class="section-number selfRef">1.5. </a><a href="#name-conventions-used-in-this-do" class="section-name selfRef">Conventions Used in This Document</a>
        </h3>
<p id="section-1.5-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-1.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-route-packet-format">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-route-packet-format" class="section-name selfRef">ROUTE Packet Format</a>
      </h2>
<div id="sect-2.1">
<section id="section-2.1">
        <h3 id="name-packet-structure-and-header">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-packet-structure-and-header" class="section-name selfRef">Packet Structure and Header Fields</a>
        </h3>
<p id="section-2.1-1">
   The packet format used by ROUTE Source Flows and Repair Flows follows
   the ALC packet format specified in RFC 5775 <span>[<a href="#RFC5775" class="xref">RFC5775</a>]</span> with the UDP
   header followed by the default LCT header and the source FEC Payload
   ID followed by the packet payload. The overall ROUTE packet format is
   as depicted in <a href="#route-packet-format" class="xref">Figure 2</a>.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<span id="name-overall-route-packet-format"></span><div id="route-packet-format">
<figure id="figure-2">
          <div class="alignLeft art-text artwork" id="section-2.1-2.1">
<pre>
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           UDP Header                          |
|                                                               |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                       Default LCT header                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         FEC Payload ID                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Payload Data                         |
|                               ...                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-overall-route-packet-format" class="selfRef">Overall ROUTE Packet Format</a>
          </figcaption></figure>
</div>
<p id="section-2.1-3">
   The Default LCT header is as defined in the LCT building block in RFC
   5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">
   The LCT packet header fields <span class="bcp14">SHALL</span> be used as defined by the LCT
   building block in RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>. The semantics and usage of the
   following LCT header fields <span class="bcp14">SHALL</span> be further constrained in ROUTE as
   follows:<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-2.1-5">
          <dt id="section-2.1-5.1">Version number (V):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-5.2"> This 4-bit field indicates the protocol
   version number. The version number <span class="bcp14">SHALL</span> be set to '0001', as specified in
   RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>.<a href="#section-2.1-5.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-5.3">Congestion Control flag (C) field:</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-5.4"> This 2-bit field, as
   defined in RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>, <span class="bcp14">SHALL</span> be set to '00'.<a href="#section-2.1-5.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-5.5">Protocol-Specific Indication (PSI):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-5.6"> The most significant bit of this 2-bit flag is called the
          Source Packet Indicator (SPI) and indicates whether the current
          packet is a source packet or a FEC repair packet. The SPI
          <span class="bcp14">SHALL</span> be set to '1' to indicate a source packet and
          <span class="bcp14">SHALL</span> bet set to '0' to indicate a repair
          packet.<a href="#section-2.1-5.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-5.7">Transport Session Identifier flag (S):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-5.8"> This 1-bit field
   <span class="bcp14">SHALL</span> be set to '1' to indicate a 32-bit word in the TSI field.<a href="#section-2.1-5.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-5.9">Transport Object Identifier flag (O):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-5.10"> This 2-bit field <span class="bcp14">SHALL</span>
   be set to '01' to indicate the number of full 32-bit words in the TOI
   field.<a href="#section-2.1-5.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-5.11">Half-word flag (H):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-5.12"> This 1-bit field <span class="bcp14">SHALL</span> be set to '0' to
   indicate that no half-word field sizes are used.<a href="#section-2.1-5.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-5.13">Codepoint (CP):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-5.14"> This 8-bit field is used to indicate the type of the payload
          that is carried by this packet; for ROUTE, it is defined as shown
          below to indicate the type of delivery object carried in the payload
          of the associated ROUTE packet. The remaining unmapped Codepoint
          values can be used by a service using ROUTE. In this case, the
          Codepoint values <span class="bcp14">SHALL</span> follow the semantics specified
          in the following table. "IS" stands for Initialization Segment of
          the media content such as the DASH Initialization Segment
           <span>[<a href="#DASH" class="xref">DASH</a>]</span>. The various modes of operation in the table
          (File/Entity/Package Mode) are specified in <a href="#sect-4" class="xref">Section 4</a>. The table also lists a Codepoint value range
          that is reserved for future service-specific uses.<a href="#section-2.1-5.14" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<span id="name-codepoint-values"></span><div id="codepoint-values">
<table class="center" id="table-2">
          <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-codepoint-values" class="selfRef">Codepoint Values</a>
          </caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Codepoint value
       </th>
              <th class="text-left" rowspan="1" colspan="1">Semantics
       </th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">0
     </td>
              <td class="text-left" rowspan="1" colspan="1">Reserved (not used)
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">1
     </td>
              <td class="text-left" rowspan="1" colspan="1">Non Real Time (NRT) - File Mode
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">2
     </td>
              <td class="text-left" rowspan="1" colspan="1">NRT - Entity Mode
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">3
     </td>
              <td class="text-left" rowspan="1" colspan="1">NRT - Unsigned Package Mode
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">4
     </td>
              <td class="text-left" rowspan="1" colspan="1">NRT - Signed Package Mode
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">5
     </td>
              <td class="text-left" rowspan="1" colspan="1">New IS, timeline changed
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">6
     </td>
              <td class="text-left" rowspan="1" colspan="1">New IS, timeline continued
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">7
     </td>
              <td class="text-left" rowspan="1" colspan="1">Redundant IS
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">8
     </td>
              <td class="text-left" rowspan="1" colspan="1">Media Segment, File Mode
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">9
     </td>
              <td class="text-left" rowspan="1" colspan="1">Media Segment, Entity Mode
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">10
     </td>
              <td class="text-left" rowspan="1" colspan="1">Media Segment, File Mode with CMAF Random Access chunk
</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">11 - 255
     </td>
              <td class="text-left" rowspan="1" colspan="1">Reserved, service-specific
</td>
            </tr>
          </tbody>
        </table>
</div>
<span class="break"></span><dl class="dlParallel" id="section-2.1-7">
          <dt id="section-2.1-7.1">Congestion Control Information (CCI):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-7.2"> For packets carrying DASH segments, CCI <span class="bcp14">MAY</span> convey
          the 32-bit earliest presentation time <span>[<a href="#DASH" class="xref">DASH</a>]</span> of the
          DASH segment contained in the ROUTE packet. In this case, this
          information can be used by a ROUTE receiver for fast stream
          acquisition (details in <a href="#sect-6.2" class="xref">Section 6.2</a>). Otherwise, this field <span class="bcp14">SHALL</span> be
          set to 0.<a href="#section-2.1-7.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-7.3">Transport Session Identifier (TSI):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-7.4"> This 32-bit field
   identifies the Transport Session in ROUTE. The context of the Transport
   Session is provided by signaling metadata. The value TSI = 0 <span class="bcp14">SHALL</span> only be
   used for service-specific signaling.<a href="#section-2.1-7.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.1-7.5">Transport Object Identifier (TOI):</dt>
          <dd style="margin-left: 1.5em" id="section-2.1-7.6"> This 32-bit field <span class="bcp14">SHALL</span>
   identify the object within this session to which the payload of the current
   packet belongs. The mapping of the TOI field to the object is provided by
   the Extended File Delivery Table (FDT).<a href="#section-2.1-7.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-2.2">
<section id="section-2.2">
        <h3 id="name-lct-header-extensions">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-lct-header-extensions" class="section-name selfRef">LCT Header Extensions</a>
        </h3>
<p id="section-2.2-1">
   The following LCT header extensions are defined or used by ROUTE:<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">EXT_FTI:</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.2"> as specified in RFC 5775.<a href="#section-2.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.3">EXT_TOL:</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.4"> the length in bytes of the multicast transport object shall be
          signaled using EXT_TOL as specified by ATSC-ROUTE <span>[<a href="#ATSCA331" class="xref">ATSCA331</a>]</span> with 24 bits or, if required, 48 bits of
          Transfer Length. The frequency of using the EXT_TOL header extension
          is determined by channel conditions that may cause the loss of the
          packet carrying the Close Object flag (B) <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>.<a href="#section-2.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.5"></dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.6">
   NOTE: The transport object length can also be determined without the use of
   EXT_TOL by examining the LCT packet with the Close Object flag
   (B). However, if this packet is lost, then the EXT_TOL information can be
   used by the receiver to determine the transport object length.<a href="#section-2.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-2.2-2.7">EXT_TIME Header:</dt>
          <dd style="margin-left: 1.5em" id="section-2.2-2.8"> as specified in RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>. The Sender Current Time <span class="bcp14">SHALL</span> be signaled using
   EXT_TIME.<a href="#section-2.2-2.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-2.3">
<section id="section-2.3">
        <h3 id="name-fec-payload-id-for-source-f">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-fec-payload-id-for-source-f" class="section-name selfRef">FEC Payload ID for Source Flows</a>
        </h3>
<p id="section-2.3-1">
   The syntax of the FEC Payload ID for the Compact No-Code FEC Scheme used in
   ROUTE Source Flows is a 32-bit unsigned integer value that
   <span class="bcp14">SHALL</span> express the start_offset as an octet number
   corresponding to the first octet of the fragment of the delivery object
   carried in this packet. The start_offset value for the first fragment of
   any delivery object <span class="bcp14">SHALL</span> be set to 0. <a href="#start_offset" class="xref">Figure 3</a> shows the 32-bit start_offset field.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<span id="name-fec-payload-id-for-source-fl"></span><div id="start_offset">
<figure id="figure-3">
          <div class="alignLeft art-text artwork" id="section-2.3-2.1">
<pre>
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                         start_offset                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-fec-payload-id-for-source-fl" class="selfRef">FEC Payload ID for Source Flows</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sect-2.4">
<section id="section-2.4">
        <h3 id="name-fec-payload-id-for-repair-f">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-fec-payload-id-for-repair-f" class="section-name selfRef">FEC Payload ID for Repair Flows</a>
        </h3>
<p id="section-2.4-1">
   FEC Payload ID for Repair Flows is specified in RFC 6330 <span>[<a href="#RFC6330" class="xref">RFC6330</a>]</span>.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-session-metadata">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-session-metadata" class="section-name selfRef">Session Metadata</a>
      </h2>
<p id="section-3-1">
   The required session metadata for Source and Repair Flows is
   specified in the following sections. The list specified here is not
   exhaustive; a service <span class="bcp14">MAY</span> signal more metadata to meet its needs. The
   data format is also not specified beyond its cardinality; the exact
   format of specifying the data is left for the service, e.g., by using
   XML encoding format, as has been done by <span>[<a href="#DVBMABR" class="xref">DVBMABR</a>]</span> and <span>[<a href="#ATSCA331" class="xref">ATSCA331</a>]</span>.
   It is specified in the following if an attribute is mandatory (m),
   conditional mandatory (cm) or optional (o) to realize a basic ROUTE
   session. A mandatory field <span class="bcp14">SHALL</span> always be present in the session
   metadata, and a conditional mandatory field <span class="bcp14">SHALL</span> be present if the
   specified condition is true. The delivery of the session metadata to
   the ROUTE receiver is beyond the scope of this document.<a href="#section-3-1" class="pilcrow">¶</a></p>
<div id="sect-3.1">
<section id="section-3.1">
        <h3 id="name-generic-metadata">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-generic-metadata" class="section-name selfRef">Generic Metadata</a>
        </h3>
<p id="section-3.1-1">
   Generic metadata is applicable to both Source and Repair Flows as
   follows. Before a receiver can join a ROUTE session, the receiver
   needs to obtain this generic metadata that contains at least the
   following information:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.1-2">
          <dt id="section-3.1-2.1">ROUTE version number (m):</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.2"> the version number of ROUTE used
   in this session. The version number conforming to this document <span class="bcp14">SHALL</span> be
   1.<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.3">Connection ID (m):</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.4"> the unique identifier of a Connection,
   usually consisting of the following 4-tuple: source IP address/source port number,
   destination IP address/destination port number. The IP addresses can be
   IPv4 or IPv6 addresses depending upon which IP version is used by the
   deployment.<a href="#section-3.1-2.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-3.2">
<section id="section-3.2">
        <h3 id="name-session-metadata-for-source">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-session-metadata-for-source" class="section-name selfRef">Session Metadata for Source Flows</a>
        </h3>
<p id="section-3.2-1">
   stsi (m): The LCT TSI value corresponding to the Transport Session for
   the Source Flow.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.2-2">
          <dt id="section-3.2-2.1">rt (o):</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.2"> A Boolean flag that <span class="bcp14">SHALL</span> indicate whether the
   content component carried by this Source Flow corresponds to real-time
   streaming media or non-real-time content. When set to "true", it <span class="bcp14">SHALL</span> be
   an indication of real-time content, and when absent or set to "false", it
   <span class="bcp14">SHALL</span> be an indication of non-real-time (NRT) content.<a href="#section-3.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.3">minBufferSize (o):</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.4"> A 32-bit unsigned integer that <span class="bcp14">SHALL</span>
   represent, in kilobytes, the minimum required storage size of the receiver
   transport buffer for the parent LCT channel of this Source Flow. The
   buffer holds the data belonging to a source object until its complete
   reception. This attribute is only applicable when rt = "true".<a href="#section-3.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.5"></dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.6">A service that chooses not to signal this attribute relies on
   the receiver implementation, which must discard the received data beyond
   its buffering capability. Such discarding of data will impact the
   service quality.<a href="#section-3.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.7">EFDT (cm):</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.8"> When present, <span class="bcp14">SHALL</span> contain a single instance of
   an FDT-Instance element per RFC 6726 FLUTE <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>, which
   <span class="bcp14">MAY</span> contain the optional FDT extensions as defined in <a href="#sect-4.1" class="xref">Section 4.1</a>. The optional EFDT element <span class="bcp14">MAY</span> only be present for File
   Mode of delivery. In File Mode, it <span class="bcp14">SHALL</span> be present if this Source Flow
   transports streaming media segments.<a href="#section-3.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.9">contentType (o):</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.10"> A string that <span class="bcp14">SHALL</span> represent the media
   type for the media content. It <span class="bcp14">SHALL</span> obey the semantics of the Content-Type
   header as specified by the HTTP/1.1 protocol in RFC 7231 <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>. This document does not define any new contentType
   strings. In its absence, the signaling of media type for the media content
   is beyond the scope of this document.<a href="#section-3.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.11">applicationMapping (m):</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.12"> A set of identifiers that provide an application-specific
          mapping of the received Application Objects to the Source Flows. For
          example, for DASH, this would provide the mapping of a Source Flow
          to a specific DASH Representation from a Media Presentation
          Description (MPD), the latter identified by its Representation and
          corresponding Adaptation Set and Period IDs.<a href="#section-3.2-2.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sect-3.3">
<section id="section-3.3">
        <h3 id="name-session-metadata-for-repair">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-session-metadata-for-repair" class="section-name selfRef">Session Metadata for Repair Flows</a>
        </h3>
<span class="break"></span><dl class="dlParallel" id="section-3.3-1">
          <dt id="section-3.3-1.1">minBuffSize (o):
          </dt>
          <dd style="margin-left: 1.5em" id="section-3.3-1.2">
            <p id="section-3.3-1.2.1">
     A 32-bit unsigned integer whose value <span class="bcp14">SHALL</span>
   represent a required size of the receiver transport buffer for
   AL‑FEC decoding processing. When present, this attribute
   <span class="bcp14">SHALL</span> indicate the minimum buffer size that is
   required to handle all associated objects that are assigned to a
   super-object, i.e., a delivery object formed by the concatenation of
   multiple FEC transport objects in order to bundle these FEC
   transport objects for AL-FEC protection.<a href="#section-3.3-1.2.1" class="pilcrow">¶</a></p>
<p id="section-3.3-1.2.2">                                                                                      
   A service that chooses not to signal this attribute relies on the receiver
   implementation, which must discard the received repair data beyond its
   buffering capability. Such discarding of data will impact the service
    quality.<a href="#section-3.3-1.2.2" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.3-1.3">fecOTI (m): 
          </dt>
          <dd style="margin-left: 1.5em" id="section-3.3-1.4">A parameter consisting of the concatenation of Common and
   Scheme-Specific FEC Object Transmission Information (FEC OTI) as
   defined in Sections <a href="https://www.rfc-editor.org/rfc/rfc6330#section-3.3.2" class="relref">3.3.2</a> and <a href="https://www.rfc-editor.org/rfc/rfc6330#section-3.3.3" class="relref">3.3.3</a> of <span>[<a href="#RFC6330" class="xref">RFC6330</a>]</span> and
   that corresponds to the delivery objects carried in the Source Flow
   to which this Repair Flow is associated, with the following
   qualification: the 40-bit Transfer Length (F) field may either
   represent the actual size of the object, or it is encoded as all
   zeroes. In the latter case, the FEC transport object size either is
   unknown or cannot be represented by this attribute.  In other words,
   for the all-zeroes format, the delivery objects in the Source Flow
   correspond to streaming content, either a live Service whereby
   content encoding has not yet occurred at the time this session data
   was generated or pre-recorded streaming content whose delivery
   object sizes, albeit known at the time of session data generation,
   are variable and cannot be represented as a single value by the
   fecOTI attribute.<a href="#section-3.3-1.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.3-1.5">ptsi (m):
          </dt>
          <dd style="margin-left: 1.5em" id="section-3.3-1.6">TSI value(s) of each Source Flow protected by this Repair Flow.<a href="#section-3.3-1.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.3-1.7">mappingTOIx (o):
          </dt>
          <dd style="margin-left: 1.5em" id="section-3.3-1.8">Values of the constant X for use in deriving the TOI of the
   delivery object of each protected Source Flow from the TOI of the
   FEC (super-)object. The default value is "1". Multiple mappingTOIx
   values <span class="bcp14">MAY</span> be provided for each protected Source
   Flow depending upon the usage of FEC (super-)object.<a href="#section-3.3-1.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.3-1.9">mappingTOIy (o):
          </dt>
          <dd style="margin-left: 1.5em" id="section-3.3-1.10">The corresponding constant Y to each mappingTOIx, when present,
   for use in deriving the parent SourceTOI value from the above
   equation. The default value is "0".<a href="#section-3.3-1.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-delivery-object-mode">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-delivery-object-mode" class="section-name selfRef">Delivery Object Mode</a>
      </h2>
<p id="section-4-1">
   ROUTE provides several different delivery object modes, and one of
   these modes may suit the application needs better for a given
   Transport Session. A delivery object is self contained for the
   application, typically associated with certain properties, metadata,
   and timing-related information relevant to the
   application. The signaling of the delivery object mode is done on an
   object basis using Codepoint as specified in <a href="#sect-2.1" class="xref">Section 2.1</a>.<a href="#section-4-1" class="pilcrow">¶</a></p>
<div id="sect-4.1">
<section id="section-4.1">
        <h3 id="name-file-mode">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-file-mode" class="section-name selfRef">File Mode</a>
        </h3>
<p id="section-4.1-1">
   File Mode uses an out-of-band Extended FDT (EFDT) signaling for
   recovery of delivery objects with the following extensions and
   considerations.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<div id="sect-4.1.1">
<section id="section-4.1.1">
          <h4 id="name-extensions-to-fdt">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-extensions-to-fdt" class="section-name selfRef">Extensions to FDT</a>
          </h4>
<p id="section-4.1.1-1">
   The following extensions are specified to FDT, as specified in RFC 6726
   <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>. An Extended FDT-Instance is an
   instance of FLUTE FDT, as specified in <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>, plus optionally one or more of the following
   extensions:<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1.1-2">
            <dt id="section-4.1.1-2.1">efdtVersion:</dt>
            <dd style="margin-left: 1.5em" id="section-4.1.1-2.2"> A value that <span class="bcp14">SHALL</span> represent the version of
   this Extended FDT-Instance.<a href="#section-4.1.1-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.1.1-2.3">maxExpiresDelta:</dt>
            <dd style="margin-left: 1.5em" id="section-4.1.1-2.4">Let "tp" represent the wall clock time at
   the receiver when the receiver acquires the first ROUTE packet carrying
   data of the object described by this Extended FDT-Instance.
   maxExpiresDelta, when present, <span class="bcp14">SHALL</span> represent a time interval that when
   added to "tp" <span class="bcp14">SHALL</span> represent the expiration time of the associated
   Extended FDT-Instance "te". The time interval is expressed in number of
   seconds. When maxExpiresDelta is not present, the expiration time of the
   Extended FDT-Instance <span class="bcp14">SHALL</span> be given by the sum of a) the value of the ERT
   field in the EXT_TIME LCT header extension in the first ROUTE packet
   carrying data of that file, and b) the current receiver time when parsing
   the packet header of that ROUTE packet. See Sections <a href="#sect-5.4" class="xref">5.4</a> and <a href="#sect-6.3.3" class="xref">6.3.3</a> on
   additional rules for deriving the Extended FDT-Instance expiration
   time. Hence, <code>te = tp + maxExpiresDelta</code><a href="#section-4.1.1-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.1.1-2.5">maxTransportSize:</dt>
            <dd style="margin-left: 1.5em" id="section-4.1.1-2.6"> An attribute that <span class="bcp14">SHALL</span> represent the
   maximum transport size in bytes of any delivery object described by this
   Extended FDT-Instance. This attribute <span class="bcp14">SHALL</span> be present if a) the
   fileTemplate is present in Extended FDT-Instance, or b) one or more File
   elements, if present in this Extended FDT-Instance, do not include the
   Transfer-Length attribute. When maxTransportSize is not present, the
   maximum transport size is not signaled, while other signaling such as the
   Transfer-Length attribute signal the exact Transfer Length of the
   object.<a href="#section-4.1.1-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.1.1-2.7">fileTemplate:</dt>
            <dd style="margin-left: 1.5em" id="section-4.1.1-2.8">A string value, which when present and in
   conjunction with parameter substitution, is used in deriving the
   Content-Location attribute for the delivery object described by this
   Extended FDT-Instance. It <span class="bcp14">SHALL</span> include the "$TOI$" identifier. Each
   identifier <span class="bcp14">MAY</span> be suffixed as needed by specific file names within the
   enclosing '$' characters following this prototype: <code>%0[width]d</code><a href="#section-4.1.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
<p id="section-4.1.1-3">
   The width parameter is an unsigned integer that provides the minimum
   number of characters to be printed. If the value to be printed is
   shorter than this number, the result <span class="bcp14">SHALL</span> be padded with leading
   zeroes. The value is not truncated even if the result is larger. When
   no format tag is present, a default format tag with width=1 <span class="bcp14">SHALL</span> be
   used.<a href="#section-4.1.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1.1-4">
   Strings other than identifiers <span class="bcp14">SHALL</span> only contain characters that are
   permitted within URIs according to RFC 3986 <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>.<a href="#section-4.1.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1.1-5">
   <code>$$</code> is an escape sequence in fileTemplate value, i.e., "$$" is
   non-recursively replaced with a single "$".<a href="#section-4.1.1-5" class="pilcrow">¶</a></p>
<p id="section-4.1.1-6">
   The usage of fileTemplate is described in Sender and Receiver
   operations in Sections <a href="#sect-5.4" class="xref">5.4</a> and <a href="#sect-6.3" class="xref">6.3</a>, respectively.<a href="#section-4.1.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-4.1.2">
<section id="section-4.1.2">
          <h4 id="name-constraints-on-extended-fdt">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-constraints-on-extended-fdt" class="section-name selfRef">Constraints on Extended FDT</a>
          </h4>
<p id="section-4.1.2-1">
   The Extended FDT-Instance <span class="bcp14">SHALL</span> conform to an FDT-Instance according
   to RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span> with the following constraints: at least one
   File element and the @Expires attribute <span class="bcp14">SHALL</span> be present.<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
<p id="section-4.1.2-2">
   Content encoding <span class="bcp14">MAY</span> be used for delivery of any file described by an
   FDT-Instance.File element in the Extended FDT-Instance. The content
   encoding defined in the present document is gzip <span>[<a href="#RFC1952" class="xref">RFC1952</a>]</span>. When content
   encoding is used, the File@Content-Encoding and File@Content-Length
   attributes <span class="bcp14">SHALL</span> be present in the Extended FDT-Instance.<a href="#section-4.1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-4.2">
<section id="section-4.2">
        <h3 id="name-entity-mode">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-entity-mode" class="section-name selfRef">Entity Mode</a>
        </h3>
<p id="section-4.2-1">
   For Entity Mode, the following applies:<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-2.1">Delivery object metadata <span class="bcp14">SHALL</span> be expressed in
          the form of entity headers as defined in HTTP/1.1, which correspond
          to one or more of the representation header fields, payload header
          fields, and response header fields as defined in Sections <a href="https://www.rfc-editor.org/rfc/rfc7231#section-3.1" class="relref">3.1</a>, <a href="https://www.rfc-editor.org/rfc/rfc7231#section-3.3" class="relref">3.3</a>, and <a href="https://www.rfc-editor.org/rfc/rfc7231#section-7" class="relref">7</a>, respectively, of
          <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>.<a href="#section-4.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.2">The entity headers sent along with the delivery object provide all
      information about that multicast transport object.<a href="#section-4.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.2-2.3">
            <p id="section-4.2-2.3.1">Sending a media object (if the object is chunked) in Entity Mode
      may result in one of the following options:<a href="#section-4.2-2.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2-2.3.2.1">
                <p id="section-4.2-2.3.2.1.1">If the length of the chunked object is known at the sender, the
        ROUTE Entity Mode delivery object <span class="bcp14">MAY</span> be sent without using
        HTTP/1.1 chunked transfer coding, i.e., the object starts with
        an HTTP header containing the Content Length field followed
        by the concatenation of CMAF Chunks:<a href="#section-4.2-2.3.2.1.1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-4.2-2.3.2.1.2">
<pre>
|HTTP Header+Length||---chunk ----||---chunk ----||---chunk --
--||---chunk ----|
</pre><a href="#section-4.2-2.3.2.1.2" class="pilcrow">¶</a>
</div>
</li>
              <li class="normal" id="section-4.2-2.3.2.2">
                <p id="section-4.2-2.3.2.2.1">If the length of the chunked object is unknown at the sender when
        starting to send the object, HTTP/1.1 chunked transfer coding
        format <span class="bcp14">SHALL</span> be used:<a href="#section-4.2-2.3.2.2.1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-4.2-2.3.2.2.2">
<pre>
|HTTP Header||Separator+Length||---chunk ----
||Separator+Length||---chunk ----||Separator+Length||---chunk
----||Separator+Length||---chunk ----||Separator+Length=0|
</pre><a href="#section-4.2-2.3.2.2.2" class="pilcrow">¶</a>
</div>
<p id="section-4.2-2.3.2.2.3">Note, however, that it is not required to send a CMAF Chunk in
        exactly one HTTP chunk.<a href="#section-4.2-2.3.2.2.3" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
        </ul>
</section>
</div>
<div id="sect-4.3">
<section id="section-4.3">
        <h3 id="name-unsigned-package-mode">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-unsigned-package-mode" class="section-name selfRef">Unsigned Package Mode</a>
        </h3>
<p id="section-4.3-1">
   In this delivery mode, the delivery object consists of a group of
   files that are packaged for delivery only. If applied, the client is
   expected to unpack the package and provide each file as an
   independent object to the application. Packaging is supported by
   Multipart Multipurpose Internet Mail Extensions (MIME) <span>[<a href="#RFC2557" class="xref">RFC2557</a>]</span>,
   where objects are packaged into one document for transport, with
   Content-Type set to multipart/related. When binary files are
   included in the package, Content-Transfer-Encoding of "binary"
   should be used for those files.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-4.4">
<section id="section-4.4">
        <h3 id="name-signed-package-mode">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-signed-package-mode" class="section-name selfRef">Signed Package Mode</a>
        </h3>
<p id="section-4.4-1">
   In Signed Package Mode delivery, the delivery object consists of a
   group of files that are packaged for delivery, and the package
   includes one or more signatures for validation. Signed packaging is
   supported by RFC 8551 Secure MIME (S/MIME) <span>[<a href="#RFC8551" class="xref">RFC8551</a>]</span>, where objects
   are packaged into one document for transport and the package includes
   objects necessary for validation of the package.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-sender-operation">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-sender-operation" class="section-name selfRef">Sender Operation</a>
      </h2>
<div id="sect-5.1">
<section id="section-5.1">
        <h3 id="name-usage-of-alc-and-lct-for-so">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-usage-of-alc-and-lct-for-so" class="section-name selfRef">Usage of ALC and LCT for Source Flow</a>
        </h3>
<p id="section-5.1-1">
   ROUTE Source Flow carries the source data as specified in RFC 5775
   <span>[<a href="#RFC5775" class="xref">RFC5775</a>]</span>. There are several special considerations that ROUTE
   introduces to the usage of the LCT building block as outlined in the
   following:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-2.1">ROUTE limits the usage of the LCT building block to a single
     channel per session. Congestion control is thus sender driven in
     ROUTE. It also signifies that there is no specific congestion-control-related signaling from the sender to the receiver; the CCI
     field is either set to 0 or used for other purposes as specified
     in <a href="#sect-2.1" class="xref">Section 2.1</a>. The functionality of receiver-driven layered
     multicast may still be offered by the application, allowing the
     receiver application to select the appropriate delivery session
     based on the bandwidth requirement of that session.<a href="#section-5.1-2.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-3">
   Further, the following details apply to LCT:<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-4.1">
            <p id="section-5.1-4.1.1">The Layered Coding Transport (LCT) Building Block as defined in
     RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span> is used with the following constraints:<a href="#section-5.1-4.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-4.1.2.1">The TSI in the LCT header <span class="bcp14">SHALL</span> be set equal to the value of
        the stsi attribute in <a href="#sect-3.2" class="xref">Section 3.2</a>.<a href="#section-5.1-4.1.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.1-4.1.2.2">The Codepoint (CP) in the LCT header <span class="bcp14">SHALL</span> be used to signal
        the applied formatting as defined in the signaling metadata.<a href="#section-5.1-4.1.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.1-4.1.2.3">
                <p id="section-5.1-4.1.2.3.1">In accordance with ALC, a source FEC Payload ID header is used to
        identify, for FEC purposes, the encoding symbols of the
        delivery object, or a portion thereof, carried by the
        associated ROUTE packet. This information may be sent in
        several ways:<a href="#section-5.1-4.1.2.3.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-4.1.2.3.2.1">
                    <p id="section-5.1-4.1.2.3.2.1.1">As a simple new null FEC scheme with the following usage:<a href="#section-5.1-4.1.2.3.2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-4.1.2.3.2.1.2.1">The value of the source FEC Payload ID header <span class="bcp14">SHALL</span> be set to
   0 in case the ROUTE packet contains the entire delivery object, or<a href="#section-5.1-4.1.2.3.2.1.2.1" class="pilcrow">¶</a>
</li>
                      <li class="normal" id="section-5.1-4.1.2.3.2.1.2.2">The value of the source FEC Payload ID header <span class="bcp14">SHALL</span> be set as a
   direct address (start offset) corresponding to the starting byte
   position of the portion of the object carried in this packet using a
   32-bit field.<a href="#section-5.1-4.1.2.3.2.1.2.2" class="pilcrow">¶</a>
</li>
                    </ul>
</li>
                  <li class="normal" id="section-5.1-4.1.2.3.2.2">In a compatible manner to RFC 6330 <span>[<a href="#RFC6330" class="xref">RFC6330</a>]</span> where the SBN and ESI
 defines the start offset together with the symbol size T.<a href="#section-5.1-4.1.2.3.2.2" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-5.1-4.1.2.3.2.3">The signaling metadata provides the appropriate parameters to
 indicate any of the above modes using the srcFecPayloadId attribute.<a href="#section-5.1-4.1.2.3.2.3" class="pilcrow">¶</a>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="normal" id="section-5.1-4.2">
            <p id="section-5.1-4.2.1">The LCT Header EXT_TIME extension as defined in RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>
              <span class="bcp14">MAY</span> be used by the sender in the following manner:<a href="#section-5.1-4.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-4.2.2.1">The Sender Current Time (SCT), depending on the application,
        <span class="bcp14">MAY</span> be used to occasionally or frequently signal the sender
        current time possibly for reliever time synchronization.<a href="#section-5.1-4.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.1-4.2.2.2">The Expected Residual Time (ERT) <span class="bcp14">MAY</span> be used to indicate the
        expected remaining time for transmission of the current
        object in order to optimize detection of a lost delivery object.<a href="#section-5.1-4.2.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.1-4.2.2.3">The Sender Last Changed (SLC) flag is typically not utilized
        but <span class="bcp14">MAY</span> be used to indicate the addition/removal of Segments.<a href="#section-5.1-4.2.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-5.1-5">
   Additional extension headers <span class="bcp14">MAY</span> be used to support real-time
   delivery. Such extension headers are defined in <a href="#sect-2.1" class="xref">Section 2.1</a>.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.2">
<section id="section-5.2">
        <h3 id="name-route-packetization-for-sou">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-route-packetization-for-sou" class="section-name selfRef">ROUTE Packetization for Source Flow</a>
        </h3>
<p id="section-5.2-1">
   The following description of the ROUTE sender operation on the
   mapping of the Application Object to the ROUTE packet payloads
   logically represents an extension of RFC 5445 <span>[<a href="#RFC5445" class="xref">RFC5445</a>]</span>, which in
   turn inherits the context, language, declarations, and restrictions of
   the FEC building block in RFC 5052 <span>[<a href="#RFC5052" class="xref">RFC5052</a>]</span>.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
   The data carried in the payload of a given ROUTE packet constitutes a
   contiguous portion of the Application Object. ROUTE source delivery
   can be considered as a special case of the use of the Compact No-Code
   Scheme associated with FEC Encoding ID = 0 according to Sections
   <a href="https://www.rfc-editor.org/rfc/rfc5445#section-3.4.1" class="relref">3.4.1</a> and <a href="https://www.rfc-editor.org/rfc/rfc5445#section-3.4.2" class="relref">3.4.2</a> of <span>[<a href="#RFC5445" class="xref">RFC5445</a>]</span>, in which the encoding symbol
   size is exactly one byte. As specified in <a href="#sect-2.1" class="xref">Section 2.1</a>, for ROUTE
   Source Flows, the FEC Payload ID <span class="bcp14">SHALL</span> deliver the 32-bit
   start_offset. All receivers are expected to support, at minimum,
   operation with this special case of the Compact No-Code FEC.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">
   Note that in the event the source object size is greater than 2<sup>32</sup> bytes
   (approximately 4.3 GB), the applications (in the broadcaster server and the
   receiver) are expected to perform segmentation/reassembly using methods
   beyond the scope of this document.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2-4">
   Finally, in some special cases, a ROUTE sender <span class="bcp14">MAY</span> need to produce
   ROUTE packets that do not contain any payload. This may be required,
   for example, to signal the end of a session. These dataless packets
   do not contain FEC Payload ID or payload data, but only the LCT
   header fields. The total datagram length, conveyed by outer protocol
   headers (e.g., the IP or UDP header), enables receivers to detect the
   absence of the LCT header, FEC Payload ID, and payload data.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
<div id="sect-5.2.1">
<section id="section-5.2.1">
          <h4 id="name-basic-route-packetization">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-basic-route-packetization" class="section-name selfRef">Basic ROUTE Packetization</a>
          </h4>
<p id="section-5.2.1-1">
   In the basic operation, it is assumed that the Application Object is
   fully available at the ROUTE sender.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.2.1-2">
<li id="section-5.2.1-2.1">The amount of data to be sent in a single ROUTE packet is limited
      by the maximum transfer unit of the data packets or the size of
      the remaining data of the Application Object being sent, whichever
      is smaller. The transfer unit is determined either by knowledge of
      underlying transport block sizes or by other constraints.<a href="#section-5.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-5.2.1-2.2">The start_offset field in the LCT header of the ROUTE packet
      indicates the byte offset of the carried data in the Application
      Object being sent.<a href="#section-5.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li id="section-5.2.1-2.3">The Close Object flag (B) is set to 1 if this is the last ROUTE
      packet carrying the data of the Application Object.<a href="#section-5.2.1-2.3" class="pilcrow">¶</a>
</li>
          </ol>
<p id="section-5.2.1-3">
   The order of packet delivery is arbitrary, but in the absence of
   other constraints, delivery with increasing start_offset value is
   recommended.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.2.2">
<section id="section-5.2.2">
          <h4 id="name-route-packetization-for-cma">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-route-packetization-for-cma" class="section-name selfRef">ROUTE Packetization for CMAF Chunked Content</a>
          </h4>
<p id="section-5.2.2-1">
   The following additional guidelines should be followed for ROUTE
   packetization of CMAF Chunked Content in addition to the guidelines of
   <a href="#sect-5.2.1" class="xref">Section 5.2.1</a>:<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-5.2.2-2">
<li id="section-5.2.2-2.1">If it is the first ROUTE packet carrying a CMAF Random Access
      chunk, except for the first CMAF Chunk in the segment, the
      Codepoint value <span class="bcp14">MAY</span> be set to 10, as specified in the Codepoint
      value table in <a href="#sect-2.1" class="xref">Section 2.1</a>. The receiver <span class="bcp14">MAY</span> use this information
      for optimization of random access.<a href="#section-5.2.2-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-5.2.2-2.2">As soon as the total length of the media object is known,
      potentially with the packaging of the last CMAF Chunk of a
      segment, the EXT_TOL extension header <span class="bcp14">MAY</span> be added to the LCT
      header to signal the Transfer Length, so that the receiver may
      know this information in a timely fashion.<a href="#section-5.2.2-2.2" class="pilcrow">¶</a>
</li>
          </ol>
</section>
</div>
</section>
</div>
<div id="sect-5.3">
<section id="section-5.3">
        <h3 id="name-timing-of-packet-emission">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-timing-of-packet-emission" class="section-name selfRef">Timing of Packet Emission</a>
        </h3>
<p id="section-5.3-1">
   The sender <span class="bcp14">SHALL</span> use the timing information provided by the
   application to time the emission of packets for a timely reception.
   This information may be contained in the Application Objects e.g.,
   DASH segments and/or the presentation manifest. Hence, such packets of
   streaming media with real-time constraints <span class="bcp14">SHALL</span> be sent in such a
   way as to enable their timely reception with respect to the presentation
   timeline.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.4">
<section id="section-5.4">
        <h3 id="name-extended-fdt-encoding-for-f">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-extended-fdt-encoding-for-f" class="section-name selfRef">Extended FDT Encoding for File Mode Sending</a>
        </h3>
<p id="section-5.4-1">
   For File Mode sending:<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.4-2.1">The TOI field in the ROUTE packet header <span class="bcp14">SHALL</span> be set such that
      Content-Location can be derived at the receiver according to File
      Template substitution specified in <a href="#sect-6.3.1" class="xref">Section 6.3.1</a>.<a href="#section-5.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.4-2.2">After sending the first packet with a given TOI value, none of the
      packets pertaining to this TOI <span class="bcp14">SHALL</span> be sent later than the wall
      clock time as derived from maxExpiresDelta. The EXT_TIME header
      with Expected Residual Time (ERT) <span class="bcp14">MAY</span> be used in order to convey
      more accurate expiry time.<a href="#section-5.4-2.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sect-5.5">
<section id="section-5.5">
        <h3 id="name-fec-framework-consideration">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-fec-framework-consideration" class="section-name selfRef">FEC Framework Considerations</a>
        </h3>
<p id="section-5.5-1">
   The FEC framework uses concepts of the FECFRAME work as defined in
   RFC 6363 <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>, as well as the FEC building block, RFC 5052
   <span>[<a href="#RFC5052" class="xref">RFC5052</a>]</span>, which is adopted in the existing FLUTE/ALC/LCT
   specifications.<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<p id="section-5.5-2">
   The FEC design adheres to the following principles:<a href="#section-5.5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.5-3.1">FEC-related information is provided only where needed.<a href="#section-5.5-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.5-3.2">Receivers not capable of this framework can ignore repair packets.<a href="#section-5.5-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.5-3.3">The FEC is symbol based with fixed symbol size per protected
     Source Flow. The ALC protocol and existing FEC schemes are reused.<a href="#section-5.5-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.5-3.4">A FEC Repair Flow provides protection of delivery objects from one
     or more Source Flows.<a href="#section-5.5-3.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.5-4">
   The FEC-specific components of the FEC framework are:<a href="#section-5.5-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.5-5.1">FEC Repair Flow declaration including all FEC-specific
     information.<a href="#section-5.5-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.5-5.2">A FEC transport object that is the concatenation of a delivery object,
     padding octets, and size information in order to form a chunk of data that has a size in symbols of N, where N &gt;= 1.<a href="#section-5.5-5.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.5-5.3">A FEC super-object that is the concatenation of one or more FEC
     transport objects in order to bundle FEC transport objects for FEC
     protection.<a href="#section-5.5-5.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.5-5.4">A FEC protocol and packet structure.<a href="#section-5.5-5.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.5-6">
   A receiver needs to be able to recover delivery objects from repair
   packets based on available FEC information.<a href="#section-5.5-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.6">
<section id="section-5.6">
        <h3 id="name-fec-transport-object-constr">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-fec-transport-object-constr" class="section-name selfRef">FEC Transport Object Construction</a>
        </h3>
<p id="section-5.6-1">
   In order to identify a delivery object in the context of the repair
   protocol, the following information is needed:<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.6-2.1">TSI and TOI of the delivery object. In this case, the FEC object
     corresponds to the (entire) delivery object.<a href="#section-5.6-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-2.2">Octet range of the delivery object, i.e., start offset within the delivery
     object and number of subsequent and contiguous octets of delivery object
     that constitutes the FEC object (i.e., the FEC-protected portion of the
     source object). In this case, the FEC object corresponds to a contiguous
     byte range portion of the delivery object.<a href="#section-5.6-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.6-3">
   Typically, for real-time object delivery with smaller delivery object
   sizes, the first mapping is applied, i.e., the delivery object is a
   FEC object.<a href="#section-5.6-3" class="pilcrow">¶</a></p>
<p id="section-5.6-4">
   Assuming that the FEC object is the delivery object, for each
   delivery object, the associated FEC transport object is comprised of
   the concatenation of the delivery object, padding octets (P), and the
   FEC object size (F) in octets, where F is carried in a 4-octet field.<a href="#section-5.6-4" class="pilcrow">¶</a></p>
<p id="section-5.6-5">
   The FEC transport object size S, in FEC encoding symbols, <span class="bcp14">SHALL</span> be an
   integer multiple of the symbol size Y.  S is determined from the session
   information and/or the repair packet headers.<a href="#section-5.6-5" class="pilcrow">¶</a></p>
<p id="section-5.6-6">
   F is carried in the last 4 octets of the FEC transport object.
   Specifically, let:<a href="#section-5.6-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.6-7.1">F be the size of the delivery object in octets,<a href="#section-5.6-7.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-7.2">F' be the F octets of data of the delivery object,<a href="#section-5.6-7.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-7.3">f' denote the four octets of data carrying the value of F in
     network octet order (high-order octet first),<a href="#section-5.6-7.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-7.4">S be the size of the FEC transport object with S=ceil((F+4)/Y),
     where the ceil() function rounds the result upward to its nearest
     integer,<a href="#section-5.6-7.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-7.5">P' be S*Y-4-F octets of data, i.e., padding placed between the
     delivery object and the 4-byte field conveying the value of F and
     located at the end of the FEC transport object, and<a href="#section-5.6-7.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-7.6">O' be the concatenation of F', P', and f'.<a href="#section-5.6-7.6" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.6-8">
   O' then constitutes the FEC transport object of size S*Y octets. Note
   that padding octets and the object size F are not sent in source
   packets of the delivery object but are only part of a FEC transport
   object that FEC decoding recovers in order to extract the FEC object
   and thus the delivery object or portion of the delivery object that
   constitutes the FEC object. In the above context, the FEC transport
   object size in symbols is S.<a href="#section-5.6-8" class="pilcrow">¶</a></p>
<p id="section-5.6-9">
   The general information about a FEC transport object that is
   conveyed to a FEC-enabled receiver is the source TSI, source TOI, and
   the associated octet range within the delivery object comprising the
   associated FEC object. However, as the size in octets of the FEC
   object is provided in the appended field within the FEC transport
   object, the remaining information can be conveyed as:<a href="#section-5.6-9" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.6-10.1">The TSI and TOI of the delivery object from which the FEC object
     associated with the FEC transport object is generated<a href="#section-5.6-10.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-10.2">The start octet within the delivery object for the associated FEC object<a href="#section-5.6-10.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.6-10.3">The size in symbols of the FEC transport object, S<a href="#section-5.6-10.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sect-5.7">
<section id="section-5.7">
        <h3 id="name-super-object-construction">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-super-object-construction" class="section-name selfRef">Super-Object Construction</a>
        </h3>
<p id="section-5.7-1">
   From the FEC Repair Flow declaration, the construction of a FEC
   super-object as the concatenation of one or more FEC transport
   objects can be determined. The FEC super-object includes the general
   information about the FEC transport objects as described in the
   previous sections, as well as the placement order of FEC transport
   objects within the FEC super-object.<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">
   Let:<a href="#section-5.7-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.7-3.1">N be the total number of FEC transport objects for the FEC super-object
     construction.<a href="#section-5.7-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.7-3.2">For i = 0, ..., N-1, let S[i] be the size in symbols of FEC
     transport object i.<a href="#section-5.7-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.7-3.3">B' be the FEC super-object that is the concatenation of the FEC
     transport objects in numerical order, comprised of K = Sum of N
     source symbols, each symbol denoted as S[i].<a href="#section-5.7-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.7-4">
   For each FEC super-object, the remaining general information that
   needs to be conveyed to a FEC-enabled receiver, beyond what is
   already carried in the FEC transport objects that constitute the FEC
   super-object, comprises:<a href="#section-5.7-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.7-5.1">The total number of FEC transport objects N.<a href="#section-5.7-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.7-5.2">
            <p id="section-5.7-5.2.1">For each FEC transport object:<a href="#section-5.7-5.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.7-5.2.2.1">The TSI and TOI of the delivery object from which the FEC object
        associated with the FEC transport object is generated,<a href="#section-5.7-5.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.7-5.2.2.2">The start octet within the delivery object for the associated FEC
        object, and<a href="#section-5.7-5.2.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.7-5.2.2.3">The size in symbols of the FEC transport object.<a href="#section-5.7-5.2.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-5.7-6">
   The carriage of the FEC repair information is discussed below.<a href="#section-5.7-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-5.8">
<section id="section-5.8">
        <h3 id="name-repair-packet-consideration">
<a href="#section-5.8" class="section-number selfRef">5.8. </a><a href="#name-repair-packet-consideration" class="section-name selfRef">Repair Packet Considerations</a>
        </h3>
<p id="section-5.8-1">
   The repair protocol is based on Asynchronous Layered Coding (ALC) as
   defined in RFC 5775 <span>[<a href="#RFC5775" class="xref">RFC5775</a>]</span> and the Layered Coding Transport (LCT)
   Building Block as defined in RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span> with the following
   details:<a href="#section-5.8-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.8-2.1">
            <p id="section-5.8-2.1.1">The Layered Coding Transport (LCT) Building Block as defined in
     RFC 5651 <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span> is used as defined in Asynchronous Layered
     Coding (ALC), <a href="#sect-2.1" class="xref">Section 2.1</a>. In addition, the following constraint
     applies:<a href="#section-5.8-2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.8-2.1.2.1">The TSI in the LCT header <span class="bcp14">SHALL</span> identify the Repair Flow to
       which this packet applies by the matching the value of the ptsi
       attribute in the signaling metadata among the LCT channels
       carrying Repair Flows.<a href="#section-5.8-2.1.2.1" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li class="normal" id="section-5.8-2.2">
            <p id="section-5.8-2.2.1">The FEC building block is used according to RFC 6330 <span>[<a href="#RFC6330" class="xref">RFC6330</a>]</span>,
     but only repair packets are delivered.<a href="#section-5.8-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.8-2.2.2.1">Each repair packet within the scope of the Repair Flow (as indicated
        by the TSI field in the LCT header) <span class="bcp14">SHALL</span> carry the repair symbols for
        a corresponding FEC transport object/super-object as identified by its
        TOI. The repair object/super- object TOI <span class="bcp14">SHALL</span> be unique for each FEC
        super-object that is created within the scope of the TSI.<a href="#section-5.8-2.2.2.1" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
</section>
</div>
<div id="sect-5.9">
<section id="section-5.9">
        <h3 id="name-summary-fec-information">
<a href="#section-5.9" class="section-number selfRef">5.9. </a><a href="#name-summary-fec-information" class="section-name selfRef">Summary FEC Information</a>
        </h3>
<p id="section-5.9-1">
   For each super-object (identified by a unique TOI within a Repair
   Flow that is in turn identified by the TSI in the LCT header) that is
   generated, the following information needs to be communicated to the
   receiver:<a href="#section-5.9-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.9-2.1">
            <p id="section-5.9-2.1.1">The FEC configuration consisting of:<a href="#section-5.9-2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.9-2.1.2.1">FEC Object Transmission Information (OTI) per RFC 5052
        <span>[<a href="#RFC5052" class="xref">RFC5052</a>]</span>.<a href="#section-5.9-2.1.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.9-2.1.2.2">Additional FEC information (see <a href="#sect-3.3" class="xref">Section 3.3</a>).<a href="#section-5.9-2.1.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.9-2.1.2.3">The total number of FEC objects included in the FEC super-object, N.<a href="#section-5.9-2.1.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li class="normal" id="section-5.9-2.2">
            <p id="section-5.9-2.2.1">For each FEC transport object:<a href="#section-5.9-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.9-2.2.2.1">TSI and TOI of the delivery object used to generate the FEC
        object associated with the FEC transport object,<a href="#section-5.9-2.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.9-2.2.2.2">The start octet within the delivery object of the associated FEC
        object, if applicable, and<a href="#section-5.9-2.2.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-5.9-2.2.2.3">The size in symbols of the FEC transport object, S.<a href="#section-5.9-2.2.2.3" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-5.9-3">
   The above information is delivered:<a href="#section-5.9-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.9-4.1">Statically in the session metadata as defined in <a href="#sect-3.3" class="xref">Section 3.3</a>, and<a href="#section-5.9-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.9-4.2">Dynamically in an LCT extension header.<a href="#section-5.9-4.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="sect-6">
<section id="section-6">
      <h2 id="name-receiver-operation">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-receiver-operation" class="section-name selfRef">Receiver Operation</a>
      </h2>
<p id="section-6-1">
   The receiver receives packets and filters those packets according to
   the following. From the ROUTE session and each contained LCT channel,
   the receiver regenerates delivery objects from the ROUTE session and
   each contained LCT channel.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
   In the event that the receiver receives data that does not conform to
   the ROUTE protocol specified in this document, the receiver <span class="bcp14">SHOULD</span>
   attempt to recover gracefully by e.g., informing the application about
   the issues using means beyond the scope of this document. The ROUTE
   packetization specified in <a href="#sect-5.2.1" class="xref">Section 5.2.1</a> implies that the receiver
   <span class="bcp14">SHALL NOT</span> receive overlapping data; if such a condition is
   encountered at the receiver, the packet <span class="bcp14">SHALL</span> be assumed to be
   corrupted.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">
   The basic receiver operation is provided below (it assumes an error-free
   scenario), while repair considerations are provided in <a href="#sect-7" class="xref">Section 7</a>.<a href="#section-6-3" class="pilcrow">¶</a></p>
<div id="sect-6.1">
<section id="section-6.1">
        <h3 id="name-basic-application-object-re">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-basic-application-object-re" class="section-name selfRef">Basic Application Object Recovery for Source Flows</a>
        </h3>
<p id="section-6.1-1">
   Upon receipt of each ROUTE packet of a Source Flow, the receiver
   proceeds with the following steps in the order listed.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="olPercent" id="section-6.1-2">
<dt>1)</dt>
<dd id="section-6.1-2.1">The ROUTE receiver is expected to parse the LCT and FEC Payload ID to
     verify that it is a valid header. If it is not valid, then the payload is
     discarded without further processing.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>2)</dt>
<dd id="section-6.1-2.2">All ROUTE packets used to recover a specific delivery object carry the
     same TOI value in the LCT header.<a href="#section-6.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>3)</dt>
<dd id="section-6.1-2.3">The ROUTE receiver is expected to assert that the TSI and the
     Codepoint represent valid operation points in the signaling metadata,
     i.e., the signaling contains a matching entry to the TSI value provided in
     the packet header, as well as for this TSI, and the Codepoint field in the
     LCT header has a valid Codepoint mapping.<a href="#section-6.1-2.3" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt>4)</dt>
<dd id="section-6.1-2.4">
            <p id="section-6.1-2.4.1">The ROUTE receiver should process the remainder of the payload,
     including the appropriate interpretation of the other payload header
     fields, using the source FEC Payload ID (to determine the
     start_offset) and the payload data to reconstruct the corresponding
     object as follows:<a href="#section-6.1-2.4.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-6.1-2.4.2">
<li id="section-6.1-2.4.2.1">For File Mode, upon receipt of the first ROUTE packet
         payload for an object, the ROUTE receiver uses the
         File@Transfer-Length attribute of the associated Extended FDT-Instance, when present, to determine the length T of the
         object. When the File@Transfer-Length attribute is not
         present in the Extended FDT-Instance, the receiver uses the
         maxTransportSize attribute of the associated Extended FDT-Instance to determine the maximum length T' of the object.
         Alternatively, and specifically for delivery modes other than
         File Mode, the EXT_TOL header can be used to determine the length
         T of the object.<a href="#section-6.1-2.4.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-6.1-2.4.2.2">The ROUTE receiver allocates buffer space for the T or T'
         bytes that the object will or may occupy.<a href="#section-6.1-2.4.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-6.1-2.4.2.3">The ROUTE receiver computes the length of the payload, Y, by
         subtracting the payload header length from the total length
         of the received payload.<a href="#section-6.1-2.4.2.3" class="pilcrow">¶</a>
</li>
              <li id="section-6.1-2.4.2.4">
                <p id="section-6.1-2.4.2.4.1">The ROUTE receiver allocates a Boolean array RECEIVED[0..T-1] or
         RECEIVED[0..T'-1], as appropriate, with all entries initialized to
         false to track received object symbols. The ROUTE receiver
         continuously acquires packet payloads for the object as long as all
         of the following conditions are satisfied:<a href="#section-6.1-2.4.2.4.1" class="pilcrow">¶</a></p>
<ol start="1" type="i" class="normal type-i" id="section-6.1-2.4.2.4.2">
    <li id="section-6.1-2.4.2.4.2.1">there is at least one entry in RECEIVED still set to false,<a href="#section-6.1-2.4.2.4.2.1" class="pilcrow">¶</a>
</li>
                  <li id="section-6.1-2.4.2.4.2.2">the object has not yet expired, and<a href="#section-6.1-2.4.2.4.2.2" class="pilcrow">¶</a>
</li>
                  <li id="section-6.1-2.4.2.4.2.3">
                    <p id="section-6.1-2.4.2.4.2.3.1">the application has not given up on reception of this object.<a href="#section-6.1-2.4.2.4.2.3.1" class="pilcrow">¶</a></p>
<p id="section-6.1-2.4.2.4.2.3.2">More details are provided below.<a href="#section-6.1-2.4.2.4.2.3.2" class="pilcrow">¶</a></p>
</li>
                </ol>
</li>
              <li id="section-6.1-2.4.2.5">
                <p id="section-6.1-2.4.2.5.1">For each received ROUTE packet payload for the object
                (including the first payload), the steps to be taken to help
                recover the object are as follows:<a href="#section-6.1-2.4.2.5.1" class="pilcrow">¶</a></p>
<ol start="1" type="i" class="normal type-i" id="section-6.1-2.4.2.5.2">
<li id="section-6.1-2.4.2.5.2.1">If the packet includes an
                EXT_TOL or EXT_FTI header, modify the Boolean array
                RECEIVED[0..T'-1] to become RECEIVED[0..T-1].<a href="#section-6.1-2.4.2.5.2.1" class="pilcrow">¶</a>
</li>
                  <li id="section-6.1-2.4.2.5.2.2">Let X be the value of the start_offset field in the ROUTE
     packet header and let Y be the length of the payload, Y, computed
     by subtracting the LCT header size and the FEC Payload ID size
     from the total length of the received packet.<a href="#section-6.1-2.4.2.5.2.2" class="pilcrow">¶</a>
</li>
                  <li id="section-6.1-2.4.2.5.2.3">The ROUTE receiver copies the data into the appropriate place
     within the space reserved for the object and sets RECEIVED[X
     ... X+Y-1] = true.<a href="#section-6.1-2.4.2.5.2.3" class="pilcrow">¶</a>
</li>
                  <li id="section-6.1-2.4.2.5.2.4">If all T entries of RECEIVED are true, then the receiver has
     recovered the entire object.<a href="#section-6.1-2.4.2.5.2.4" class="pilcrow">¶</a>
</li>
                </ol>
</li>
            </ol>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-6.1-3">
   Upon recovery of both the complete set of packet payloads for the
   delivery object associated with a given TOI value, and the metadata
   for that delivery object, the reception of the delivery object, now a
   fully received Application Object, is complete.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">
   Given the timely reception of ROUTE packets belonging to an
   Application Object, the receiver <span class="bcp14">SHALL</span> make the Application Objects
   available to the application in a timely fashion using the
   application-provided timing data (e.g., the timing data signaled via
   the presentation manifest file). For example, HTTP/1.1 chunked
   transfer may need to be enabled to transfer the Application Objects
   if MPD@availabilityTimeOffset is signaled in the DASH presentation
   manifest in order to allow for the timely sending of segment data to the
   application.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6.2">
<section id="section-6.2">
        <h3 id="name-fast-stream-acquisition">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-fast-stream-acquisition" class="section-name selfRef">Fast Stream Acquisition</a>
        </h3>
<p id="section-6.2-1">
   When the receiver initially starts reception of ROUTE packets, it is likely
   that the reception does not start from the very first packet carrying the
   data of a multicast transport object; in this case, such a partially
   received object is normally discarded. However, the channel acquisition or
   "tune-in" times can be improved if the partially received object is usable
   by the application.  One example realization for this is as follows:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">The receiver checks for the first received packet with the
     Codepoint value set to 10, indicating the start of a CMAF Random
     Access chunk.<a href="#section-6.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.2">The receiver <span class="bcp14">MAY</span> make the partially received object (a partial
     DASH segment starting from the packet above) available to the
     application for fast stream acquisition.<a href="#section-6.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.3">It <span class="bcp14">MAY</span> recover the earliest presentation time of this CMAF Random
     Access chunk from the ROUTE packet LCT Congestion Control
     Information (CCI) field as specified in <a href="#sect-2.1" class="xref">Section 2.1</a> to be able to
     add a new Period element in the MPD exposed to the application
      containing just the partially received DASH segment with period
      continuity signaling.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="sect-6.3">
<section id="section-6.3">
        <h3 id="name-generating-extended-fdt-ins">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-generating-extended-fdt-ins" class="section-name selfRef">Generating Extended FDT-Instance for File Mode</a>
        </h3>
<p id="section-6.3-1">
   An Extended FDT-Instance conforming to RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>, is produced at the receiver using the service metadata
   and in-band signaling in the following steps:<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<div id="sect-6.3.1">
<section id="section-6.3.1">
          <h4 id="name-file-template-substitution-">
<a href="#section-6.3.1" class="section-number selfRef">6.3.1. </a><a href="#name-file-template-substitution-" class="section-name selfRef">File Template Substitution for Content-Location Derivation</a>
          </h4>
<p id="section-6.3.1-1">
   The Content-Location element of the Extended FDT for a specific
   Application Object is derived as follows:<a href="#section-6.3.1-1" class="pilcrow">¶</a></p>
<p id="section-6.3.1-2">
   "$TOI$" is substituted with the unique TOI value in the LCT header of
   the ROUTE packets used to recover the given delivery object (as
   specified in <a href="#sect-6.1" class="xref">Section 6.1</a>).<a href="#section-6.3.1-2" class="pilcrow">¶</a></p>
<p id="section-6.3.1-3">
   After the substitution, the fileTemplate <span class="bcp14">SHALL</span> be a valid URL
   corresponding to the Content-Location attribute of the associated
   Application Object.<a href="#section-6.3.1-3" class="pilcrow">¶</a></p>
<p id="section-6.3.1-4">
   An example @fileTemplate using a width of 5 is:
   fileTemplate="myVideo$TOI%05d$.mps", resulting in file names with
   exactly five digits in the number portion. The Media Segment file
   name for TOI=33 using this template is myVideo00033.mps.<a href="#section-6.3.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6.3.2">
<section id="section-6.3.2">
          <h4 id="name-filetransfer-length-derivat">
<a href="#section-6.3.2" class="section-number selfRef">6.3.2. </a><a href="#name-filetransfer-length-derivat" class="section-name selfRef">File@Transfer-Length Derivation</a>
          </h4>
<p id="section-6.3.2-1">
   Either the EXT_FTI header (per RFC 5775 <span>[<a href="#RFC5775" class="xref">RFC5775</a>]</span>) or the EXT_TOL
   header, when present, is used to derive the Transport Object Length
   (TOL) of the File. If the File@Transfer-Length parameter in the
   Extended FDT-Instance is not present, then the EXT_TOL header or the
   or EXT_FTI header <span class="bcp14">SHALL</span> be present. Note that a header containing the
   transport object length (EXT_TOL or EXT_FTI) need not be present in
   each packet header. If the broadcaster does not know the length of
   the transport object at the beginning of the transfer, an EXT_TOL or
   EXT_FTI header <span class="bcp14">SHALL</span> be included in at least the last packet of the
   file and should be included in the last few packets of the transfer.<a href="#section-6.3.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6.3.3">
<section id="section-6.3.3">
          <h4 id="name-fdt-instanceexpires-derivat">
<a href="#section-6.3.3" class="section-number selfRef">6.3.3. </a><a href="#name-fdt-instanceexpires-derivat" class="section-name selfRef">FDT-Instance@Expires Derivation</a>
          </h4>
<p id="section-6.3.3-1">
   When present, the maxExpiresDelta attribute <span class="bcp14">SHALL</span> be used to generate
   the value of the FDT-Instance@Expires attribute. The receiver is
   expected to add this value to its wall clock time when acquiring the
   first ROUTE packet carrying the data of a given delivery object to
   obtain the value for @Expires.<a href="#section-6.3.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3.3-2">
   When maxExpiresDelta is not present, the EXT_TIME header with
   Expected Residual Time (ERT) <span class="bcp14">SHALL</span> be used to derive the expiry time
   of the Extended FDT-Instance. When both maxExpiresDelta and the ERT
   of EXT_TIME are present, the smaller of the two values should be used
   as the incremental time interval to be added to the receiver's
   current time to generate the effective value for @Expires. When
   neither maxExpiresDelta nor the ERT field of the EXT_TIME header is
   present, then the expiration time of the Extended FDT-Instance is
   given by its @Expires attribute.<a href="#section-6.3.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="sect-7">
<section id="section-7">
      <h2 id="name-fec-application">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-fec-application" class="section-name selfRef">FEC Application</a>
      </h2>
<div id="sect-7.1">
<section id="section-7.1">
        <h3 id="name-general-fec-application-gui">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-general-fec-application-gui" class="section-name selfRef">General FEC Application Guidelines</a>
        </h3>
<p id="section-7.1-1">
   It is up to the receiver to decide to use zero, one, or more of the
   FEC streams. Hence, the application assigns a recovery property to
   each flow, which defines aspects such as the delay and the required
   memory if one or the other is chosen. The receiver <span class="bcp14">MAY</span> decide whether
   or not to utilize Repair Flows based on the following considerations:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1-2.1">The desired start-up and end-to-end latency. If a Repair Flow
     requires a significant amount of buffering time to be effective,
     such Repair Flow might only be used in time-shift operations or in
     poor reception conditions, since use of such Repair Flow trades
     off end-to-end latency against DASH Media Presentation quality.<a href="#section-7.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.2">FEC capabilities, i.e., the receiver <span class="bcp14">MAY</span> pick only the FEC
     algorithm that it supports.<a href="#section-7.1-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.3">Which Source Flows are being protected; for example, if the Repair
     Flow protects Source Flows that are not selected by the receiver,
     then the receiver may not select the Repair Flow.<a href="#section-7.1-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.4">Other considerations such as available buffer size, reception
     conditions, etc.<a href="#section-7.1-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.1-3">
   If a receiver decides to acquire a certain Repair Flow, then the
   receiver must receive data on all Source Flows that are protected by
   that Repair Flow to collect the relevant packets.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-7.2">
<section id="section-7.2">
        <h3 id="name-toi-mapping">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-toi-mapping" class="section-name selfRef">TOI Mapping</a>
        </h3>
<p id="section-7.2-1">
   When mappingTOIx/mappingTOIy are used to signal X and Y values, the TOI
   value(s) of the one or more source objects (sourceTOI) protected by a given
   FEC transport object or FEC super-object with a TOI value rTOI is derived
   through an equation sourceTOI = X*rTOI + Y.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">
   When neither mappingTOIx nor mappingTOIy is present, there is a 1:1
   relationship between each delivery object carried in the Source Flow
   as identified by ptsi to a FEC object carried in this Repair Flow.
   In this case, the TOI of each of those delivery objects <span class="bcp14">SHALL</span> be
   identical to the TOI of the corresponding FEC object.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-7.3">
<section id="section-7.3">
        <h3 id="name-delivery-object-reception-t">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-delivery-object-reception-t" class="section-name selfRef">Delivery Object Reception Timeout</a>
        </h3>
<p id="section-7.3-1">
   The permitted start and end times for the receiver to perform the
   file repair procedure, in case of unsuccessful broadcast file
   reception, and associated rules and parameters are as follows:<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.3-2.1">The latest time that the file repair procedure may start is bound
     by the @Expires attribute of the FDT-Instance.<a href="#section-7.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-2.2">
            <p id="section-7.3-2.2.1">The receiver may choose to start the file repair procedure
            earlier if it detects the occurrence of any of the following
            events:<a href="#section-7.3-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.3-2.2.2.1">Presence of the Close Object flag (B) in the LCT header
        <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span> for the file of interest;<a href="#section-7.3-2.2.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-7.3-2.2.2.2">Presence of the Close Session flag (A) in the LCT header
        <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span> before the nominal expiration of the Extended FDT-Instance as defined by the @Expires attribute.<a href="#section-7.3-2.2.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
</section>
</div>
<div id="sect-7.4">
<section id="section-7.4">
        <h3 id="name-example-fec-operation">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-example-fec-operation" class="section-name selfRef">Example FEC Operation</a>
        </h3>
<p id="section-7.4-1">
   To be able to recover the delivery objects that are protected by a Repair
   Flow, a receiver needs to obtain the necessary Service signaling metadata
   fragments that describe the corresponding collection of delivery objects
   that are covered by this Repair Flow.  A Repair Flow is characterized by
   the combination of an LCT channel, a unique TSI number, as well as the
   corresponding protected Source Flows.<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<p id="section-7.4-2">
   If a receiver acquires data of a Repair Flow, the receiver is expected to
   collect all packets of all protected Transport Sessions.  Upon receipt of
   each packet, whether it is a source or repair packet, the receiver proceeds
   with the following steps in the order listed.<a href="#section-7.4-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-7.4-3">
<li id="section-7.4-3.1">The receiver is expected to parse
        the packet header and verify that it is a valid header. If it is not
        valid, then the packet <span class="bcp14">SHALL</span> be discarded without
        further processing.<a href="#section-7.4-3.1" class="pilcrow">¶</a>
</li>
          <li id="section-7.4-3.2">The receiver is expected to parse the TSI field of the packet
          header and verify that a matching value exists in the Service
          signaling for the Repair Flow or the associated Protected Source
          Flow. If no match is found, the packet <span class="bcp14">SHALL</span> be
          discarded without further processing.<a href="#section-7.4-3.2" class="pilcrow">¶</a>
</li>
          <li id="section-7.4-3.3">
            <p id="section-7.4-3.3.1">The receiver processes the remainder of the packet, including
            interpretation of the other header fields, and using the source
            FEC Payload ID (to determine the start_offset byte position within
            the source object), the Repair FEC Payload ID, as well as the
            payload data, reconstructs the decoding blocks corresponding to a
            FEC super-object as follows:<a href="#section-7.4-3.3.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-7.4-3.3.2">
<li id="section-7.4-3.3.2.1">For a source packet, the
            receiver identifies the delivery object to which the received
            packet is associated using the session information and the TOI
            carried in the payload header. Similarly, for a repair object, the
            receiver identifies the FEC super-object to which the received
            packet is associated using the session information and the TOI
            carried in the payload header.<a href="#section-7.4-3.3.2.1" class="pilcrow">¶</a>
</li>
              <li id="section-7.4-3.3.2.2">For source packets, the receiver collects the data for each
              FEC super-object and recovers FEC super-objects in the same way
              as a Source Flow in <a href="#sect-6.1" class="xref">Section 6.1</a>. The received FEC super-object is then mapped
              to a source block and the corresponding encoding symbols are
              generated.<a href="#section-7.4-3.3.2.2" class="pilcrow">¶</a>
</li>
              <li id="section-7.4-3.3.2.3">With the reception of the repair packets, the FEC
              super-object can be recovered.<a href="#section-7.4-3.3.2.3" class="pilcrow">¶</a>
</li>
              <li id="section-7.4-3.3.2.4">Once the FEC super-object is recovered, the individual
         delivery objects can be extracted.<a href="#section-7.4-3.3.2.4" class="pilcrow">¶</a>
</li>
            </ol>
</li>
        </ol>
</section>
</div>
</section>
</div>
<div id="sect-8">
<section id="section-8">
      <h2 id="name-considerations-for-defining">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-considerations-for-defining" class="section-name selfRef">Considerations for Defining ROUTE Profiles</a>
      </h2>
<p id="section-8-1">
   Services (e.g., ATSC-ROUTE <span>[<a href="#ATSCA331" class="xref">ATSCA331</a>]</span>, DVB-MABR <span>[<a href="#DVBMABR" class="xref">DVBMABR</a>]</span>, etc.) may define specific ROUTE "profiles" based
   on this document in their respective standards organizations. An example is
   noted in the overview section: DVB has specified a profile of ATSC-ROUTE in
   DVB Adaptive Media Streaming over IP Multicast (DVB-MABR) <span>[<a href="#DVBMABR" class="xref">DVBMABR</a>]</span>. The definition has the following
   considerations. Services <span class="bcp14">MAY</span><a href="#section-8-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8-2.1">Restrict the signaling of certain values signaled in the LCT header
     and/or provision unused fields in the LCT header.<a href="#section-8-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-2.2">Restrict using certain LCT header extensions and/or add new LCT
        header extensions.<a href="#section-8-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-2.3">Restrict or limit usage of some Codepoints and/or assign semantics
        to service-specific Codepoints marked as reserved in this
        document.<a href="#section-8-2.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-8-2.4">Restrict usage of certain Service signaling attributes and/or add
        their own service metadata.<a href="#section-8-2.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-8-3">
   Services <span class="bcp14">SHALL NOT</span> redefine the semantics of any of the ROUTE
   attributes in LCT headers and extensions, as well as Service signaling
   attributes already specified in this document.<a href="#section-8-3" class="pilcrow">¶</a></p>
<p id="section-8-4">
   By following these guidelines, services can define profiles that are
   interoperable.<a href="#section-8-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-9">
<section id="section-9">
      <h2 id="name-route-concepts">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-route-concepts" class="section-name selfRef">ROUTE Concepts</a>
      </h2>
<div id="sect-9.1">
<section id="section-9.1">
        <h3 id="name-route-modes-of-delivery">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-route-modes-of-delivery" class="section-name selfRef">ROUTE Modes of Delivery</a>
        </h3>
<p id="section-9.1-1">
   Different ROUTE delivery modes specified in <a href="#sect-4" class="xref">Section 4</a> are optimized for delivery of different types of media
   data. For example, File Mode is specifically optimized for delivering DASH
   content using Segment Template with number substitution. Using File
   Template in EFDT avoids the need for the repeated sending of metadata as
   outlined in the following section. Same optimizations, however, cannot be
   used for time substitution and segment timeline where the addressing of
   each segment is time dependent and in general does not follow a fixed or
   repeated pattern. In this case, Entity Mode is more optimized since it carries the
   file location in band. Also, Entity Mode can be used to deliver
   a file or part of the file using HTTP Partial Content response headers.<a href="#section-9.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-9.2">
<section id="section-9.2">
        <h3 id="name-file-mode-optimizations">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-file-mode-optimizations" class="section-name selfRef">File Mode Optimizations</a>
        </h3>
<p id="section-9.2-1">
   In File Mode, the delivery object represents an Application Object. This
   mode replicates FLUTE as defined in RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span> but with the ability to send static and pre-known file
   metadata out of band.<a href="#section-9.2-1" class="pilcrow">¶</a></p>
<p id="section-9.2-2">
   In FLUTE, FDT-Instances are delivered in band and need to be generated and
   delivered in real time if objects are generated in real time at the
   sender. These FDT-Instances have some differences as compared to the FDT
   specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6726#section-3.4.2" class="relref">Section 3.4.2</a> of [<a href="#RFC6726" class="xref">RFC6726</a>]</span> and Section 7.2.10 of MBMS
   <span>[<a href="#MBMS" class="xref">MBMS</a>]</span>. The key difference is that besides separated delivery of file
   metadata from the delivery object it describes, the FDT functionality in
   ROUTE may be extended by additional file metadata and rules that enable the
   receiver to generate the Content-Location attribute of the File element of
   the FDT, on the fly. This is done by using information in both the
   extensions to the FDT and the LCT header. The combination of pre-delivery
   of static file metadata and receiver self generation of dynamic file
   metadata avoids the necessity of continuously sending the FDT-Instances for
   real-time objects. Such modified FDT functionality in ROUTE is referred to
   as the Extended FDT.<a href="#section-9.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-9.3">
<section id="section-9.3">
        <h3 id="name-in-band-signaling-of-object">
<a href="#section-9.3" class="section-number selfRef">9.3. </a><a href="#name-in-band-signaling-of-object" class="section-name selfRef">In-Band Signaling of Object Transfer Length</a>
        </h3>
<p id="section-9.3-1">
   As an extension to FLUTE, ROUTE allows for using EXT_TOL LCT header
   extension with 24 bits or, if required, 48 bits to signal the Transfer
   Length directly within the ROUTE packet.<a href="#section-9.3-1" class="pilcrow">¶</a></p>
<p id="section-9.3-2">
   The transport object length can also be determined without the use of
   EXT_TOL by examining the LCT packet with the Close Object flag (B).
   However, if this packet is lost, then the EXT_TOL information can be
   used by the receiver to determine the transport object length.<a href="#section-9.3-2" class="pilcrow">¶</a></p>
<p id="section-9.3-3">
   Applications using ROUTE for delivery of low-latency streaming content may
   make use of this feature for sender-end latency optimizations: the sender
   does not have to wait for the completion of the packaging of a whole
   Application Object to find its Transfer Length to be included in the FDT
   before the sending can start.  Rather, partially encoded data can already
   be started to be sent via the ROUTE sender. As the time approaches when the
   encoding of the Application Object is nearing completion, and the length of
   the object becomes known (e.g., the time of writing the last CMAF Chunk of
   a DASH segment), only then the sender can signal the object length using
   the EXT TOL LCT header. For example, for a 2-second DASH segment with
   100-millisecond chunks, it may result in saving up to 1.9 second latency at
   the sending end.<a href="#section-9.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-9.4">
<section id="section-9.4">
        <h3 id="name-repair-protocol-concepts">
<a href="#section-9.4" class="section-number selfRef">9.4. </a><a href="#name-repair-protocol-concepts" class="section-name selfRef">Repair Protocol Concepts</a>
        </h3>
<p id="section-9.4-1">
   The ROUTE repair protocol is FEC-based and is enabled as an additional
   layer between the transport layer (e.g., UDP) and the object delivery layer
   protocol. The FEC reuses concepts of the FEC Framework defined in RFC 6363
   <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>, but in contrast to the FEC
   Framework in RFC 6363 <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>, the ROUTE
   repair protocol does not protect packets but instead protects delivery
   objects as delivered in the source protocol. In addition, as an extension
   to FLUTE, it supports the protection of multiple objects in one source
   block which is in alignment with the FEC Framework as defined in RFC 6363
   <span>[<a href="#RFC6363" class="xref">RFC6363</a>]</span>. Each FEC source block may
   consist of parts of a delivery object, as a single delivery object (similar
   to FLUTE) or multiple delivery objects that are bundled prior to FEC
   protection.  ROUTE FEC makes use of FEC schemes in a similar way as those
   defined in RFC 5052 <span>[<a href="#RFC5052" class="xref">RFC5052</a>]</span> and uses the
   terminology of that document. The FEC scheme defines the FEC encoding and
   decoding as well as the protocol fields and procedures used to identify
   packet payload data in the context of the FEC scheme.<a href="#section-9.4-1" class="pilcrow">¶</a></p>
<p id="section-9.4-2">
   In ROUTE, all packets are LCT packets as defined in RFC 5651
   <span>[<a href="#RFC5651" class="xref">RFC5651</a>]</span>. Source and repair packets may be distinguished by:<a href="#section-9.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9.4-3.1">Different ROUTE sessions, i.e., they are carried on different
     UDP/IP port combinations.<a href="#section-9.4-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-9.4-3.2">Different LCT channels, i.e., they use different TSI values in the
     LCT header.<a href="#section-9.4-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-9.4-3.3">The most significant PSI bit in the LCT, if carried in the same LCT
     channel. This mode of operation is mostly suitable for FLUTE-compatible
     deployments.<a href="#section-9.4-3.3" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="sect-10">
<section id="section-10">
      <h2 id="name-interoperability-chart">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-interoperability-chart" class="section-name selfRef">Interoperability Chart</a>
      </h2>
<p id="section-10-1">
   As noted in prevision sections, ATSC-ROUTE <span>[<a href="#ATSCA331" class="xref">ATSCA331</a>]</span> and DVB-MABR
   <span>[<a href="#DVBMABR" class="xref">DVBMABR</a>]</span> are considered services using this document that constrain
   specific features as well as add new ones. In this context, the
   following table is an informative comparison of the interoperability
   of ROUTE as specified in this document with ATSC-ROUTE
   <span>[<a href="#ATSCA331" class="xref">ATSCA331</a>]</span> and DVB-MABR <span>[<a href="#DVBMABR" class="xref">DVBMABR</a>]</span>:<a href="#section-10-1" class="pilcrow">¶</a></p>
<span id="name-interoperability-chart-2"></span><div id="interoperability">
<table class="center" id="table-3">
        <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-interoperability-chart-2" class="selfRef">Interoperability Chart</a>
        </caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Element</th>
            <th class="text-left" rowspan="1" colspan="1">ATSC-ROUTE</th>
            <th class="text-left" rowspan="1" colspan="1">This Document</th>
            <th class="text-left" rowspan="1" colspan="1">DVB-MABR</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="2" colspan="1">LCT header field</td>
            <td class="text-left" rowspan="1" colspan="1">PSI LSB set to 0 for Source Flow</td>
            <td class="text-left" rowspan="1" colspan="1">Not defined</td>
            <td class="text-left" rowspan="1" colspan="1">Set to 1 for Source Flow for CMAF Random Access chunk</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">CCI may be set to 0</td>
            <td class="text-left" rowspan="1" colspan="2">CCI may be set to EPT for Source Flow</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="2" colspan="1">LCT header extensions</td>
            <td class="text-left" rowspan="1" colspan="1">EXT_ROUTE_PRESENTATION_TIME Header used for Media Delivery Event (MDE) mode</td>
            <td class="text-left" rowspan="1" colspan="1">Not defined; may be added by a profile.</td>
            <td class="text-left" rowspan="1" colspan="1">Shall not be used.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">EXT_TIME Header linked to MDE mode in Annex A.3.7.2 <span>[<a href="#ATSCA331" class="xref">ATSCA331</a>]</span>
</td>
            <td class="text-left" rowspan="1" colspan="2">EXT_TIME Header may be used regardless (for FDT-Instance@Expires calculation)</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Codepoints</td>
            <td class="text-left" rowspan="1" colspan="1">Full set</td>
            <td class="text-left" rowspan="1" colspan="1">Does not specify range 11 - 255 (leaves to profiles)</td>
            <td class="text-left" rowspan="1" colspan="1">Restricted to 5 - 9</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Session metadata</td>
            <td class="text-left" rowspan="1" colspan="1">Full set</td>
            <td class="text-left" rowspan="1" colspan="1">Only defines a small subset of data necessary for setting up Source and                                                
      Repair Flows. Does not define format or encoding of data except if data is                                                              
      integral/alphanumerical. Leaves rest to profiles.</td>
            <td class="text-left" rowspan="1" colspan="1">Reuses A/331 metadata, duplicated from its own Service signaling.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="2" colspan="1">Extended FDT</td>
            <td class="text-left" rowspan="1" colspan="1">Instance shall not be sent with Source Flow</td>
            <td class="text-left" rowspan="1" colspan="1">Not restricted, may be restricted by a profile.</td>
            <td class="text-left" rowspan="1" colspan="1">Instance shall not be sent with Source Flow</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">No restriction</td>
            <td class="text-center" rowspan="1" colspan="2">Only allowed in File Mode</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Delivery Object Mode</td>
            <td class="text-center" rowspan="1" colspan="2">File, Entity, Signed/unsigned package</td>
            <td class="text-left" rowspan="1" colspan="1">Signed/unsigned package not allowed</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">Sender operation: Packetization</td>
            <td class="text-left" rowspan="1" colspan="1">Defined for DASH segment</td>
            <td class="text-center" rowspan="1" colspan="2">Defined for DASH segment and CMAF Chunks                                                                     
    </td>
          </tr>
          <tr>
            <td class="text-left" rowspan="2" colspan="1">Receiver object recovery</td>
            <td class="text-left" rowspan="1" colspan="1">Object handed to application upon complete reception</td>
            <td class="text-center" rowspan="1" colspan="2">Object may be handed before completion if MPD@availabilityTimeOffset signaled</td>
          </tr>
          <tr>
            <td class="text-center" rowspan="1" colspan="1">-</td>
            <td class="text-center" rowspan="1" colspan="2">Fast Stream acquisition guidelines provided</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<div id="sect-11">
<section id="section-11">
      <h2 id="name-security-and-privacy-consid">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-security-and-privacy-consid" class="section-name selfRef">Security and Privacy Considerations</a>
      </h2>
<div id="sect-11.1">
<section id="section-11.1">
        <h3 id="name-security-considerations">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
        </h3>
<p id="section-11.1-1">
   As noted in <a href="#sect-9" class="xref">Section 9</a>, ROUTE is aligned with
   FLUTE as specified in RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>
   and only diverges in certain signaling optimizations, especially for the
   real-time object delivery case. Hence, most of the security considerations
   documented in RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span> for the
   data flow itself, the session metadata (session control parameters in RFC
   6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>), and the associated
   building blocks apply directly to ROUTE as elaborated in the following
   along with some additional considerations.<a href="#section-11.1-1" class="pilcrow">¶</a></p>
<p id="section-11.1-2">
   Both encryption and integrity protection applied either on file or
   packet level, as recommended in the file corruption considerations of RFC
   6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>, <span class="bcp14">SHOULD</span> be used for ROUTE. Additionally, RFC 3740
   <span>[<a href="#RFC3740" class="xref">RFC3740</a>]</span> documents multicast security architecture in great detail
   with clear security recommendations that <span class="bcp14">SHOULD</span> be followed.<a href="#section-11.1-2" class="pilcrow">¶</a></p>
<p id="section-11.1-3">
   When ROUTE is carried over UDP and a reverse channel from receiver to
   sender is available, the security mechanisms provided in RFC 9147
   <span>[<a href="#RFC9147" class="xref">RFC9147</a>]</span> <span class="bcp14">SHOULD</span> be applied.<a href="#section-11.1-3" class="pilcrow">¶</a></p>
<p id="section-11.1-4">
   In regard to considerations for attacks against session description, this
   document does not specify the semantics or mechanism of delivery of session
   metadata, though the same threats apply for service using ROUTE as
   well. Hence, a service using ROUTE <span class="bcp14">SHOULD</span> take these threats
   into consideration and address them appropriately following the guidelines
   provided by RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>. Additionally, to the recommendations of RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span>, for Internet connected devices,
   services <span class="bcp14">SHOULD</span> enable clients to access the session
   description information using HTTPS with customary
   authentication/authorization, instead of sending this data via
   multicast/broadcast, since considerable security work has been done already
   in this unicast domain, which can enable highly secure access of session
   description data. Accessing via unicast, however, will have different privacy
   considerations, noted in <a href="#sect-11.2" class="xref">Section 11.2</a>. Note
   that in general the multicast/broadcast stream is delayed with respect to
   the unicast stream.  Therefore, the session description protocol
   <span class="bcp14">SHOULD</span> be time synchronized with the broadcast stream,
   particularly if the session description contains security-related
   information.<a href="#section-11.1-4" class="pilcrow">¶</a></p>
<p id="section-11.1-5">
   In regard to FDT, there is one key difference for File Mode when using File
   Template in EFDT, which avoids repeated sending of FDT-Instances and hence,
   the corresponding threats noted in RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span> do not apply directly to ROUTE in this case. The threat,
   however, is shifted to the ALC/LCT headers, since they carry the additional
   signaling that enables determining Content-Location and
   File@Transfer-Length in this case. Hence, integrity protection
   recommendations of ALC/LCT header <span class="bcp14">SHOULD</span> be considered with
   higher emphasis in this case for ROUTE.<a href="#section-11.1-5" class="pilcrow">¶</a></p>
<p id="section-11.1-6">
   Finally, attacks against the congestion control building block for
   the case of ROUTE can impact the optional fast stream acquisition
   specified in <a href="#sect-6.2" class="xref">Section 6.2</a>. Receivers <span class="bcp14">SHOULD</span> have robustness against
   timestamp values that are suspicious, e.g., by comparing the signaled
   time in the LCT headers with the approximate time signaled by the
   MPD, and <span class="bcp14">SHOULD</span> discard outlying values. Additionally, receivers <span class="bcp14">MUST</span>
   adhere to the expiry timelines as specified in <a href="#sect-6" class="xref">Section 6</a>. Integrity
   protection mechanisms documented in RFC 6726 <span>[<a href="#RFC6726" class="xref">RFC6726</a>]</span> <span class="bcp14">SHOULD</span> be used
   to address this threat.<a href="#section-11.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-11.2">
<section id="section-11.2">
        <h3 id="name-privacy-considerations">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
        </h3>
<p id="section-11.2-1">
   Encryption mechanisms recommended for security considerations in
   <a href="#sect-11.1" class="xref">Section 11.1</a> <span class="bcp14">SHOULD</span> also be applied to enable privacy and protection
   from snooping attacks.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
<p id="section-11.2-2">
   Since this protocol is primarily targeted for IP multicast/broadcast
   environments where the end user is mostly listening, identity
   protection and user data retention considerations are more protected
   than in the unicast case. Best practices for enabling privacy on IP
   multicast/broadcast <span class="bcp14">SHOULD</span> be applied by the operators, e.g.,
   "<a href="#RFC8932" class="xref">Recommendations for DNS Privacy Service Operators</a>" in RFC 8932
   <span>[<a href="#RFC8932" class="xref">RFC8932</a>]</span>.<a href="#section-11.2-2" class="pilcrow">¶</a></p>
<p id="section-11.2-3">
   However, if clients access session description information via HTTPS,
   the same privacy considerations and solutions <span class="bcp14">SHALL</span> apply to this
   access as for regular HTTPS communication, an area that is very well
   studied and the concepts of which are being integrated directly into
   newer transport protocols such as IETF QUIC <span>[<a href="#RFC9000" class="xref">RFC9000</a>]</span> enabling HTTP/3
   <span>[<a href="#I-D.ietf-quic-http" class="xref">HTTP3</a>]</span>. Hence, such newer protocols <span class="bcp14">SHOULD</span> be used to foster privacy.<a href="#section-11.2-3" class="pilcrow">¶</a></p>
<p id="section-11.2-4">
   Note that streaming services <span class="bcp14">MAY</span> contain content that may only be
   accessed via DRM (digital rights management) systems.  DRM systems
   can prevent unauthorized access to content delivered via ROUTE.<a href="#section-11.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-12">
<section id="section-12">
      <h2 id="name-iana-considerations">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-12-1">This document has no IANA actions.<a href="#section-12-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-13">
      <h2 id="name-references">
<a href="#section-13" class="section-number selfRef">13. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-13.1">
        <h3 id="name-normative-references">
<a href="#section-13.1" class="section-number selfRef">13.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="ATSCA331">[ATSCA331]</dt>
        <dd>
<span class="refAuthor">Advanced Television Systems Committee</span>, <span class="refTitle">"Signaling, Delivery, Synchronization, and Error Protection"</span>, <span class="seriesInfo">ATSC Standard A/331:2022-03</span>, <time datetime="2022-03" class="refDate">March 2022</time>. </dd>
<dd class="break"></dd>
<dt id="RFC1952">[RFC1952]</dt>
        <dd>
<span class="refAuthor">Deutsch, P.</span>, <span class="refTitle">"GZIP file format specification version 4.3"</span>, <span class="seriesInfo">RFC 1952</span>, <span class="seriesInfo">DOI 10.17487/RFC1952</span>, <time datetime="1996-05" class="refDate">May 1996</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc1952">https://www.rfc-editor.org/info/rfc1952</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="RFC2557">[RFC2557]</dt>
        <dd>
<span class="refAuthor">Palme, J.</span>, <span class="refAuthor">Hopmann, A.</span>, and <span class="refAuthor">N. Shelness</span>, <span class="refTitle">"MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)"</span>, <span class="seriesInfo">RFC 2557</span>, <span class="seriesInfo">DOI 10.17487/RFC2557</span>, <time datetime="1999-03" class="refDate">March 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2557">https://www.rfc-editor.org/info/rfc2557</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Fielding, R.</span>, and <span class="refAuthor">L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5052">[RFC5052]</dt>
        <dd>
<span class="refAuthor">Watson, M.</span>, <span class="refAuthor">Luby, M.</span>, and <span class="refAuthor">L. Vicisano</span>, <span class="refTitle">"Forward Error Correction (FEC) Building Block"</span>, <span class="seriesInfo">RFC 5052</span>, <span class="seriesInfo">DOI 10.17487/RFC5052</span>, <time datetime="2007-08" class="refDate">August 2007</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5052">https://www.rfc-editor.org/info/rfc5052</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5445">[RFC5445]</dt>
        <dd>
<span class="refAuthor">Watson, M.</span>, <span class="refTitle">"Basic Forward Error Correction (FEC) Schemes"</span>, <span class="seriesInfo">RFC 5445</span>, <span class="seriesInfo">DOI 10.17487/RFC5445</span>, <time datetime="2009-03" class="refDate">March 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5445">https://www.rfc-editor.org/info/rfc5445</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5651">[RFC5651]</dt>
        <dd>
<span class="refAuthor">Luby, M.</span>, <span class="refAuthor">Watson, M.</span>, and <span class="refAuthor">L. Vicisano</span>, <span class="refTitle">"Layered Coding Transport (LCT) Building Block"</span>, <span class="seriesInfo">RFC 5651</span>, <span class="seriesInfo">DOI 10.17487/RFC5651</span>, <time datetime="2009-10" class="refDate">October 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5651">https://www.rfc-editor.org/info/rfc5651</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5775">[RFC5775]</dt>
        <dd>
<span class="refAuthor">Luby, M.</span>, <span class="refAuthor">Watson, M.</span>, and <span class="refAuthor">L. Vicisano</span>, <span class="refTitle">"Asynchronous Layered Coding (ALC) Protocol Instantiation"</span>, <span class="seriesInfo">RFC 5775</span>, <span class="seriesInfo">DOI 10.17487/RFC5775</span>, <time datetime="2010-04" class="refDate">April 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5775">https://www.rfc-editor.org/info/rfc5775</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6330">[RFC6330]</dt>
        <dd>
<span class="refAuthor">Luby, M.</span>, <span class="refAuthor">Shokrollahi, A.</span>, <span class="refAuthor">Watson, M.</span>, <span class="refAuthor">Stockhammer, T.</span>, and <span class="refAuthor">L. Minder</span>, <span class="refTitle">"RaptorQ Forward Error Correction Scheme for Object Delivery"</span>, <span class="seriesInfo">RFC 6330</span>, <span class="seriesInfo">DOI 10.17487/RFC6330</span>, <time datetime="2011-08" class="refDate">August 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6330">https://www.rfc-editor.org/info/rfc6330</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6363">[RFC6363]</dt>
        <dd>
<span class="refAuthor">Watson, M.</span>, <span class="refAuthor">Begen, A.</span>, and <span class="refAuthor">V. Roca</span>, <span class="refTitle">"Forward Error Correction (FEC) Framework"</span>, <span class="seriesInfo">RFC 6363</span>, <span class="seriesInfo">DOI 10.17487/RFC6363</span>, <time datetime="2011-10" class="refDate">October 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6363">https://www.rfc-editor.org/info/rfc6363</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6726">[RFC6726]</dt>
        <dd>
<span class="refAuthor">Paila, T.</span>, <span class="refAuthor">Walsh, R.</span>, <span class="refAuthor">Luby, M.</span>, <span class="refAuthor">Roca, V.</span>, and <span class="refAuthor">R. Lehtonen</span>, <span class="refTitle">"FLUTE - File Delivery over Unidirectional Transport"</span>, <span class="seriesInfo">RFC 6726</span>, <span class="seriesInfo">DOI 10.17487/RFC6726</span>, <time datetime="2012-11" class="refDate">November 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6726">https://www.rfc-editor.org/info/rfc6726</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7231">[RFC7231]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span> and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"</span>, <span class="seriesInfo">RFC 7231</span>, <span class="seriesInfo">DOI 10.17487/RFC7231</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</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="RFC8551">[RFC8551]</dt>
      <dd>
<span class="refAuthor">Schaad, J.</span>, <span class="refAuthor">Ramsdell, B.</span>, and <span class="refAuthor">S. Turner</span>, <span class="refTitle">"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification"</span>, <span class="seriesInfo">RFC 8551</span>, <span class="seriesInfo">DOI 10.17487/RFC8551</span>, <time datetime="2019-04" class="refDate">April 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8551">https://www.rfc-editor.org/info/rfc8551</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-13.2">
        <h3 id="name-informative-references">
<a href="#section-13.2" class="section-number selfRef">13.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CMAF">[CMAF]</dt>
        <dd>
<span class="refAuthor">International Organization for Standardization</span>, <span class="refTitle">"Information technology -- Multimedia application format (MPEG-A) -- Part 19: Common media application format (CMAF) for segmented media"</span>, <span class="refContent">First edition</span>, <span class="seriesInfo">ISO/IEC FDIS 23000-19</span>, <time datetime="2018-01" class="refDate">January 2018</time>, <span>&lt;<a href="https://www.iso.org/standard/71975.html">https://www.iso.org/standard/71975.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DASH">[DASH]</dt>
        <dd>
<span class="refAuthor">International Organization for Standardization</span>, <span class="refTitle">"Information technology - Dynamic adaptive streaming over HTTP (DASH) - Part 1: Media presentation description and segment formats"</span>, <span class="refContent">Fourth edition</span>, <span class="seriesInfo">ISO/IEC 23009-1:2019</span>, <time datetime="2019-12" class="refDate">December 2019</time>, <span>&lt;<a href="https://www.iso.org/standard/79329.html">https://www.iso.org/standard/79329.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="DVBMABR">[DVBMABR]</dt>
        <dd>
<span class="refAuthor">ETSI</span>, <span class="refTitle">"Digital Video Broadcasting (DVB); Adaptive media streaming over IP multicast"</span>, <span class="refContent">version 1.1.1</span>, <span class="seriesInfo">ETSI TS 103 769</span>, <time datetime="2020-11" class="refDate">November 2020</time>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-quic-http">[HTTP3]</dt>
        <dd>
<span class="refAuthor">Bishop, M., Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol Version 3 (HTTP/3)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-quic-http-34</span>, <time datetime="2021-02-02" class="refDate">2 February 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34">https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-34</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MBMS">[MBMS]</dt>
        <dd>
<span class="refAuthor">ETSI</span>, <span class="refTitle">"Universal Mobile Telecommunications Systems (UMTS); LTE; 5G; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs"</span>, <span class="refContent">version 16.9.1</span>, <span class="seriesInfo">ETSI TS 126 346</span>, <time datetime="2021-05" class="refDate">May 2021</time>. </dd>
<dd class="break"></dd>
<dt id="RFC3740">[RFC3740]</dt>
        <dd>
<span class="refAuthor">Hardjono, T.</span> and <span class="refAuthor">B. Weis</span>, <span class="refTitle">"The Multicast Group Security Architecture"</span>, <span class="seriesInfo">RFC 3740</span>, <span class="seriesInfo">DOI 10.17487/RFC3740</span>, <time datetime="2004-03" class="refDate">March 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3740">https://www.rfc-editor.org/info/rfc3740</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6968">[RFC6968]</dt>
        <dd>
<span class="refAuthor">Roca, V.</span> and <span class="refAuthor">B. Adamson</span>, <span class="refTitle">"FCAST: Object Delivery for the Asynchronous Layered Coding (ALC) and NACK-Oriented Reliable Multicast (NORM) Protocols"</span>, <span class="seriesInfo">RFC 6968</span>, <span class="seriesInfo">DOI 10.17487/RFC6968</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6968">https://www.rfc-editor.org/info/rfc6968</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8932">[RFC8932]</dt>
        <dd>
<span class="refAuthor">Dickinson, S.</span>, <span class="refAuthor">Overeinder, B.</span>, <span class="refAuthor">van Rijswijk-Deij, R.</span>, and <span class="refAuthor">A. Mankin</span>, <span class="refTitle">"Recommendations for DNS Privacy Service Operators"</span>, <span class="seriesInfo">BCP 232</span>, <span class="seriesInfo">RFC 8932</span>, <span class="seriesInfo">DOI 10.17487/RFC8932</span>, <time datetime="2020-10" class="refDate">October 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8932">https://www.rfc-editor.org/info/rfc8932</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9000">[RFC9000]</dt>
        <dd>
<span class="refAuthor">Iyengar, J., Ed.</span> and <span class="refAuthor">M. Thomson, Ed.</span>, <span class="refTitle">"QUIC: A UDP-Based Multiplexed and Secure Transport"</span>, <span class="seriesInfo">RFC 9000</span>, <span class="seriesInfo">DOI 10.17487/RFC9000</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9000">https://www.rfc-editor.org/info/rfc9000</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9147">[RFC9147]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 9147</span>, <span class="seriesInfo">DOI 10.17487/RFC9147</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9147">https://www.rfc-editor.org/info/rfc9147</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="sect-14">
<section id="appendix-A">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-A-1">
   As outlined in the introduction and in ROUTE concepts in <a href="#sect-9" class="xref">Section 9</a>,
   the concepts specified in this document are the culmination of the
   collaborative work of several experts and organizations over the
   years. The authors would especially like to acknowledge the work and
   efforts of the following people and organizations to help realize the
   technologies described in this document (in no specific order): <span class="contact-name">Mike    Luby</span>, <span class="contact-name">Kent Walker</span>, <span class="contact-name">Charles Lo</span>, and other colleagues from Qualcomm
   Incorporated, LG Electronics, Nomor Research, Sony, and BBC R&amp;D.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Waqar Zia</span></div>
<div dir="auto" class="left"><span class="org">Qualcomm CDMA Technologies GmbH</span></div>
<div dir="auto" class="left"><span class="street-address">Anzinger Str. 13</span></div>
<div dir="auto" class="left">
<span class="postal-code">81671</span> <span class="locality">Munich</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:wzia@qti.qualcomm.com" class="email">wzia@qti.qualcomm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Thomas Stockhammer</span></div>
<div dir="auto" class="left"><span class="org">Qualcomm CDMA Technologies GmbH</span></div>
<div dir="auto" class="left"><span class="street-address">Anzinger Str. 13</span></div>
<div dir="auto" class="left">
<span class="postal-code">81671</span> <span class="locality">Munich</span>
</div>
<div dir="auto" class="left"><span class="country-name">Germany</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tsto@qti.qualcomm.com" class="email">tsto@qti.qualcomm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Lenaig Chaponniere</span></div>
<div dir="auto" class="left"><span class="org">Qualcomm Technologies Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">5775 Morehouse Drive</span></div>
<div dir="auto" class="left">
<span class="locality">San Diego</span>, <span class="region">CA</span> <span class="postal-code">92121</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:lguellec@qti.qualcomm.com" class="email">lguellec@qti.qualcomm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Giridhar Mandyam</span></div>
<div dir="auto" class="left"><span class="org">Qualcomm Technologies Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">5775 Morehouse Drive</span></div>
<div dir="auto" class="left">
<span class="locality">San Diego</span>, <span class="region">CA</span> <span class="postal-code">92121</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mandyam@qti.qualcomm.com" class="email">mandyam@qti.qualcomm.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Michael Luby</span></div>
<div dir="auto" class="left"><span class="org">BitRipple, Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">1133 Miller Ave</span></div>
<div dir="auto" class="left">
<span class="locality">Berkeley</span>, <span class="region">CA</span> <span class="postal-code">94708</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:luby@bitripple.com" class="email">luby@bitripple.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>