File: rfc9188.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 (2343 lines) | stat: -rw-r--r-- 97,725 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 9188: Generic Multi-Access (GMA) Encapsulation Protocol</title>
<meta content="Jing Zhu" name="author">
<meta content="Satish Kanugovi" name="author">
<meta content="
       
   A device can be simultaneously connected to multiple networks, e.g., Wi-Fi,
   LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity
   over these networks below the transport layer (L4) to improve the quality
   of experience for applications that do not have built-in multi-path
   capabilities. Such optimization requires additional control information,
   e.g., a sequence number, in each packet. This document presents a new
   lightweight and flexible encapsulation protocol for this need. The solution
   has been developed by the authors based on their experiences in multiple
   standards bodies including the IETF and 3GPP. However, this document is not
   an Internet Standard and does not represent the consensus opinion of
   the IETF. This document will enable other developers to build interoperable
   implementations in order to experiment with the protocol. 
    " name="description">
<meta content="xml2rfc 3.12.1" name="generator">
<meta content="9188" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.1
    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="rfc9188.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/rfc9188" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-zhu-intarea-gma-14" 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 9188</td>
<td class="center">GMA Encapsulation Protocol</td>
<td class="right">February 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Zhu &amp; Kanugovi</td>
<td class="center">Experimental</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/rfc9188" class="eref">9188</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-02" class="published">February 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">J. Zhu</div>
<div class="org">Intel</div>
</div>
<div class="author">
      <div class="author-name">S. Kanugovi</div>
<div class="org">Nokia</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9188</h1>
<h1 id="title">Generic Multi-Access (GMA) Encapsulation Protocol</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
   A device can be simultaneously connected to multiple networks, e.g., Wi-Fi,
   LTE, 5G, and DSL. It is desirable to seamlessly combine the connectivity
   over these networks below the transport layer (L4) to improve the quality
   of experience for applications that do not have built-in multi-path
   capabilities. Such optimization requires additional control information,
   e.g., a sequence number, in each packet. This document presents a new
   lightweight and flexible encapsulation protocol for this need. The solution
   has been developed by the authors based on their experiences in multiple
   standards bodies including the IETF and 3GPP. However, this document is not
   an Internet Standard and does not represent the consensus opinion of
   the IETF. This document will enable other developers to build interoperable
   implementations in order to experiment with the protocol.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document defines an Experimental Protocol for the Internet
            community.  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/rfc9188">https://www.rfc-editor.org/info/rfc9188</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" class="keepWithNext"><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-scope-of-experiment" class="xref">Scope of Experiment</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" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-used-in-this-do" class="xref">Conventions Used in This Document</a></p>
</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-use-case" class="xref">Use Case</a></p>
</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-gma-encapsulation-methods" class="xref">GMA Encapsulation Methods</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-trailer-based-ip-encapsulat" class="xref">Trailer-Based IP Encapsulation</a></p>
</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-header-based-ip-encapsulati" class="xref">Header-Based IP Encapsulation</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-header-based-non-ip-encapsu" class="xref">Header-Based Non-IP Encapsulation</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-ip-protocol-identifier" class="xref">IP Protocol Identifier</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-fragmentation" class="xref">Fragmentation</a></p>
</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-concatenation" class="xref">Concatenation</a></p>
</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-security-considerations" class="xref">Security Considerations</a></p>
</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-iana-considerations" class="xref">IANA Considerations</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-references" class="xref">References</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-normative-references" class="xref">Normative References</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-informative-references" class="xref">Informative References</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="#appendix-A" 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>
<p id="section-1-1">
   A device can be simultaneously connected to multiple networks,
   e.g., Wi-Fi, LTE, 5G, and DSL. It is desirable to seamlessly
   combine the connectivity over these networks below the transport
   layer (L4) to improve the quality of experience for applications that
   do not have built-in multi-path capabilities.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
   <a href="#Fig1" class="xref">Figure 1</a> shows the Multi-Access Management Service (MAMS) user-plane
   protocol stack <span>[<a href="#RFC8743" class="xref">MAMS</a>]</span>, which has been used in today's
   multi-access solutions <span>[<a href="#ATSSS" class="xref">ATSSS</a>]</span> <span>[<a href="#LWIPEP" class="xref">LWIPEP</a>]</span> <span>[<a href="#RFC2890" class="xref">GRE1</a>]</span> <span>[<a href="#RFC8157" class="xref">GRE2</a>]</span>. It
   consists of two layers: convergence and adaptation.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
   The convergence layer is responsible for multi-access operations, including
   multi-link (path) aggregation, splitting/reordering, lossless
   switching/retransmission, fragmentation, concatenation, etc. It operates on
   top of the adaptation layer in the protocol stack. From the perspective of
   a transmitter, a User Payload (e.g., IP packet) is processed by the
   convergence layer first and then by the adaptation layer before being
   transported over a delivery connection; from the receiver's perspective, an
   IP packet received over a delivery connection is processed by the
   adaptation layer first and then by the convergence layer.<a href="#section-1-3" class="pilcrow">¶</a></p>
<span id="name-mams-user-plane-protocol-st"></span><div id="Fig1">
<figure id="figure-1">
        <div class="alignLeft art-text artwork" id="section-1-4.1">
<pre>
       +-----------------------------------------------------+
       |   User Payload, e.g., IP Protocol Data Unit (PDU)   |
       +-----------------------------------------------------+
    +-----------------------------------------------------------+
    |  +-----------------------------------------------------+  |
    |  | Multi-Access (MX) Convergence Layer                 |  |
    |  +-----------------------------------------------------+  |
    |  +-----------------------------------------------------+  |
    |  | MX Adaptation   | MX Adaptation   | MX Adaptation   |  |
    |  | Layer           | Layer           | Layer           |  |
    |  +-----------------+-----------------+-----------------+  |
    |  | Access #1 IP    | Access #2 IP    | Access #3 IP    |  |
    |  +-----------------------------------------------------+  |
    |                            MAMS User-Plane Protocol Stack |
    +-----------------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-mams-user-plane-protocol-st" class="selfRef">MAMS User-Plane Protocol Stack</a>
        </figcaption></figure>
</div>
<p id="section-1-5">
   GRE (Generic Routing Encapsulation) <span>[<a href="#LWIPEP" class="xref">LWIPEP</a>]</span> <span>[<a href="#RFC2890" class="xref">GRE1</a>]</span> <span>[<a href="#RFC8157" class="xref">GRE2</a>]</span> can be used as
   the encapsulation protocol at the convergence layer to encode additional
   control information, e.g., key and sequence number.  However, there are two
   main drawbacks with this approach:<a href="#section-1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-6.1">It is difficult to introduce new control fields because the
     GRE header formats are already defined, and<a href="#section-1-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.2">IP-over-IP tunneling (required for GRE) leads to higher
     overhead especially for small packets.<a href="#section-1-6.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-7">
   For example, the overhead of IP-over-IP/GRE tunneling with both
   key and sequence Number is 32 bytes (20-byte IP header + 12-byte
   GRE header), which is 80% of a 40-byte TCP ACK packet.<a href="#section-1-7" class="pilcrow">¶</a></p>
<p id="section-1-8">
   This document presents a lightweight Generic Multi-Access (GMA)
   encapsulation protocol for the convergence layer. It supports three
   encapsulation methods: trailer-based IP encapsulation, header-based IP
   encapsulation, and non-IP encapsulation.  Particularly, the IP
   encapsulation methods avoid IP-over-IP tunneling overhead (20 bytes), which
   is 50% of a 40-byte TCP ACK packet. Moreover, it introduces new control
   fields to support fragmentation and concatenation, which are not available
   in GRE-based solutions <span>[<a href="#LWIPEP" class="xref">LWIPEP</a>]</span> <span>[<a href="#RFC2890" class="xref">GRE1</a>]</span> <span>[<a href="#RFC8157" class="xref">GRE2</a>]</span>.<a href="#section-1-8" class="pilcrow">¶</a></p>
<p id="section-1-9">
   The GMA protocol only operates between endpoints that have been configured
   to use GMA. This configuration can be through any control messages and
   procedures, including, for example, Multi-Access Management Services <span>[<a href="#RFC8743" class="xref">MAMS</a>]</span>. Moreover, UDP or IPsec tunneling can
   be used at the adaptation sublayer to protect GMA operation from
   intermediate nodes.<a href="#section-1-9" class="pilcrow">¶</a></p>
<p id="section-1-10">
   The solution described in this document was developed by the authors based
   on their experiences in multiple standards bodies including the IETF and
   3GPP. However, this document is not an Internet Standard and does not
   represent the consensus opinion of the IETF.  This document presents the
   protocol specification to enable experimentation as described in <a href="#sect-1.1" class="xref">Section 1.1</a> and to facilitate other interoperable
   implementations.<a href="#section-1-10" class="pilcrow">¶</a></p>
<div id="sect-1.1">
<section id="section-1.1">
        <h3 id="name-scope-of-experiment">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-scope-of-experiment" class="section-name selfRef">Scope of Experiment</a>
        </h3>
<p id="section-1.1-1">
   The protocol described in this document is an experiment. The
   objective of the experiment is to determine whether the protocol
   meets the requirements, can be safely used, and has support for
   deployment.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
<p id="section-1.1-2">
   <a href="#sect-4" class="xref">Section 4</a> describes three possible encapsulation methods that are
   enabled by this protocol. Part of this experiment is to assess
   whether all three mechanisms are necessary or whether, for
   example, all implementations are able to support the main
   "trailer-based" IP encapsulation method. Similarly, the experiment
   will investigate the relative merits of the IP and non-IP
   encapsulation methods.<a href="#section-1.1-2" class="pilcrow">¶</a></p>
<p id="section-1.1-3">
   It is expected that this protocol experiment can be conducted on the
   Internet since the GMA packets are identified by an IP protocol number and
   the protocol is intended for single-hop propagation; devices should not be
   forwarding packets, and if they do, they will not need to examine the payload,
   while destination systems that do not support this protocol should not
   receive such packets and will handle them as unknown payloads according to
   normal IP processing. Thus, experimentation is conducted between consenting
   end systems that have been mutually configured to participate in the
   experiment as described in <a href="#sect-7" class="xref">Section 7</a>.<a href="#section-1.1-3" class="pilcrow">¶</a></p>
<p id="section-1.1-4">
   Note that this experiment "reuses" the IP protocol identifier 114
   as described in <a href="#sect-4.4" class="xref">Section 4.4</a>. Part of this experiment is to assess
   the safety of doing this. The experiment should consider the
   following safety mechanisms:<a href="#section-1.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.1-5.1">GMA endpoints <span class="bcp14">SHOULD</span> detect non-GMA IP packets that also use
     114 and log an error to report the situation (although such
     error logging <span class="bcp14">MUST</span> be subject to rate limits).<a href="#section-1.1-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.1-5.2">GMA endpoints <span class="bcp14">SHOULD</span> stop using 114 and switch to non-IP encapsulation,
i.e., UDP encapsulation (<a href="#Fig7" class="xref">Figure 7</a>), after detecting any non-GMA usage of 114.<a href="#section-1.1-5.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-1.1-6">
   The experiment <span class="bcp14">SHOULD</span> use a packet tracing tool, e.g.,
   WireShark or TCPDUMP, to monitor both ingress and egress traffic at GMA
   endpoints and ensure the above safety mechanisms are implemented.<a href="#section-1.1-6" class="pilcrow">¶</a></p>
<p id="section-1.1-7">
   Path quality measurements (one-way delay, loss, etc.) and congestion
   detection are performed by the receiver based on the GMA control fields,
   e.g., Sequence Number, Timestamp, etc. The receiver will then dynamically
   control how to split or steer traffic over multiple delivery connections
   accordingly. The GMA control protocol <span>[<a href="#I-D.zhu-intarea-gma-control" class="xref">GMAC</a>]</span> <span class="bcp14">MAY</span>
   be used for signaling between GMA endpoints. Another objective of the
   experiment is to evaluate the usage of various receiver-based algorithms
   <span>[<a href="#GCC" class="xref">GCC</a>]</span> <span>[<a href="#MPIP" class="xref">MPIP</a>]</span>
   in multi-path traffic management and the impact on the End-to-End (E2E)
   performance (throughput, delay, etc.) of higher-layer (transport)
   protocols, e.g., TCP, QUIC, WebRTC, etc.<a href="#section-1.1-7" class="pilcrow">¶</a></p>
<p id="section-1.1-8">
   The authors will continually assess the progress of this
   experiment and encourage other implementers to contact them to
   report the status of their implementations and their experiences
   with the protocol.<a href="#section-1.1-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-2">
<section id="section-2">
      <h2 id="name-conventions-used-in-this-do">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-used-in-this-do" class="section-name selfRef">Conventions Used in This Document</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
        <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-3">
<section id="section-3">
      <h2 id="name-use-case">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-use-case" class="section-name selfRef">Use Case</a>
      </h2>
<p id="section-3-1">
   As shown in <a href="#Fig2" class="xref">Figure 2</a>, a client device (e.g., smartphone,
   laptop, etc.) may connect to the Internet via both Wi-Fi and LTE
   connections, one of which (e.g., LTE) may operate as the anchor connection,
   and the other (e.g., Wi-Fi) may operate as the delivery connection. The
   anchor connection provides the IP address and connectivity for end-to-end
   Internet access, and the delivery connection provides an additional path
   between the client and Multi-Access Gateway for multi-access optimizations.<a href="#section-3-1" class="pilcrow">¶</a></p>
<span id="name-gma-based-multi-access-aggr"></span><div id="Fig2">
<figure id="figure-2">
        <div class="alignLeft art-text artwork" id="section-3-2.1">
<pre>
                     Multi-Access Aggregation

                 +---+                        +---+
                 | |A|--- LTE Connection -----|C| |
                 |U|-|                        |-|S| Internet
                 | |B|--- Wi-Fi Connection ---|D| |
                 +---+                        +---+
                client                Multi-Access Gateway
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-gma-based-multi-access-aggr" class="selfRef">GMA-Based Multi-Access Aggregation</a>
        </figcaption></figure>
</div>
<span class="break"></span><dl class="dlParallel" id="section-3-3">
        <dt id="section-3-3.1">A:</dt>
        <dd style="margin-left: 2.0em" id="section-3-3.2"> The adaptation-layer endpoint of the LTE connection
 resides in the client.<a href="#section-3-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.3">B:</dt>
        <dd style="margin-left: 2.0em" id="section-3-3.4"> The adaptation-layer endpoint of the Wi-Fi connection
 resides in the client.<a href="#section-3-3.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.5">C:</dt>
        <dd style="margin-left: 2.0em" id="section-3-3.6"> The adaptation-layer endpoint of the LTE connection
 resides in the Multi-Access Gateway, aka N-MADP (Network
 Multi-Access Data Proxy) in <span>[<a href="#RFC8743" class="xref">MAMS</a>]</span>.<a href="#section-3-3.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.7">D:</dt>
        <dd style="margin-left: 2.0em" id="section-3-3.8"> The adaptation-layer endpoint of the Wi-Fi connection
 resides in the Multi-Access Gateway.<a href="#section-3-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.9">U:</dt>
        <dd style="margin-left: 2.0em" id="section-3-3.10"> The convergence-layer endpoint resides in the client.<a href="#section-3-3.10" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-3-3.11">S:</dt>
        <dd style="margin-left: 2.0em" id="section-3-3.12"> The convergence-layer endpoint resides in the Multi-Access
 Gateway.<a href="#section-3-3.12" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-3-4">
   For example, per-packet aggregation allows a single IP flow to use the
   combined bandwidth of the two connections. In another example, packets lost
   due to a temporary link outage may be retransmitted. Moreover, packets may
   be duplicated over multiple connections to achieve high reliability and low
   latency, where duplicated packets are eliminated by the receiving
   side. Such multi-access optimization requires additional control
   information, e.g., a sequence number, in each packet, which can be
   supported by the GMA encapsulation protocol described in this document.<a href="#section-3-4" class="pilcrow">¶</a></p>
<p id="section-3-5">
   The GMA protocol described in this document is designed for multiple
   connections, but it may also be used when there is only one connection
   between two endpoints. For example, it may be used for loss detection and
   recovery. In another example, it may be used to concatenate multiple small
   packets and reduce per-packet overhead.<a href="#section-3-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-4">
<section id="section-4">
      <h2 id="name-gma-encapsulation-methods">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-gma-encapsulation-methods" class="section-name selfRef">GMA Encapsulation Methods</a>
      </h2>
<p id="section-4-1">
   The GMA encapsulation protocol supports the following three
   methods:<a href="#section-4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-2.1">Trailer-based IP Encapsulation (<a href="#sect-4.1" class="xref">Section 4.1</a>)<a href="#section-4-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-2.2">Header-based IP Encapsulation (<a href="#sect-4.2" class="xref">Section 4.2</a>)<a href="#section-4-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-2.3">Header-based non-IP Encapsulation (<a href="#sect-4.3" class="xref">Section 4.3</a>)<a href="#section-4-2.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-3">
   Non-IP encapsulation <span class="bcp14">MUST</span> be used if the original IP packet is
   IPv6.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
   Trailer-based IP encapsulation <span class="bcp14">MUST</span> be used if it is supported by
   GMA endpoints and the original IP packet is IPv4.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
   Header-based encapsulation <span class="bcp14">MUST</span> be used if the trailer-based
   method is not supported by either the client or Multi-Access Gateway.
   In this case, if the adaptation layer, e.g., UDP tunneling,
   supports non-IP packet format, non-IP encapsulation <span class="bcp14">MUST</span> be used;
   otherwise, header-based IP encapsulation <span class="bcp14">MUST</span> be used.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
   If non-IP encapsulation is configured, a GMA header <span class="bcp14">MUST</span> be
   present in every packet. In comparison, if IP encapsulation is configured,
   a GMA header or trailer may be added dynamically on a per-packet basis, and
   it indicates the presence of a GMA header (or trailer) to set the protocol
   type of the GMA PDU to "114" (see <a href="#sect-4.4" class="xref">Section 4.4</a>).<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">
   The GMA endpoints <span class="bcp14">MAY</span> configure the GMA encapsulation method through
   control signaling or pre-configuration. For example, the "MX UP Setup
   Configuration Request" message as specified in Multi-Access Management
   Service <span>[<a href="#RFC8743" class="xref">MAMS</a>]</span> includes "MX Convergence Method Parameters",
   which provides the list of parameters to configure the convergence layer,
   and can be extended to indicate the GMA encapsulation method.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">
   GMA endpoint <span class="bcp14">MUST</span> discard a received packet and <span class="bcp14">MAY</span> log an error
   to report the situation (although such error logging <span class="bcp14">MUST</span> be
   subject to rate limits) under any of the following conditions:<a href="#section-4-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-9.1">The GMA version number in the GMA header (or trailer) is not
     understood or supported by the GMA endpoint.<a href="#section-4-9.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-9.2">A flag bit in the GMA header (or trailer) not understood or
     supported by the GMA endpoint is set to "1".<a href="#section-4-9.2" class="pilcrow">¶</a>
</li>
      </ul>
<div id="sect-4.1">
<section id="section-4.1">
        <h3 id="name-trailer-based-ip-encapsulat">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-trailer-based-ip-encapsulat" class="section-name selfRef">Trailer-Based IP Encapsulation</a>
        </h3>
<span id="name-gma-pdu-format-with-trailer"></span><div id="Fig3">
<figure id="figure-3">
          <div class="alignLeft art-text artwork" id="section-4.1-1.1">
<pre>
       |&lt;---------------------GMA PDU -----------------------&gt;|
       +------------------------------------------------------+
       | IP hdr |        IP payload             | GMA Trailer |
       +------------------------------------------------------+
       |&lt;------- GMA SDU (user payload)--------&gt;|
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-gma-pdu-format-with-trailer" class="selfRef">GMA PDU Format with Trailer-based IP Encapsulation</a>
          </figcaption></figure>
</div>
<p id="section-4.1-2">
   This method <span class="bcp14">SHALL NOT</span> be used if the original IP packet (GMA
   service data unit (GMA SDU)) is IPv6.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">
   <a href="#Fig3" class="xref">Figure 3</a> shows the trailer-based IP encapsulation GMA protocol
   data unit (GMA PDU) format. A (GMA) PDU may carry one or multiple IP
   packets, aka (GMA) SDUs, in the payload, or a fragment of the SDU.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">
   The protocol type field in the IP header of the GMA PDU <span class="bcp14">MUST</span> be
   changed to 114 (Any 0-Hop Protocol) (see <a href="#sect-4.4" class="xref">Section 4.4</a>) to indicate
   the presence of the GMA trailer.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">
   The following three IP header fields <span class="bcp14">MUST</span> be changed:<a href="#section-4.1-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-6">
          <dt id="section-4.1-6.1">IP Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-6.2"> Add the length of "GMA Trailer" to the length of the
     original IP packet.<a href="#section-4.1-6.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-6.3">Time To Live (TTL):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-6.4"> Set to "1".<a href="#section-4.1-6.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-6.5">IP checksum:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-6.6"> Recalculate after changing "protocol
          type", "TTL", and "IP Length".<a href="#section-4.1-6.6" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.1-7">
   The GMA (Generic Multi-Access) trailer <span class="bcp14">MUST</span> consist of two
   mandatory fields (the last 3 bytes): Next Header and Flags.<a href="#section-4.1-7" class="pilcrow">¶</a></p>
<p id="section-4.1-8">
   This is defined as follows:<a href="#section-4.1-8" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-9">
          <dt id="section-4.1-9.1">Next Header (1 byte):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-9.2"> This is the IP protocol type of the (first) SDU
     in a PDU; it stores the value before it was overwritten to
     114.<a href="#section-4.1-9.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-9.3">Flags (2 bytes):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-9.4">
            <p id="section-4.1-9.4.1"> Bit 0 is the most significant bit (MSB), and
     bit 15 is the least significant bit (LSB).<a href="#section-4.1-9.4.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-9.4.2">
              <dt id="section-4.1-9.4.2.1">Checksum Present (bit 0):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.2"> If the Checksum Present
              bit is set to 1, then the Checksum field is present.<a href="#section-4.1-9.4.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.3">Concatenation Present (bit 1):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.4"> If the Concatenation
              Present bit is set to 1, then the PDU carries multiple SDUs, and
              the First SDU Length field is present.<a href="#section-4.1-9.4.2.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.5">Connection ID Present (bit 2):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.6"> If the Connection ID
              Present bit is set to 1, then the Connection ID field is
              present.<a href="#section-4.1-9.4.2.6" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.7">Flow ID Present (bit 3):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.8"> If the Flow ID Present bit
              is set to 1, then the Flow ID field is present.<a href="#section-4.1-9.4.2.8" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.9">Fragmentation Present (bit 4):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.10">If the Fragmentation
              Present bit is set to 1, then the PDU carry a fragment of the
              SDU and the Fragmentation Control field is present.<a href="#section-4.1-9.4.2.10" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.11">Delivery SN Present (bit 5):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.12"> If the Delivery SN
              (Sequence Number) Present bit is set to 1, then the Delivery SN
              field is present and contains the valid information.<a href="#section-4.1-9.4.2.12" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.13">Flow SN Present (bit 6):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.14"> If the Flow SN Present bit
              is set to 1, then the Sequence Number field is present.<a href="#section-4.1-9.4.2.14" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.15">Timestamp Present (bit 7):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.16"> If the Timestamp Present
              bit is set to 1, then the Timestamp field is present.<a href="#section-4.1-9.4.2.16" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.17">TTL Present (bit 8):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.18"> If the TTL Present bit is set
              to 1, then the TTL field is present.<a href="#section-4.1-9.4.2.18" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.19">Reserved (bit 9-12):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.20"> This is set to "0" and ignored
              on receipt.<a href="#section-4.1-9.4.2.20" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-9.4.2.21">Version (bit 13~15):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-9.4.2.22"> This is the GMA version
              number; it is set to 0 for the GMA encapsulation protocol specified in
              this document.<a href="#section-4.1-9.4.2.22" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.1-10">
   The Flags field is at the end of the PDU, and the Next Header field is the
   second last. The receiver <span class="bcp14">SHOULD</span> first decode the Flags
   field to determine the length of the GMA trailer and then decode each
   optional field accordingly. The Generic Multi-Access (GMA) trailer
   <span class="bcp14">MAY</span> consist of the following optional fields:<a href="#section-4.1-10" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-11">
          <dt id="section-4.1-11.1">Checksum (1 byte):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.2"> This contains the (one's
          complement) checksum sum of all 8 bits in the trailer. For purposes
          of computing the checksum, the value of the Checksum field is
          zero. This field is present only if the Checksum Present bit is set
          to 1.<a href="#section-4.1-11.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.3">First SDU Length (2 bytes):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.4"> This is the length of the
          first IP packet in the PDU, only included if a PDU contains multiple
          IP packets. This field is present only if the Concatenation Present
          bit is set to 1.<a href="#section-4.1-11.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.5">Connection ID (1 byte):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.6">
            <p id="section-4.1-11.6.1"> This contains an unsigned integer to identify the
     anchor and delivery connection of the GMA PDU. This field is
     present only if the Connection ID Present bit is set to 1.<a href="#section-4.1-11.6.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-11.6.2">
              <dt id="section-4.1-11.6.2.1">Anchor Connection ID (MSB 4 bits):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-11.6.2.2"> This contains an
              unsigned integer to identify the anchor connection.<a href="#section-4.1-11.6.2.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-4.1-11.6.2.3">Delivery Connection ID (LSB 4 bits):</dt>
              <dd style="margin-left: 1.5em" id="section-4.1-11.6.2.4"> This contains
              an unsigned integer to identify the delivery connection.<a href="#section-4.1-11.6.2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.7">Flow ID (1 byte):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.8"> This contains an unsigned integer to identify the
          IP flow that a PDU belongs to, for example Data Radio Bearer (DRB)
          ID <span>[<a href="#LWIPEP" class="xref">LWIPEP</a>]</span> for a cellular (e.g., LTE)
          connection. This field is present only if the Flow ID Present bit is
          set to 1.<a href="#section-4.1-11.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.9">Fragmentation Control (FC) (1 byte):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.10"> This provides
          necessary information for reassembly, only needed if a PDU carries
          fragments. This field is present only if the Fragmentation Present
          bit is set to 1. Please refer to <a href="#sect-5" class="xref">Section 5</a> for its
          detailed format and usage.<a href="#section-4.1-11.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.11">Delivery SN (1 byte):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.12"> This contains an auto-incremented integer to
          indicate the GMA PDU transmission order on a delivery connection.
          Delivery SN is needed to measure packet loss of each delivery
          connection and therefore generated per delivery connection per
          flow. This field is present only if the Delivery SN Present bit is
          set to 1.<a href="#section-4.1-11.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.13">Flow SN (3 bytes):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.14"> This contains an auto-incremented
          integer to indicate the GMA SDU (IP packet) order of a flow. Flow SN
          is needed for retransmission, reordering, and fragmentation. It
          <span class="bcp14">SHALL</span> be generated per flow. This field is present
          only if the Flow SN Present bit is set to 1.<a href="#section-4.1-11.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.15">Timestamp (4 bytes):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.16"> This contains the
          current value of the timestamp clock of the transmitter in the unit
          of 1 millisecond. This field is present only if the Timestamp
          Present bit is set to 1.<a href="#section-4.1-11.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-11.17">TTL (1 byte):</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-11.18"> This contains the TTL value of
          the original IP header if the GMA SDU is IPv4, or the Hop-Limit
          value of the IP header if the GMA SDU is IPv6. This field is present
          only if the TTL Present bit is set to 1.<a href="#section-4.1-11.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.1-12">
   <a href="#Fig4" class="xref">Figure 4</a> shows the GMA trailer format with all the fields present,
   and the order of the GMA control fields <span class="bcp14">SHALL</span> follow the bit order
   in the Flags field. Note that the bits in the Flags field are
   ordered with the first bit transmitted being bit 0 (MSB). All
   fields are transmitted in regular network byte order and appear in
   reverse order to their corresponding flag bits. If a flag bit is
   clear, the corresponding optional field is absent.<a href="#section-4.1-12" class="pilcrow">¶</a></p>
<p id="section-4.1-13">
   For example, bit 0 (the MSB) of the Flags field is the Checksum Present
   bit, and the Checksum field is the last in the trailer with the exception
   of the two mandatory fields. Bit 1 is the Concatenation Present bit, and
   the FSL field is the second last.<a href="#section-4.1-13" class="pilcrow">¶</a></p>
<span id="name-gma-trailer-format-with-all"></span><div id="Fig4">
<figure id="figure-4">
          <div class="alignLeft art-text artwork" id="section-4.1-14.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     TTL       |                   Timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                |                   Flow SN                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Delivery SN  |    FC         |   Flow ID     | Connection ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      First SDU Length (FSL)   |   Checksum    |  Next Header  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Flags                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-gma-trailer-format-with-all" class="selfRef">GMA Trailer Format with All Optional Fields Present</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sect-4.2">
<section id="section-4.2">
        <h3 id="name-header-based-ip-encapsulati">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-header-based-ip-encapsulati" class="section-name selfRef">Header-Based IP Encapsulation</a>
        </h3>
<p id="section-4.2-1">
   This method <span class="bcp14">SHALL NOT</span> be used if the original IP packet (GMA SDU)
   is IPv6.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
   <a href="#Fig5" class="xref">Figure 5</a> shows the header-based IP encapsulation format. Here, the
   GMA header is inserted right after the IP header of the GMA SDU,
   and the IP header fields of the GMA PDU <span class="bcp14">MUST</span> be changed the same
   way as in trailer-based IP encapsulation.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<span id="name-gma-pdu-format-with-header-"></span><div id="Fig5">
<figure id="figure-5">
          <div class="alignLeft art-text artwork" id="section-4.2-3.1">
<pre>
       +-----------------------------------------------+
       |IP hdr | GMA Header  |       IP payload        |
       +-----------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-gma-pdu-format-with-header-" class="selfRef">GMA PDU Format with Header-Based IP Encapsulation</a>
          </figcaption></figure>
</div>
<p id="section-4.2-4">
   <a href="#Fig6" class="xref">Figure 6</a> shows the GMA header format. In comparison to the GMA
   trailer, the only difference is that the Flags field is now in the front so
   that the receiver can first decode the Flags field to determine the GMA
   header length.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">
   The "TTL" field <span class="bcp14">MUST</span> be included and the "TTL" bit in the
   GMA header (or Trailer) <span class="bcp14">MUST</span> be set to 1 if (trailer- or
   header-based) IP encapsulation is used.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<span id="name-gma-header-format"></span><div id="Fig6">
<figure id="figure-6">
          <div class="alignLeft art-text artwork" id="section-4.2-6.1">
<pre>
    +------------------------------------------------------+
    | Flags | other fields (TTL, Timestamp, Flow SN, etc.) |
    +------------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-gma-header-format" class="selfRef">GMA Header Format</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sect-4.3">
<section id="section-4.3">
        <h3 id="name-header-based-non-ip-encapsu">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-header-based-non-ip-encapsu" class="section-name selfRef">Header-Based Non-IP Encapsulation</a>
        </h3>
<p id="section-4.3-1">
   <a href="#Fig7" class="xref">Figure 7</a> shows the header-based non-IP encapsulation format. Here,
   "UDP Tunneling" is configured at the MX adaptation layer. The
   ports for "UDP Tunneling" at the client are chosen from the Dynamic
   Port range, and the ports for "UDP Tunneling" at the Multi-Access
   Gateway are configured and provided to the client through additional
   control messages, e.g., <span>[<a href="#RFC8743" class="xref">MAMS</a>]</span>.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">
   "TTL", "FSL", and "Next Header" are no longer needed and <span class="bcp14">MUST</span> not
   be included. Moreover, the IP header fields of the GMA SDU remain
   unchanged.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<span id="name-gma-pdu-format-with-non-ip-"></span><div id="Fig7">
<figure id="figure-7">
          <div class="alignLeft art-text artwork" id="section-4.3-3.1">
<pre>
 +-------------------------------------------------------------+
 | IP hdr | UDP hdr  | GMA Header | IP hdr |    IP payload     |
 +-------------------------------------------------------------+
                                 |&lt;------- GMA SDU------------&gt;|
                     |&lt;------------------- GMA PDU------------&gt;|
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-gma-pdu-format-with-non-ip-" class="selfRef">GMA PDU Format with Non-IP Encapsulation</a>
          </figcaption></figure>
</div>
</section>
</div>
<div id="sect-4.4">
<section id="section-4.4">
        <h3 id="name-ip-protocol-identifier">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-ip-protocol-identifier" class="section-name selfRef">IP Protocol Identifier</a>
        </h3>
<p id="section-4.4-1">
   As described in <a href="#sect-4.1" class="xref">Section 4.1</a>, IP-encapsulated GMA PDUs are
   indicated using the IP protocol type 114. This is designated and
   recorded by IANA <span>[<a href="#IANA" class="xref">IANA</a>]</span> to indicate "any 0-Hop Protocol". No
   reference is given in the IANA registry for the definition of this
   protocol type, and IANA has no record of why the assignment was
   made or how it is used, although it was probably assigned before
   1999 <span>[<a href="#IANA1999" class="xref">IANA1999</a>]</span>.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
   There is some risk associated with "reusing" protocol type 114
   because there may be implementations of other protocols also using
   this protocol type. However, because the protocol described in
   this document is used only between adjacent devices specifically
   configured for this purpose, the use of protocol type 114 should
   be safe.<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<p id="section-4.4-3">
   As described in <a href="#sect-1.1" class="xref">Section 1.1</a>, one of the purposes of the experiment
   described in this document is to verify the safety of using this
   protocol type. Deployments should be aware of the risk of a clash
   with other uses of this protocol type.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="sect-5">
<section id="section-5">
      <h2 id="name-fragmentation">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-fragmentation" class="section-name selfRef">Fragmentation</a>
      </h2>
<p id="section-5-1">
   If the MTU size of the anchor connection (for GMA SDU) is configured such
   that the corresponding GMA PDU length adding the GMA header (or trailer)
   and other overhead (UDP tunneling) <span class="bcp14">MAY</span> exceed the MTU of a
   delivery connection, GMA endpoints <span class="bcp14">MUST</span> be configured to
   support fragmentation through additional control messages <span>[<a href="#RFC8743" class="xref">MAMS</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
   The fragmentation procedure at the convergence sublayer is similar
   to IP fragmentation <span>[<a href="#RFC0791" class="xref">RFC0791</a>]</span> in principle, but with the following
   two differences for less overhead:<a href="#section-5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5-3.1">The fragment offset field is expressed in number of fragments.<a href="#section-5-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-5-3.2">The maximum number of fragments per SDU is 2<sup>7</sup> (=128).<a href="#section-5-3.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-5-4">
   The Fragmentation Control (FC) field in the GMA trailer (or
   header) contains the following bits:<a href="#section-5-4" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5-5">
        <dt id="section-5-5.1">Bit 7:</dt>
        <dd style="margin-left: 1.5em" id="section-5-5.2"> a More Fragment (MF) flag to indicate if the fragment
     is the last one (0) or not (1)<a href="#section-5-5.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-5.3">Bit 0-6:</dt>
        <dd style="margin-left: 1.5em" id="section-5-5.4"> Fragment Offset (in units of fragments) to specify
     the offset of a particular fragment relative to the beginning
     of the SDU<a href="#section-5-5.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-5-6">
   A PDU carries a whole SDU without fragmentation if the FC field is
   set to all "0"s or the FC field is not present in the trailer.
   Otherwise, the PDU contains a fragment of the SDU.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">
   The Flow SN field in the trailer is used to distinguish the
   fragments of one SDU from those of another. The Fragment Offset
   (FO) field tells the receiver the position of a fragment in the
   original SDU. The More Fragment (MF) flag indicates the last
   fragment.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">
   To fragment a long SDU, the transmitter creates n PDUs and copies the
   content of the IP header fields from the long PDU into the IP header of all
   the PDUs. The length field in the IP header of the PDU
   <span class="bcp14">SHOULD</span> be changed to the length of the PDU, and the protocol
   type <span class="bcp14">SHOULD</span> be changed to 114.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">
   The data of the long SDU is divided into n portions based on the
   MTU size of the delivery connection. The first portion of the data
   is placed in the first PDU. The MF flag is set to "1", and the FO
   field is set to "0". The i-th portion of the data is placed in the
   i-th PDU. The MF flag is set to "0" if it is the last fragment and
   set to "1" otherwise. The FO field is set to i-1.<a href="#section-5-9" class="pilcrow">¶</a></p>
<p id="section-5-10">
   To assemble the fragments of an SDU, the receiver combines PDUs
   that all have the same Flow SN. The combination is done by placing
   the data portion of each fragment in the relative order indicated
   by the Fragment Offset in that fragment's GMA trailer (or header).
   The first fragment will have the Fragment Offset set to "0", and
   the last fragment will have the More Fragment flag set to "0".<a href="#section-5-10" class="pilcrow">¶</a></p>
<p id="section-5-11">
   GMA fragmentation operates above the IP layer of individual access
   connection (Wi-Fi, LTE) and between the two endpoints of convergence
   layer. The convergence layer endpoints (client, Multi-access Gateway)
   <span class="bcp14">SHOULD</span> obtain the MTU of individual connection through
   either manual configuration or implementing Path MTU Discovery (PMTUD) as
   suggested in <span>[<a href="#RFC8900" class="xref">RFC8900</a>]</span>.<a href="#section-5-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-6">
<section id="section-6">
      <h2 id="name-concatenation">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-concatenation" class="section-name selfRef">Concatenation</a>
      </h2>
<p id="section-6-1">
   The convergence sublayer <span class="bcp14">MAY</span> support concatenation if a delivery
   connection has a larger maximum transmission unit (MTU) than the
   original IP packet (SDU). Only the SDUs with the same client IP
   address and the same Flow ID <span class="bcp14">MAY</span> be concatenated.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
   If the (trailer- or header-based) IP encapsulation method is used,
   the First SDU Length (FSL) field <span class="bcp14">SHOULD</span> be included in the GMA
   trailer (or header) to indicate the length of the first SDU.
   Otherwise, the FSL field <span class="bcp14">SHOULD</span> not be included.<a href="#section-6-2" class="pilcrow">¶</a></p>
<span id="name-example-of-gma-pdu-format-w"></span><div id="Fig8">
<figure id="figure-8">
        <div class="alignLeft art-text artwork" id="section-6-3.1">
<pre>
  +-----------------------------------------------------------+
  |IP hdr| IP payload    |IP hdr|   IP payload  | GMA Trailer |
  +-----------------------------------------------------------+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-example-of-gma-pdu-format-w" class="selfRef">Example of GMA PDU Format with Concatenation and Trailer-Based IP Encapsulation</a>
        </figcaption></figure>
</div>
<p id="section-6-4">
   To concatenate two or more SDUs, the transmitter creates one PDU
   and copies the content of the IP header field from the first SDU
   into the IP header of the PDU. The data of the first SDU is placed
   in the first portion of the data of the PDU. The whole second SDU
   is then placed in the second portion of the data of the PDU
   (<a href="#Fig8" class="xref">Figure 8</a>). The procedure continues until the PDU size reaches the
   MTU of the delivery connection. If the FSL field is present, the
   IP Length field of the PDU <span class="bcp14">SHOULD</span> be updated to include all
   concatenated SDUs and the trailer (or header), and the IP checksum
   field <span class="bcp14">SHOULD</span> be recalculated if the packet is IPv4.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">
   To disaggregate a PDU, if the (header- or trailer-based) IP
   encapsulation method is used, the receiver first obtains the
   length of the first SDU from the FSL field and decodes the first
   SDU. The receiver then obtains the length of the second SDU based
   on the length field in the second SDU IP header and decodes the
   second SDU. The procedure continues until no byte is left in the
   PDU. If the non-IP encapsulation method (<a href="#Fig7" class="xref">Figure 7</a>) is used, the IP
   header of the first SDU will not change during the encapsulation
   process, and the receiver <span class="bcp14">SHOULD</span> obtain the length of the first
   SDU directly from its IP header (<a href="#Fig9" class="xref">Figure 9</a>).<a href="#section-6-5" class="pilcrow">¶</a></p>
<span id="name-example-of-gma-pdu-format-wi"></span><div id="Fig9">
<figure id="figure-9">
        <div class="alignLeft art-text artwork" id="section-6-6.1">
<pre>
                                 |&lt;-------1st GMA SDU------------
+---------------------------------------------------------------+
| IP hdr | UDP hdr  | GMA Header | IP hdr |       IP payload    |
+---------------------------------------------------------------+
         | IP hdr |           IP payload    |
+-------------------------------------------+
--------&gt;|&lt;-------2nd GMA SDU---------------&gt;
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-example-of-gma-pdu-format-wi" class="selfRef">Example of GMA PDU Format with Concatenation and Header-Based Non-IP (UDP) Encapsulation</a>
        </figcaption></figure>
</div>
<p id="section-6-7">
   If a PDU contains multiple SDUs, the Flow SN field is for the last
   SDU, and the Flow SN of other SDUs carried by the same PDU can be
   obtained according to its order in the PDU. For example, if the SN
   field is 6 and a PDU contains 3 SDUs (IP packets), the SN is 4, 5,
   and 6 for the first, second, and last SDU, respectively.<a href="#section-6-7" class="pilcrow">¶</a></p>
<p id="section-6-8">
   GMA concatenation can be used for packing small packets of a
   single application, e.g., TCP ACKs, or from multiple applications.
   Notice that a single GMA flow may carry multiple application flows
   (TCP, UDP, etc.).<a href="#section-6-8" class="pilcrow">¶</a></p>
<p id="section-6-9">
   GMA endpoints <span class="bcp14">MUST NOT</span> perform concatenation and
   fragmentation in a single PDU. If a GMA PDU carries a fragmented SDU, it
   <span class="bcp14">MUST NOT</span> carry any other (fragmented or whole) SDU.<a href="#section-6-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-7">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">
   Security in a network using GMA should be relatively similar to security in
   a normal IP network. GMA is unaware of IP- or higher-layer end-to-end
   security as it carries the IP packets as opaque payload. Deployers are
   encouraged to not consider that GMA adds any form of security and to
   continue to use IP- or higher-layer security as well as link-layer
   security.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
   The GMA protocol at the convergence sublayer is a 0-hop protocol and relies
   on the security of the underlying network transport paths. When this cannot
   be assumed, appropriate security protocols (IPsec, DTLS, etc.)
   <span class="bcp14">SHOULD</span> be configured at the adaptation sublayer. On the
   other hand, packet filtering requires either that a firewall looks inside
   the GMA packet or that the filtering is done on the GMA endpoints. In those
   environments in which this is considered to be a security issue, it may be
   desirable to terminate the GMA operation at the firewall.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
   Local-only packet leak prevention (HL=0, TTL=1) <span class="bcp14">SHOULD</span> be on
   preventing the leak of the local-only GMA PDUs outside the "local domain"
   to the Internet or to another domain that could use the same IP protocol
   type, i.e., 114.<a href="#section-7-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sect-8">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">
 This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2890">[GRE1]</dt>
        <dd>
<span class="refAuthor">Dommety, G.</span>, <span class="refTitle">"Key and Sequence Number Extensions to GRE"</span>, <span class="seriesInfo">RFC 2890</span>, <span class="seriesInfo">DOI 10.17487/RFC2890</span>, <time datetime="2000-09" class="refDate">September 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2890">https://www.rfc-editor.org/info/rfc2890</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8157">[GRE2]</dt>
        <dd>
<span class="refAuthor">Leymann, N.</span>, <span class="refAuthor">Heidemann, C.</span>, <span class="refAuthor">Zhang, M.</span>, <span class="refAuthor">Sarikaya, B.</span>, and <span class="refAuthor">M. Cullen</span>, <span class="refTitle">"Huawei's GRE Tunnel Bonding Protocol"</span>, <span class="seriesInfo">RFC 8157</span>, <span class="seriesInfo">DOI 10.17487/RFC8157</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8157">https://www.rfc-editor.org/info/rfc8157</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="RFC8174">[RFC8174]</dt>
      <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="ATSSS">[ATSSS]</dt>
        <dd>
<span class="refAuthor">3GPP</span>, <span class="refTitle">"Study on access traffic steering, switch and splitting support in the 5G System (5GS) architecture"</span>, <span class="refContent">Release 16</span>, <span class="seriesInfo">3GPP TR 23.793</span>, <time datetime="2018-12" class="refDate">December 2018</time>, <span>&lt;<a href="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3254">https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3254</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="GCC">[GCC]</dt>
        <dd>
<span class="refAuthor">Holmer, S.</span>, <span class="refAuthor">Lundin, H.</span>, <span class="refAuthor">Carlucci, G.</span>, <span class="refAuthor">De Cicco, L.</span>, and <span class="refAuthor">S. Mascolo</span>, <span class="refTitle">"A Google Congestion Control Algorithm for Real-Time Communication"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-rmcat-gcc-02</span>, <time datetime="2016-07-08" class="refDate">8 July 2016</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02">https://datatracker.ietf.org/doc/html/draft-ietf-rmcat-gcc-02</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.zhu-intarea-gma-control">[GMAC]</dt>
        <dd>
<span class="refAuthor">Zhu, J.</span> and <span class="refAuthor">M. Zhang</span>, <span class="refTitle">"UDP-based Generic Multi-Access (GMA) Control Protocol"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-zhu-intarea-gma-control-00</span>, <time datetime="2021-10-13" class="refDate">13 October 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-zhu-intarea-gma-control-00">https://datatracker.ietf.org/doc/html/draft-zhu-intarea-gma-control-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA">[IANA]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"Protocol Numbers"</span>, <span>&lt;<a href="https://www.iana.org/assignments/protocol-numbers">https://www.iana.org/assignments/protocol-numbers</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA1999">[IANA1999]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">Wayback Machine archive of "Protocol Numbers"</span>, <time datetime="1999-02" class="refDate">February 1999</time>, <span>&lt;<a href="https://web.archive.org/web/19990203044112/http://www.isi.edu:80/in-notes/iana/assignments/protocol-numbers">https://web.archive.org/web/19990203044112/http://www.isi.edu:80/in-notes/iana/assignments/protocol-numbers</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="LWIPEP">[LWIPEP]</dt>
        <dd>
<span class="refAuthor">3GPP</span>, <span class="refTitle">"Evolved Universal Terrestrial Radio Access (E-UTRA); LTE-WLAN Radio Level Integration Using Ipsec Tunnel (LWIP) encapsulation; Protocol specification"</span>, <span class="refContent">Release 13</span>, <span class="seriesInfo">3GPP TS 36.361</span>, <time datetime="2020-07" class="refDate">July 2020</time>, <span>&lt;<a href="https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3037">https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3037</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8743">[MAMS]</dt>
        <dd>
<span class="refAuthor">Kanugovi, S.</span>, <span class="refAuthor">Baboescu, F.</span>, <span class="refAuthor">Zhu, J.</span>, and <span class="refAuthor">S. Seo</span>, <span class="refTitle">"Multiple Access Management Services Multi-Access Management Services (MAMS)"</span>, <span class="seriesInfo">RFC 8743</span>, <span class="seriesInfo">DOI 10.17487/RFC8743</span>, <time datetime="2020-03" class="refDate">March 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8743">https://www.rfc-editor.org/info/rfc8743</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="MPIP">[MPIP]</dt>
        <dd>
<span class="refAuthor">Sun, L.</span>, <span class="refAuthor">Tian, G.</span>, <span class="refAuthor">Zhu, G.</span>, <span class="refAuthor">Liu, Y.</span>, <span class="refAuthor">Shi, H.</span>, and <span class="refAuthor">D. Dai</span>, <span class="refTitle">"Multipath IP Routing on End Devices: Motivation, Design, and Performance"</span>, <time datetime="2017" class="refDate">2017</time>, <span>&lt;<a href="https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/MPIP_Tech.pdf">https://eeweb.engineering.nyu.edu/faculty/yongliu/docs/MPIP_Tech.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0791">[RFC0791]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span>, <span class="refTitle">"Internet Protocol"</span>, <span class="seriesInfo">STD 5</span>, <span class="seriesInfo">RFC 791</span>, <span class="seriesInfo">DOI 10.17487/RFC0791</span>, <time datetime="1981-09" class="refDate">September 1981</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc791">https://www.rfc-editor.org/info/rfc791</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8900">[RFC8900]</dt>
      <dd>
<span class="refAuthor">Bonica, R.</span>, <span class="refAuthor">Baker, F.</span>, <span class="refAuthor">Huston, G.</span>, <span class="refAuthor">Hinden, R.</span>, <span class="refAuthor">Troan, O.</span>, and <span class="refAuthor">F. Gont</span>, <span class="refTitle">"IP Fragmentation Considered Fragile"</span>, <span class="seriesInfo">BCP 230</span>, <span class="seriesInfo">RFC 8900</span>, <span class="seriesInfo">DOI 10.17487/RFC8900</span>, <time datetime="2020-09" class="refDate">September 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8900">https://www.rfc-editor.org/info/rfc8900</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="authors-addresses">
<section id="appendix-A">
      <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">Jing Zhu</span></div>
<div dir="auto" class="left"><span class="org">Intel</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:jing.z.zhu@intel.com" class="email">jing.z.zhu@intel.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Satish Kanugovi</span></div>
<div dir="auto" class="left"><span class="org">Nokia</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:satish.k@nokia.com" class="email">satish.k@nokia.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>