<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-welzl-loops-gen-info-04" indexInclude="true" ipr="trust200902" prepTime="2020-07-13T18:05:02" scripts="Common,Latin" sortRefs="false" submissionType="IETF" symRefs="true" tocDepth="3" tocInclude="true" xml:lang="en">
  <!-- xml2rfc v2v3 conversion 2.45.0 -->
  <front>
    <title abbrev="LOOPS">LOOPS Generic Information Set</title>
    <seriesInfo name="Internet-Draft" value="draft-welzl-loops-gen-info-04" stream="IETF"/>
    <author initials="M." surname="Welzl" fullname="Michael Welzl">
      <organization showOnFrontPage="true">University of Oslo</organization>
      <address>
        <postal>
          <street>PO Box 1080 Blindern</street>
          <city>Oslo</city>
          <code>N-0316</code>
          <country>Norway</country>
        </postal>
        <phone>+47 22 85 24 20</phone>
        <email>michawe@ifi.uio.no</email>
      </address>
    </author>
    <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
      <organization showOnFrontPage="true">Universität Bremen TZI</organization>
      <address>
        <postal>
          <street>Postfach 330440</street>
          <city>Bremen</city>
          <code>D-28359</code>
          <country>Germany</country>
        </postal>
        <phone>+49-421-218-63921</phone>
        <email>cabo@tzi.org</email>
      </address>
    </author>
    <date month="07" year="2020" day="13"/>
    <workgroup>TSVWG</workgroup>
    <abstract pn="section-abstract">
      <t pn="section-abstract-1">LOOPS (Local Optimizations on Path Segments) aims to provide local
(not end-to-end but in-network) recovery of lost packets to achieve
better data delivery in the presence of losses.  <xref target="I-D.li-tsvwg-loops-problem-opportunities" format="default" sectionFormat="of" derivedContent="I-D.li-tsvwg-loops-problem-opportunities"/>
provides an overview over the problems and optimization opportunities
that LOOPS could address.</t>
      <t pn="section-abstract-2">The present document is a strawman for the set of information that
would be interchanged in a LOOPS protocol, without already defining a
specific data packet format.</t>
      <t pn="section-abstract-3">The generic information set needs to be mapped to a specific
encapsulation protocol to actually run the LOOPS optimizations.
A companion document contains a sketch of a binding to the tunnel
encapsulation protocol Geneve <xref target="I-D.ietf-nvo3-geneve" format="default" sectionFormat="of" derivedContent="I-D.ietf-nvo3-geneve"/>.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t pn="section-boilerplate.1-1">
        This Internet-Draft is submitted in full conformance with the
        provisions of BCP 78 and BCP 79.
        </t>
        <t pn="section-boilerplate.1-2">
        Internet-Drafts are working documents of the Internet Engineering Task
        Force (IETF). Note that other groups may also distribute working
        documents as Internet-Drafts. The list of current Internet-Drafts is
        at <eref target="https://datatracker.ietf.org/drafts/current/" brackets="none"/>.
        </t>
        <t pn="section-boilerplate.1-3">
        Internet-Drafts are draft documents valid for a maximum of six months
        and may be updated, replaced, or obsoleted by other documents at any
        time. It is inappropriate to use Internet-Drafts as reference
        material or to cite them other than as "work in progress."
        </t>
        <t pn="section-boilerplate.1-4">
        This Internet-Draft will expire on 14 January 2021.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t pn="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-challenges">Challenges</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.2.2">
              <li pn="section-toc.1-1.2.2.1">
                <t keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-no-access-to-end-to-end-tra">No Access to End-to-End Transport Information</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.2">
                <t pn="section-toc.1-1.2.2.2.1"><xref derivedContent="2.2" format="counter" sectionFormat="of" target="section-2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-path-asymmetry">Path Asymmetry</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.3">
                <t pn="section-toc.1-1.2.2.3.1"><xref derivedContent="2.3" format="counter" sectionFormat="of" target="section-2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reordering-vs-spurious-retr">Reordering vs. Spurious Retransmission</xref></t>
              </li>
              <li pn="section-toc.1-1.2.2.4">
                <t pn="section-toc.1-1.2.2.4.1"><xref derivedContent="2.4" format="counter" sectionFormat="of" target="section-2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informing-the-end-to-end-tr">Informing the End-to-End Transport</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.3">
            <t pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-simplifying-assumptions">Simplifying assumptions</xref></t>
          </li>
          <li pn="section-toc.1-1.4">
            <t pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-loops-architecture">LOOPS Architecture</xref></t>
          </li>
          <li pn="section-toc.1-1.5">
            <t pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-loops-generic-information-s">LOOPS Generic Information Set</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.5.2">
              <li pn="section-toc.1-1.5.2.1">
                <t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-setup-information">Setup Information</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.2">
                <t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-forward-information">Forward Information</xref></t>
              </li>
              <li pn="section-toc.1-1.5.2.3">
                <t pn="section-toc.1-1.5.2.3.1"><xref derivedContent="5.3" format="counter" sectionFormat="of" target="section-5.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-reverse-information">Reverse Information</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.6">
            <t pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-loops-general-operation">LOOPS General Operation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-initial-packet-sequence-num">Initial Packet Sequence Number</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.1.2">
                  <li pn="section-toc.1-1.6.2.1.2.1">
                    <t pn="section-toc.1-1.6.2.1.2.1.1"><xref derivedContent="6.1.1" format="counter" sectionFormat="of" target="section-6.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-minimizing-collisions">Minimizing collisions</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.1.2.2">
                    <t pn="section-toc.1-1.6.2.1.2.2.1"><xref derivedContent="6.1.2" format="counter" sectionFormat="of" target="section-6.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-optional-initial-psn-proced">Optional Initial PSN procedure</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgement-generation">Acknowledgement Generation</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.3">
                <t pn="section-toc.1-1.6.2.3.1"><xref derivedContent="6.3" format="counter" sectionFormat="of" target="section-6.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-measurement">Measurement</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.3.2">
                  <li pn="section-toc.1-1.6.2.3.2.1">
                    <t pn="section-toc.1-1.6.2.3.2.1.1"><xref derivedContent="6.3.1" format="counter" sectionFormat="of" target="section-6.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ingress-relative-timestamps">Ingress-relative timestamps</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.3.2.2">
                    <t pn="section-toc.1-1.6.2.3.2.2.1"><xref derivedContent="6.3.2" format="counter" sectionFormat="of" target="section-6.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ack-generation">ACK generation</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.4">
                <t pn="section-toc.1-1.6.2.4.1"><xref derivedContent="6.4" format="counter" sectionFormat="of" target="section-6.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-loss-detection-and-recovery">Loss detection and Recovery</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2.4.2">
                  <li pn="section-toc.1-1.6.2.4.2.1">
                    <t pn="section-toc.1-1.6.2.4.2.1.1"><xref derivedContent="6.4.1" format="counter" sectionFormat="of" target="section-6.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-local-retransmission">Local Retransmission</xref></t>
                  </li>
                  <li pn="section-toc.1-1.6.2.4.2.2">
                    <t pn="section-toc.1-1.6.2.4.2.2.1"><xref derivedContent="6.4.2" format="counter" sectionFormat="of" target="section-6.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-fec">FEC</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.6.2.5">
                <t pn="section-toc.1-1.6.2.5.1"><xref derivedContent="6.5" format="counter" sectionFormat="of" target="section-6.5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discussion">Discussion</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-sketches-of-bindings-to-tun">Sketches of Bindings to Tunnel Protocols</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-embedding-loops-in-geneve">Embedding LOOPS in Geneve</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threat-model">Threat model</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-discussion-2">Discussion</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t pn="section-toc.1-1.10.1"><xref derivedContent="10" format="counter" sectionFormat="of" target="section-10"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.10.2">
              <li pn="section-toc.1-1.10.2.1">
                <t pn="section-toc.1-1.10.2.1.1"><xref derivedContent="10.1" format="counter" sectionFormat="of" target="section-10.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.10.2.2">
                <t pn="section-toc.1-1.10.2.2.1"><xref derivedContent="10.2" format="counter" sectionFormat="of" target="section-10.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.11">
            <t pn="section-toc.1-1.11.1"><xref derivedContent="Appendix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-used-in-prototype-">Protocol used in Prototype Implementation</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.11.2">
              <li pn="section-toc.1-1.11.2.1">
                <t pn="section-toc.1-1.11.2.1.1"><xref derivedContent="A.1" format="counter" sectionFormat="of" target="section-a.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-block-code-fec">Block Code FEC</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.12">
            <t pn="section-toc.1-1.12.1"><xref derivedContent="Appendix B" format="default" sectionFormat="of" target="section-appendix.b"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-transparent-mode">Transparent mode</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.12.2">
              <li pn="section-toc.1-1.12.2.1">
                <t pn="section-toc.1-1.12.2.1.1"><xref derivedContent="B.1" format="counter" sectionFormat="of" target="section-b.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-identification">Packet identification</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.2">
                <t pn="section-toc.1-1.12.2.2.1"><xref derivedContent="B.2" format="counter" sectionFormat="of" target="section-b.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-generic-information-and-pro">Generic information and protocol operation</xref></t>
              </li>
              <li pn="section-toc.1-1.12.2.3">
                <t pn="section-toc.1-1.12.2.3.1"><xref derivedContent="B.3" format="counter" sectionFormat="of" target="section-b.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-a-hybrid-mode">A hybrid mode</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.13">
            <t pn="section-toc.1-1.13.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.14">
            <t pn="section-toc.1-1.14.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.d"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t pn="section-1-1">Today's networks exhibit a wide variety of data rates and, relative to
those, processing power and memory capacities of nodes acting as
routers.  For instance, networks that employ tunneling to build
overlay networks may position powerful virtual router nodes in the
network to act as tunnel endpoints.  The capabilities available in the
more powerful cases provide new opportunities for optimizations.</t>
      <t pn="section-1-2">LOOPS (Local Optimizations on Path Segments) aims to provide local
(not end-to-end but in-network) recovery of lost packets to achieve
better data delivery.  <xref target="I-D.li-tsvwg-loops-problem-opportunities" format="default" sectionFormat="of" derivedContent="I-D.li-tsvwg-loops-problem-opportunities"/> provides an overview over
the problems and optimization opportunities that LOOPS could address.
One simplifying assumption (<xref target="sec-simply" format="default" sectionFormat="of" derivedContent="Section 3"/>) in the present document is
that LOOPS segments operate independently from each other, each as a
pair of a LOOPS Ingress and a LOOPS Egress node.</t>
      <t pn="section-1-3">The present document is a strawman for the set of information that
would be interchanged in a LOOPS protocol between these nodes, without
already defining a specific data packet format.
The main body of the document defines a mode of the LOOPS protocol
that is based on traditional tunneling, the "tunnel mode".
<xref target="sec-trans" format="default" sectionFormat="of" derivedContent="Appendix B"/> is an even rougher strawman of a radically different,
alternative mode that we call "transparent mode", as well as a
slightly more conventional "hybrid mode" (<xref target="hybrid" format="default" sectionFormat="of" derivedContent="Appendix B.3"/>).
These different modes may be applicable to different usage scenarios
and will be developed in parallel, with a view of ultimately
standardizing one or more of them.</t>
      <t pn="section-1-4">For tunnel mode,
the generic information set needs to be mapped to a specific
encapsulation protocol to actually run the LOOPS optimizations.  LOOPS
is not tied to any specific overlay protocol, but is meant to run
embedded into a variety of tunnel protocols.  LOOPS information is
added as part of a tunnel protocol header at the LOOPS ingress as
shown in <xref target="fig-loops-packet" format="default" sectionFormat="of" derivedContent="Figure 1"/>.
A companion document <xref target="I-D.bormann-loops-geneve-binding" format="default" sectionFormat="of" derivedContent="I-D.bormann-loops-geneve-binding"/> contains a sketch of a binding to the tunnel
encapsulation protocol Geneve <xref target="I-D.ietf-nvo3-geneve" format="default" sectionFormat="of" derivedContent="I-D.ietf-nvo3-geneve"/>.</t>
      <figure anchor="fig-loops-packet" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-packet-in-tunnel-with-loops">Packet in Tunnel with LOOPS Information</name>
        <artwork name="" type="" align="left" alt="" pn="section-1-5.1"><![CDATA[
          +------------------------------------+
          |           Outer header             |
          +------------------------------------+
        / |         Tunnel Base Header         |
      /   +------------------------------------+\
 Tunnel   |    +-------------------------+     | \
 Header   ~    |    LOOPS Information    |     ~  Tunnel Header
      \   |    +-------------------------+     |  Extensions
        \ +------------------------------------+ /
          |           Data packet              |
          +------------------------------------+

]]></artwork>
      </figure>
      <t pn="section-1-6"><xref target="fig-loops-usage-scenario" format="default" sectionFormat="of" derivedContent="Figure 2"/> is extracted from the LOOPS problems and
opportunities document <xref target="I-D.li-tsvwg-loops-problem-opportunities" format="default" sectionFormat="of" derivedContent="I-D.li-tsvwg-loops-problem-opportunities"/>. It illustrates the basic
architecture and terms of the applicable scenario of LOOPS.  Not all
of the concepts introduced in the problems and opportunities document
are actually used in the current strawman specification;
<xref target="sec-simply" format="default" sectionFormat="of" derivedContent="Section 3"/> lays out some simplifying assumptions that the present
proposal makes.</t>
      <figure anchor="fig-loops-usage-scenario" align="left" suppress-title="false" pn="figure-2">
        <name slugifiedName="name-loops-usage-scenario">LOOPS Usage Scenario</name>
        <artwork name="" type="" align="left" alt="" pn="section-1-7.1"><![CDATA[
                                                   ON=overlay node
                                                   UN=underlay node

+---------+                                               +---------+
|   App   | <---------------- end-to-end ---------------> |   App   |
+---------+                                               +---------+
|Transport| <---------------- end-to-end ---------------> |Transport|
+---------+                                               +---------+
|         |                                               |         |
|         |        +--+  path  +--+  path segment2  +--+  |         |
|         |        |  |<-seg1->|  |<--------------> |  |  |         |
| Network |  +--+  |ON|  +--+  |ON|  +--+   +----+  |ON|  | Network |
|         |--|UN|--|  |--|UN|--|  |--|UN|---| UN |--|  |--|         |
+---------+  +--+  +--+  +--+  +--+  +--+   +----+  +--+  +---------+
  End Host                                                  End Host
                    <--------------------------------->
                     LOOPS domain: path segments enabling
                     optimization for local in-network recovery
]]></artwork>
      </figure>
      <section anchor="terminology" numbered="true" toc="include" removeInRFC="false" pn="section-1.1">
        <name slugifiedName="name-terminology">Terminology</name>
        <t pn="section-1.1-1">The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <t pn="section-1.1-2">This document makes use of the terminology defined in
<xref target="I-D.li-tsvwg-loops-problem-opportunities" format="default" sectionFormat="of" derivedContent="I-D.li-tsvwg-loops-problem-opportunities"/>.
This section defines additional terminology used by this document.</t>
        <dl newline="false" spacing="normal" pn="section-1.1-3">
          <dt pn="section-1.1-3.1">Data packets:</dt>
          <dd pn="section-1.1-3.2">
  The payload packets that enter and exit a LOOPS segment.</dd>
          <dt pn="section-1.1-3.3">LOOPS Segment:</dt>
          <dd pn="section-1.1-3.4">
  A part of an end-to-end path covered by a single instance of the
LOOPS protocol, the sub-path between the LOOPS Ingress and the LOOPS
Egress.  Several LOOPS segments may be encountered on an end-to-end
path, with or without intervening routers.</dd>
          <dt pn="section-1.1-3.5">LOOPS Ingress:</dt>
          <dd pn="section-1.1-3.6">
  The node that forwards data packets and forward information into the
LOOPS segment, potentially performing retransmission and forward
error correction based on acknowledgements and measurements received
from the LOOPS Egress.</dd>
          <dt pn="section-1.1-3.7">LOOPS Egress:</dt>
          <dd pn="section-1.1-3.8">
  The node that receives the data packets and forward information from
the LOOPS ingress, sends acknowledgements and measurements back to
the LOOPS ingress (reverse information), potentially recovers data
packets from forward error correction information received.</dd>
          <dt pn="section-1.1-3.9">LOOPS Nodes:</dt>
          <dd pn="section-1.1-3.10">
  Collective term for LOOPS Ingress and LOOPS Egress in a LOOPS
Segment.</dd>
          <dt pn="section-1.1-3.11">Forward Information:</dt>
          <dd pn="section-1.1-3.12">
  Information that is added to the stream of data packets in the
forward direction by the LOOPS Ingress.</dd>
          <dt pn="section-1.1-3.13">Reverse Information:</dt>
          <dd pn="section-1.1-3.14">
  Information that flows in the reverse direction, from the LOOPS
Egress back to the LOOPS Ingress.</dd>
          <dt pn="section-1.1-3.15">Setup Information:</dt>
          <dd pn="section-1.1-3.16">
  Information that is not transferred as part of the Forward or
Reverse Information, but is part of the setup of the LOOPS Nodes.</dd>
          <dt pn="section-1.1-3.17">PSN:</dt>
          <dd pn="section-1.1-3.18">
  Packet Sequence Number, a sequence number identifying a data packet
between the LOOPS Ingress and Egress.</dd>
          <dt pn="section-1.1-3.19">Sender:</dt>
          <dd pn="section-1.1-3.20">
  Original sender of a packet on an end-to-end path that includes one
or more LOOPS segment(s).</dd>
          <dt pn="section-1.1-3.21">Receiver:</dt>
          <dd pn="section-1.1-3.22">
  Ultimate receiver of a packet on an end-to-end path that includes
one or more LOOPS segment(s).</dd>
        </dl>
      </section>
    </section>
    <section anchor="challenges" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-challenges">Challenges</name>
      <t pn="section-2-1">LOOPS has to perform well in the presence of some challenges, which
are discussed in this section.</t>
      <section anchor="no-access-to-end-to-end-transport-information" numbered="true" toc="include" removeInRFC="false" pn="section-2.1">
        <name slugifiedName="name-no-access-to-end-to-end-tra">No Access to End-to-End Transport Information</name>
        <t pn="section-2.1-1">LOOPS is defined to be independent of the content of the packets being
forwarded: there is no dependency on transport-layer or higher
information.  The intention is to keep LOOPS useful with a traffic mix
that may contain encrypted transport protocols such as QUIC as well as
encrypted VPN traffic.</t>
      </section>
      <section anchor="path-asymmetry" numbered="true" toc="include" removeInRFC="false" pn="section-2.2">
        <name slugifiedName="name-path-asymmetry">Path Asymmetry</name>
        <t pn="section-2.2-1">A LOOPS segment is defined as a unidirectional forwarding path.
The tunnel might be shared with a LOOPS segment in the inverse
direction; this then allows to piggyback Reverse Information on
encapsulated packets on that segment.
But there is no guarantee that the inverse direction of any
end-to-end-path crosses that segment, so the LOOPS optimizations have
to be useful on their own in each direction.</t>
      </section>
      <section anchor="reordering-vs-spurious-retransmission" numbered="true" toc="include" removeInRFC="false" pn="section-2.3">
        <name slugifiedName="name-reordering-vs-spurious-retr">Reordering vs. Spurious Retransmission</name>
        <t pn="section-2.3-1">The end-to-end transport layer protocol may have its own
retransmission mechanism to recover lost packets.
When LOOPS recovers a loss, ideally this local recovery would replace the
triggering of a retransmission at the end-to-end sender.</t>
        <t pn="section-2.3-2">Whether this is possible depends on the specific end-to-end mechanism
used for triggering retransmission.  When end-to-end retransmission is
triggered by receiving a sequence of duplicate acknowledgements
(DUPACKs), and with more than a few packets in flight, the recovered
packet is likely to be too late to fill the hole in the sequence
number space that triggers the DUPACK detection.</t>
        <t pn="section-2.3-3">(Given a reasonable setting of parameters, the local retransmission
will still arrive earlier than the end-to-end retransmission and will
possibly unblock application processing earlier; with spurious
retransmission detection, there also will be little long-term effect
on the send rate.)</t>
        <t pn="section-2.3-4">While LOOPS makes no requirements on end-to-end protocols, it is worth
noting that
the waste of bandwidth caused by a DUPACK-based end-to-end
retransmission can be avoided when the end-to-end loss detection is
based on time instead of sequence numbers, e.g., with RACK
<xref target="I-D.ietf-tcpm-rack" format="default" sectionFormat="of" derivedContent="I-D.ietf-tcpm-rack"/>.  This requires a limit on the additional
latency that LOOPS will incur in its attempt to recover the loss
locally.  In the present version of this document, opportunity to set
such a limit is
provided in the Setup Information.  The limit can be used to compute a
deadline for retransmission, but also can be used to choose FEC
parameters that keep extra latency low.</t>
        <!--
Spurious retransmission can be avoided even with DUPACK-based
end-to-end protocols if the LOOPS egress resequences the data
packets.  With FEC based local recovery, this is relatively easy to
achieve without much additional effort.  Obviously, this introduces
extra latency even for packets that made it through the segment
without a loss.
 -->

</section>
      <section anchor="sec-cc" numbered="true" toc="include" removeInRFC="false" pn="section-2.4">
        <name slugifiedName="name-informing-the-end-to-end-tr">Informing the End-to-End Transport</name>
        <t pn="section-2.4-1">Congestion control at the end-to-end sender is used to adapt its
sending rate to the network congestion status.  In typical TCP
senders, packet loss implies congestion and leads to a reduction in
sending rate.  With LOOPS operating, packet loss can be masked from
the sender as the loss may have been locally recovered.
In this case, rate reduction may not be invoked at the
sender.  This is a desirable performance improvement if the loss was a
random loss, but it is hard to ascertain that.</t>
        <t pn="section-2.4-2">If LOOPS successfully conceals congestion losses from the end-to-end
transport protocol, that might increase the rate to a level that
congests the LOOPS segment, or that causes excessive queueing at the
LOOPS ingress.
What LOOPS should be able to achieve is to let the end host sender
invoke the rate reduction mechanism when there is a congestion loss no
matter if the lost packet was recovered locally.</t>
        <t pn="section-2.4-3">As with any tunneling protocol, information about congestion events
inside the tunnel needs to be exported to the end-to-end path the
tunnel is part of.
See e.g., <xref target="RFC6040" format="default" sectionFormat="of" derivedContent="RFC6040"/> for a discussion of how to
do this in the presence of ECN.  A more recent draft,
<xref target="I-D.ietf-tsvwg-tunnel-congestion-feedback" format="default" sectionFormat="of" derivedContent="I-D.ietf-tsvwg-tunnel-congestion-feedback"/>, proposes to activate ECN for the
tunnel regardless of whether the end-to-end protocol signals the use
of an ECN-capable transport (ECT), which requires more complicated
action at the tunnel egress.</t>
        <t pn="section-2.4-4">A sender that interprets reordering as a signal of packet loss
(DUPACKs) initiates a retransmission and reduces the sending rate.
When spurious retransmission detection (e.g., via F-RTO <xref target="RFC5862" format="default" sectionFormat="of" derivedContent="RFC5862"/> or DSACK <xref target="RFC3708" format="default" sectionFormat="of" derivedContent="RFC3708"/>) is
enabled by the TCP sender, it will often be able undo the unnecessary window
reduction shortly afterwards.  As LOOPS recovers lost packets locally, in most cases the
end host sender will eventually find out its reordering-based
retransmission (if any) is spurious.  This is an appropriate
performance improvement if the loss was a random loss.  For congestion
losses, a congestion event needs to be signaled to the end-to-end
transport.</t>
        <t pn="section-2.4-5">The present version of LOOPS requires
the end-to-end transport to be ECN-capable (which is visible at the IP
level).  Congestion loss events can easily be signaled to them by
setting the CE (congestion experienced) mark.
Effectively, LOOPS converts a packet loss (which would be a congestion
indication) to a CE mark (which also is a congestion indication).</t>
        <t pn="section-2.4-6">In effect, LOOPS can be used to convert a path segment that does not
yet use CE marks for congestion indication, and drops packets instead,
into a segment that marks for congestion and does not drop packets
except in extreme cases, incurring the benefits of Using Explicit
Congestion Notification (ECN) <xref target="RFC8087" format="default" sectionFormat="of" derivedContent="RFC8087"/>.  We speak about the
"drop-to-mark" function of LOOPS.</t>
        <!--
While end-hosts are increasingly ECN-capable, LOOPS must also work with
legacy end-hosts, or on paths that suppress ECN negotiation.
 -->
<t pn="section-2.4-7"><!--
If LOOPS were to work also for non-ECT packets, it would need to
signal a congestion loss event by introducing a packet loss, as
CE-marking is not guaranteed to be noticed.
This could be done by choosing not to retransmit or repair the
packet loss locally in this case.
Note that one congestion loss per end-to-end RTT is
sufficient to provide the rate reduction, so LOOPS may still be able
to recover most packets, in particular for burst losses.
(As LOOPS does not interact with the end-to-end transport, it does not
know the end-to-end RTT.  Some lower bound derived from configuration
and measurements could be used instead.)
 -->
<!--
The maximum latency increase provided
in the setup information should be able to provide a useful lower
bound for that, though.
 -->
<!-- hash hash Congestion Detection
Properly informing the end-to-end transport protocol about congestion
loss events requires distinguishing these from random losses.
In some special cases, distinguishing information may be available from a link
layer (e.g., see Section 3 of {{I-D.li-tsvwg-loops-problem-opportunities}}).
By enabling ECN inside the tunnel, congestion events experienced at
ECN-capable routers will usually be identified by the CE mark, which
clearly rules out a random loss.
 --> <!--
In the general case, the segment may be composed of hops without such
special indications.
In these cases, some detection mechanism is required to provide
this distinguishing information.
The specific mechanism used by an implementation is out of scope of
LOOPS, but LOOPS will need to provide measurement information for this mechanism.
For instance, congestion detection might be based on path segment
latency information, the proper measurement of which therefore
requires special attention in LOOPS.
 -->
        </t>
      </section>
    </section>
    <section anchor="sec-simply" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-simplifying-assumptions">Simplifying assumptions</name>
      <t pn="section-3-1">The above notwithstanding, Implementations may want to make use of
indicators such as transport layer port numbers to partition a tunnel
flow into separate application flows, e.g., for active queue
management (AQM).  Any such functionality is orthogonal to the LOOPS
protocol itself and thus out of scope for the present document.</t>
      <t pn="section-3-2">One observation that simplifies the design of LOOPS in comparison to
that of a reliable transport protocol is that LOOPS does not <em>have</em> to
recover every packet loss.  Therefore, probabilistic approaches, and
simply giving up after some time has elapsed, can simplify the
protocol significantly.</t>
      <t pn="section-3-3">For now, we assume that LOOPS segments that may line up on an
end-to-end path operate independently of each other.  Since the
objective of LOOPS ultimately is to assist the end-to-end protocol, it
is likely that some cooperation between them would be beneficial,
e.g., to obtain some measurements that cover a larger part of the
end-to-end path.  For instance, cooperating LOOPS segments could try
to divide up permissible increases to end-to-end latency between
them.  This is out of scope for the present version.</t>
      <t pn="section-3-4">Another simplifying assumption is that LOOPS nodes have reasonably
precise absolute time available to them, so there is no need to burden
the LOOPS protocol with time synchronization.  How this is achieved is
out of scope.</t>
      <t pn="section-3-5">LOOPS nodes are created and set up (information about their peers,
parameters) by some control plane mechanism that is out of scope for
this specification.  This means there is no need in the LOOPS protocol
itself to manage setup information.</t>
    </section>
    <section anchor="loops-architecture" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-loops-architecture">LOOPS Architecture</name>
      <t pn="section-4-1">From the above, the following architecture is derived for LOOPS.</t>
      <t pn="section-4-2">LOOPS governs the segment from an ingress node to an egress node,
which is part of one or more end-to-end paths.
Often, a LOOPS segment will operate on aggregate traffic from many
such end-to-end paths.</t>
      <t pn="section-4-3">The LOOPS protocol itself does not define how a LOOPS segment and the
protocol entities in the ingress and egress node are set up.  We
expect that a <em>setup protocol</em> on the control plane will provide some
<em>setup information</em> to the two nodes, including when to start and to
tear down processing.</t>
      <t pn="section-4-4">Each LOOPS segment governs traffic on one direction in the segment.
The LOOPS ingress adds <em>forward information</em> to that traffic; the
LOOPS egress removes the forward information and sends some <em>reverse
information</em> to inform the behavior of the ingress.</t>
      <t pn="section-4-5">Hence, in the data plane, forward information is added to each data
packet.  Reverse information can be sent in separate packets (e.g.,
Geneve control-only packets <xref target="I-D.ietf-nvo3-geneve" format="default" sectionFormat="of" derivedContent="I-D.ietf-nvo3-geneve"/>) and/or piggybacked on a
related, reverse-direction LOOPS flow, similar to the way the
forward information for that flow is carried.  The setup protocol is
used to provide the relationship between the LOOPS segments in the two
directions that is used for piggybacking reverse information.</t>
      <t pn="section-4-6">The above describes the "tunnel mode".  A transparent mode is
described in <xref target="sec-trans" format="default" sectionFormat="of" derivedContent="Appendix B"/>, which does not modify the data packets and
therefore needs to send any forward information (if needed, e.g., for FEC) in
separate packets, usually aggregated.</t>
      <t pn="section-4-7">The LOOPS <em>generic information set</em> defines what information is provided
as setup information, forward information, and reverse information.
<em>Bindings</em> map this information set to specific control plane and data
plane protocols, including defining the specific encoding being used.
Where separate packets (outside the data plane protocols being used)
need to be sent, a special UDP-based protocol needs to be defined as
well.  The various bindings aim for some commonality, so that an
implementation for multiple bindings does not need to support
gratuitous variety between them.</t>
    </section>
    <section anchor="sec-model" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-loops-generic-information-s">LOOPS Generic Information Set</name>
      <t pn="section-5-1">This section sketches a generic information set for the LOOPS
protocol.  Entries marked with (*) are items that may not be necessary
and probably should be left out of an initial specification.</t>
      <section anchor="setup-information" numbered="true" toc="include" removeInRFC="false" pn="section-5.1">
        <name slugifiedName="name-setup-information">Setup Information</name>
        <t pn="section-5.1-1">Setup Information might include:</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-5.1-2">
          <li pn="section-5.1-2.1">encapsulation protocol in use, and its vital parameters</li>
          <li pn="section-5.1-2.2">identity of LOOPS ingress and LOOPS egress; information relevant for
running the encapsulation protocol such as port numbers</li>
          <li pn="section-5.1-2.3">target maximum latency increase caused by the operation of LOOPS on
this segment</li>
          <li pn="section-5.1-2.4">maximum retransmission count (*)</li>
        </ul>
      </section>
      <section anchor="forward-information" numbered="true" toc="include" removeInRFC="false" pn="section-5.2">
        <name slugifiedName="name-forward-information">Forward Information</name>
        <t pn="section-5.2-1">In the forward information, we have identified:</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-5.2-2">
          <li pn="section-5.2-2.1">tunnel type  (a few bits, meaning agreed between Ingress and Egress)</li>
          <li pn="section-5.2-2.2">packet sequence number PSN (20+ bits), counting the data packets forwarded
transmitted by the LOOPS ingress (i.e., retransmissions re-use the PSN)</li>
          <li pn="section-5.2-2.3">an "ACK desirable" flag (one bit, usually set for a certain
percentage of the data packets only)</li>
          <li pn="section-5.2-2.4">an optional blob, to be echoed by the egress</li>
          <li pn="section-5.2-2.5">anything that the FEC scheme needs.</li>
        </ul>
        <t pn="section-5.2-3">The first four together (say, 3+24+4+1) might even fit into 32 bits,
but probably need up to 48 bits total.  FEC info of course often needs
more space.</t>
        <t pn="section-5.2-4">(Note that in this proposal there is no timestamp in the forward
information; see <xref target="sec-meas" format="default" sectionFormat="of" derivedContent="Section 6.3"/>.)</t>
        <t pn="section-5.2-5">24 bits of PSN, minus one bit for sequence number arithmetic, gives 8
million packets (or 2.4 GB at typical packet sizes) per worst-case
RTT.  So if that is, say, 30 seconds, this would be enough to fill 640
Mbit/s.</t>
        <!--
The transmission counter (TC) can be used to remove retransmission
ambiguity in measurement feedback.  (The PSN could be used at the
LOOPS egress for resequencing, which would be thwarted by setting a
new PSN for a retransmission.)  Alternatively, this could be replaced
by a retransmitted bit, or it could be left out altogether with the
ACK desired bit set only for original transmissions.
 -->

</section>
      <section anchor="reverse-information" numbered="true" toc="include" removeInRFC="false" pn="section-5.3">
        <name slugifiedName="name-reverse-information">Reverse Information</name>
        <t pn="section-5.3-1">For the reverse information, we have identified:</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-5.3-2">
          <li pn="section-5.3-2.1">
            <t pn="section-5.3-2.1.1">one optional block 1, possibly repeated:
            </t>
            <ul spacing="normal" bare="false" empty="false" pn="section-5.3-2.1.2">
              <li pn="section-5.3-2.1.2.1">PSN being acknowledged</li>
              <li pn="section-5.3-2.1.2.2">absolute time of reception for the packet acknowledged (PSN)</li>
              <li pn="section-5.3-2.1.2.3">the blob, if present, echoed back</li>
            </ul>
          </li>
          <li pn="section-5.3-2.2">
            <t pn="section-5.3-2.2.1">one optional block 2, possibly repeated:
            </t>
            <ul spacing="normal" bare="false" empty="false" pn="section-5.3-2.2.2">
              <li pn="section-5.3-2.2.2.1">an ACK bitmap (based on PSN), always starting at a multiple of 8</li>
              <li pn="section-5.3-2.2.2.2">a delta indicating the end PSN of the bitmap (actually the first
 PSN that is beyond it), using (Acked-PSN &amp; ~7) + 8*(delta+1) as the
 end of the bitmap.
 Acked-PSN in that formula is the previous block 1 PSN seen in this
 packet, or 0 if none so far.</li>
            </ul>
          </li>
        </ul>
        <t pn="section-5.3-3">Block 1 and Block 2 can be interspersed and repeated.  They can be
piggybacked on a reverse direction data packet or sent separately if
none occurs within some timeout.  They will usually be aggregated in
some useful form.  Block 1 information sets are only returned for
packets that have "ACK desirable" set.  Block 2 information is sent by
the receiver based on some saturation scheme (e.g., at least three
copies for each PSN span over time).  Still, it might be possible to
go down to 1 or 2 amortized bytes per forward packet spent for all
this.</t>
        <t pn="section-5.3-4">The latency calculation is done by the sender, who occasionally sets
"ACK desirable", and notes down the absolute time of transmission for
this data packet (the timekeeping can be done quite
efficiently as deltas).  Upon reception of a block 1 ACK, it can then
subtract that from the absolute time of reception indicated.  This
assumes time synchronization between the nodes is at least as good as
the precision of latency measurement needed, which should be no
problem with IEEE 1588 PTP synchronization (but could be if using NTP-based
synchronization only).  A sender can freely garbage collect noted down
transmission time information; doing this too early just means that
the quality of the RTT sampling will reduce.</t>
      </section>
    </section>
    <section anchor="loops-general-operation" numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-loops-general-operation">LOOPS General Operation</name>
      <t pn="section-6-1">In the Tunnel Mode described in the main body of this document,
LOOPS information is carried by some tunnel encapsulation.</t>
      <section anchor="initial-packet-sequence-number" numbered="true" toc="include" removeInRFC="false" pn="section-6.1">
        <name slugifiedName="name-initial-packet-sequence-num">Initial Packet Sequence Number</name>
        <t pn="section-6.1-1">There is no connection establishment procedure in LOOPS.
The initial PSN is assigned unilaterally by the LOOPS Ingress.</t>
        <t pn="section-6.1-2">Because of the short time that is usually set in the maximum latency
increase, there is little damage from a collision of PSNs with
packets still in flight from previous instances of LOOPS.</t>
        <section anchor="minimizing-collisions" numbered="true" toc="include" removeInRFC="false" pn="section-6.1.1">
          <name slugifiedName="name-minimizing-collisions">Minimizing collisions</name>
          <t pn="section-6.1.1-1">If desired, collisions can be minimized by assigning initial PSNs
randomly, or using stable storage.  Random assignment is more useful
for longer PSNs, where the likelihood of overlap will be low.  The
specific way a LOOPS ingress uses stable storage is a local matter and
thus out of scope.  (Implementation note: this can be made to work
similar to secure nonce generation with write attenuation: Say, every
10000 packets, the sender notes down the PSN into stable storage.
After a reboot, it reloads the PSN and adds 10000 in sequence number
arithmetic <xref target="RFC1982" format="default" sectionFormat="of" derivedContent="RFC1982"/>, plus maybe another 10000 so the sender does
not have to wait for the store operation to succeed before sending
more packets.)</t>
        </section>
        <section anchor="optional-initial-psn-procedure" numbered="true" toc="include" removeInRFC="false" pn="section-6.1.2">
          <name slugifiedName="name-optional-initial-psn-proced">Optional Initial PSN procedure</name>
          <t pn="section-6.1.2-1">As a potential option (to be discussed), an initial packet sequence
number could be communicated using a simple two-bit protocol, based on
an I flag (Initial PSN) carried in the forward information and an R
flag (Initial PSN Received) in the reverse information.  This
procedure essentially clears the egress of any previous state,
however, the benefits of this procedure are limited.</t>
          <t pn="section-6.1.2-2">The initial PSN is assigned unilaterally by the LOOPS ingress,
selected randomly.
The ingress will keep setting the I flag to one when it
starts to send packets from a new beginning or whenever it believes there is
a need to notify the egress about a new initial PSN.
The ingress will stop setting the I flag when it receives an
acknowledgement with the R flag set from the egress.</t>
          <t pn="section-6.1.2-3">When the LOOPS egress receives a packets with the I flag set, it stops
performing services that assume a sequential PSN.  The egress will no
longer provide acknowledgement information for the packets with PSN
smaller than this new initial PSN (per sequence number arithmetic
<xref target="IEN74" format="default" sectionFormat="of" derivedContent="IEN74"/>).  The egress sends acknowledgement information back without
any delay by echoing the value of the I flag in the R flag.  This also
means the egress unsets the R flag in subsequent acknowledgements for
packets with the I flag unset.</t>
          <t pn="section-6.1.2-4">It may happen that the first few packets are lost in an initial PSN
assignment process. In this case, the loss of these packets is not
detectable by the LOOPS ingress since the first received PSN will be
treated as an initial PSN at the egress.  This is an acceptable
temporary performance degradation: LOOPS does not intend to provide
perfect reliability, and LOOPS usually applies to the aggregated
traffic over a tunnel so that the initial PSN assignment happens
infrequently.</t>
        </section>
      </section>
      <section anchor="acknowledgement-generation" numbered="true" toc="include" removeInRFC="false" pn="section-6.2">
        <name slugifiedName="name-acknowledgement-generation">Acknowledgement Generation</name>
        <t pn="section-6.2-1">A data packet forwarded by the LOOPS ingress always carries PSN
information. The LOOPS egress uses the largest newly received PSN with
the "ACK desired" bit as the ACK number in the block 1 part of the
acknowledgement.  This means that the LOOPS ingress gets to modulate
the number of acknowledgement sent by the LOOPS egress.  However,
whenever an out-of-order packet arrives while there still are "holes"
in the PSNs received, the LOOPS receiver should generate a block 2
acknowledgement immediately that the LOOPS sender can use as an ACK list.</t>
        <t pn="section-6.2-2">Reverse information can be piggybacked in a reverse direction data packet.
When the reverse direction has no user data to be sent, a pure reverse
information packet needs to be generated.  This may be based on a
short delay during which the LOOPS egress waits for a data packet to
piggyback on.  (To reduce MTU considerations, the egress could wait
for less-than-full data packets.)</t>
      </section>
      <section anchor="sec-meas" numbered="true" toc="include" removeInRFC="false" pn="section-6.3">
        <name slugifiedName="name-measurement">Measurement</name>
        <t pn="section-6.3-1">When sending a block 1 acknowledgement, the LOOPS egress indicates the
absolute time of reception of the packet.  The LOOPS ingress can
subtract the absolute time of transmission that it still has
available, resulting in one high quality latency sample.
(In an alternative design, the forward information could include the
absolute time of transmission as well, and block1 information would echo it
back.  This trades memory management at the ingress for increased
bandwidth and MTU reduction.)</t>
        <t pn="section-6.3-2">When a data packet has been transmitted, it may not be clear which
specific copy is acknowledged in a block 1 acknowledgement: the
acknowledgement for the initial (or, more generally, an earlier) copy
may have been delayed (ACK ambiguity)).  The LOOPS ingress therefore
SHOULD NOT base its measurements on acknowledgements for retransmitted
data packets.  One way to achieve this is by not setting the "ACK
desired" bit on retransmissions in the first place.</t>
        <t pn="section-6.3-3">The LOOPS ingress can also use the time of reception of the block 1
acknowledgement to obtain a segment RTT sample.  Note that this will
include any wait time the LOOPS egress incurs while waiting for a
piggybacking opportunity -- this is appropriate, as all uses of an
RTT will be for keeping a retransmission timeout.</t>
        <t pn="section-6.3-4">To maintain quality of information during idle times, the LOOPS
ingress may send keepalive packets, which are discarded at the LOOPS
egress after sending acknowledgements.  The indication that a packet
is a keepalive packet is dependent on the encapsulation protocol.</t>
        <section anchor="ingress-relative-timestamps" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.1">
          <name slugifiedName="name-ingress-relative-timestamps">Ingress-relative timestamps</name>
          <t pn="section-6.3.1-1">As an optional procedure, the ingress node can attach a small blob of
data to a forward packet that carries an ACK desired flag; this blob
is then echoed by the egress in its block 1 acknowledgement.
This is typically used to attach a timestamp on a time scale defined
by the ingress; we speak of an ingress-relative timestamp.
Alternatively, the ingress can keep a timestamp in its local storage,
associated with the PSN of the packet that carries an ACK desired
flag; it can then retrieve this timestamp when the block 1
acknowledgement arrives.</t>
          <t pn="section-6.3.1-2">In either case, the LOOPS ingress keeps track of the local segment
round trip time (LRTT) based on the (saved or received) timestamp and
the arrival time of the block 1 acknowledgement, by setting the ACK
Desired flag (D flag) occasionally (several times per RTT) and
saving/including a sending timestamp for/in the packet.</t>
          <t pn="section-6.3.1-3">As the egress will send block 1 acknowledgement information right away
when it receives a packet with the D flag set, the measurement of LRTT
is more accurate for such packets.
A smoothed local segment round trip time S_LRTT can be computed in a
similar way as defined by <xref target="RFC0793" format="default" sectionFormat="of" derivedContent="RFC0793"/>. A recent minimum value of LRTT
is also kept as min_LRTT.  S_LRTT is used as a basis for the overall
timing of retransmission and state management.</t>
          <t pn="section-6.3.1-4">Retransmitted packets MUST NOT be used for local segment round trip
time (LRTT) calculation.</t>
        </section>
        <section anchor="ack-generation" numbered="true" toc="include" removeInRFC="false" pn="section-6.3.2">
          <name slugifiedName="name-ack-generation">ACK generation</name>
          <t pn="section-6.3.2-1">A block 1 acknowledgement is generated based on receiving a forward
packet with a D flag.</t>
          <t pn="section-6.3.2-2">The way block 2 acknowledgement information is sent is more subject to
control by the egress.  Generally, the egress will aggregate ACK
bits for at least K packets before sending a block 2; this can be used
to amortize the overhead to close to a couple of bits per ACK.  In
order to counter loss of reverse information packets, an egress will
also want to send an ACK bit more than once -- a saturation value of
3 or more may be chosen based on setup information.  Typically, ACK
bits already sent will be prepended to ACK bits that are new in this
block 2 information set.
If K packets do not accumulate for a while, the egress will send one
or more packets with block 2 information that covers the unsent ACK
bits it has so far.</t>
          <t pn="section-6.3.2-3">(Discussion: This works best if the egress has information both about
the S_RTT and min_RTT that the ingress uses and the reverse packet
loss rate.)</t>
        </section>
      </section>
      <section anchor="loss-detection-and-recovery" numbered="true" toc="include" removeInRFC="false" pn="section-6.4">
        <name slugifiedName="name-loss-detection-and-recovery">Loss detection and Recovery</name>
        <t pn="section-6.4-1">There are two ways for LOOPS local recovery, retransmission and FEC.</t>
        <section anchor="local-retransmission" numbered="true" toc="include" removeInRFC="false" pn="section-6.4.1">
          <name slugifiedName="name-local-retransmission">Local Retransmission</name>
          <t pn="section-6.4.1-1">When retransmission is used as recovery mechanism, the LOOPS ingress
detects a packet loss by not receiving an ACK for the packet within
the time expected based on an RTO value (which might be calculated as
in <xref target="RFC6298" format="default" sectionFormat="of" derivedContent="RFC6298"/>).  Packet retransmission should then not be performed more
than once within an LRTT.</t>
          <t pn="section-6.4.1-2">When a retransmission is desired<!-- (see {{sec-cc}} for why it might not
be)  -->, the LOOPS ingress performs the local in-network recovery by
retransmitting the packet.  Further retransmissions may be desirable
if the lack of ACK is persistent beyond an RTO, as long as the maximum
latency increase is not reached.</t>
        </section>
        <section anchor="fec" numbered="true" toc="include" removeInRFC="false" pn="section-6.4.2">
          <name slugifiedName="name-fec">FEC</name>
          <t pn="section-6.4.2-1">FEC is another way to perform local recovery.  When FEC is in use, a
FEC header is sent with data packets as well as with special repair
packets added to the flow.  The specific FEC scheme used could be
defined in the Setup Information, using a mechanism like <xref target="RFC5052" format="default" sectionFormat="of" derivedContent="RFC5052"/>.
The FEC rate (amount of redundancy added) and possibly the FEC scheme
could be unilaterally adjusted by the LOOPS ingress in an adaptive
mechanism based on the measurement information.</t>
        </section>
      </section>
      <section anchor="discussion" numbered="true" toc="include" removeInRFC="false" pn="section-6.5">
        <name slugifiedName="name-discussion">Discussion</name>
        <t pn="section-6.5-1">Without progress in the way that end-host transport protocols handle
reordering, LOOPS will be unable to prevent end-to-end retransmissions
that duplicate effort that is spent in local retransmissions.
It depends on parameters of the path segment whether this wasted
effort is significant or not.</t>
        <t pn="section-6.5-2">One remedy against this waste could be the
introduction of resequencing at the LOOPS Egress node.  This increases
overall mean packet latency, but does not always increase actual
end-to-end data stream latency if a head-of-line blocking transport
such as TCP is in use.  For applications with a large percentage of
legacy TCP end-hosts and sufficient processing capabilities at the
LOOPS Egress node, resequencing may be a viable choice.  Note that
resequencing could be switched off and on depending on some
measurement information.</t>
        <t pn="section-6.5-3">The packet numbering scheme chosen by LOOPS already provides the
necessary information for the LOOPS Egress to reconstruct the sequence
of data packets at the LOOPS ingress.</t>
      </section>
    </section>
    <section anchor="sec-sketches" numbered="true" toc="include" removeInRFC="false" pn="section-7">
      <name slugifiedName="name-sketches-of-bindings-to-tun">Sketches of Bindings to Tunnel Protocols</name>
      <t pn="section-7-1">The LOOPS information defined above in a generic way can be mapped to
specific tunnel encapsulation protocols.  A sketch for the tunnel
protocol Geneve is given below (<xref target="sec-geneve" format="default" sectionFormat="of" derivedContent="Section 7.1"/>).
The actual encapsulation can be designed in a "native"
way by putting each of the various elements into the TLV format of the
encapsulation protocol, or it can be achieved by providing single
TLVs for forward and reverse information and using some generic
encoding of both kinds of information as shown in <xref target="hybrid" format="default" sectionFormat="of" derivedContent="Appendix B.3"/>.</t>
      <section anchor="sec-geneve" numbered="true" toc="include" removeInRFC="false" pn="section-7.1">
        <name slugifiedName="name-embedding-loops-in-geneve">Embedding LOOPS in Geneve</name>
        <t pn="section-7.1-1">Geneve <xref target="I-D.ietf-nvo3-geneve" format="default" sectionFormat="of" derivedContent="I-D.ietf-nvo3-geneve"/> is an extensible overlay protocol
which can embed LOOPS functions. Geneve uses TLVs to carry optional
information between NVEs.  NVE is logically the same entity as the
LOOPS node.</t>
        <t pn="section-7.1-2">The Geneve header has a mandatory Virtual Network Identifier (VNI)
field. The specific VNI value to be used is part of the setup
information for the LOOPS tunnel.</t>
        <t pn="section-7.1-3">More details for a Geneve binding for LOOPS can be found in <xref target="I-D.bormann-loops-geneve-binding" format="default" sectionFormat="of" derivedContent="I-D.bormann-loops-geneve-binding"/>.</t>
        <!--
## Embedding LOOPS in GUE {#sec-gue}

GUE {{-gue}} is an extensible overlay protocol which
can embed LOOPS functions. GUE uses flags to indicate the presence of
fixed length header extensions. It also allows variable length
extensions to be put in "Private data" field. A new LOOPS data block
in the "private data" field needs to be defined based on the LOOPS
generic information in {{sec-model}}.

In the reverse direction, when no data packets are available for
piggybacking, LOOPS reverse information is carried in a control
message with the C-bit set in the GUE header.  The Proto/ctype field
contains a control message type when C bit is set.  Hence a new
control message type should be defined for such LOOPS reverse
information.
 -->

</section>
    </section>
    <section anchor="iana-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-8">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t pn="section-8-1">No IANA action is required at this stage.  When a LOOPS representation
is designed for a specific tunneling protocol, new codepoints will be
required in the registries that pertain to that protocol.</t>
    </section>
    <section anchor="security-considerations" numbered="true" toc="include" removeInRFC="false" pn="section-9">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t pn="section-9-1">The security of a specific LOOPS segment will depend both on the
properties of the generic information set described here and those of
the encapsulation protocol employed.  The security considerations of
the encapsulation protocol will apply, as will the protection afforded
by any security measures provided by the encapsulation protocol.
Any LOOPS encapsulation specification is expected to provide
information about preferred configurations of the encapsulation
protocol employed, including security mechanisms, and to provide a
security considerations section discussing the combination.
The following discussion aims at discussing security considerations
that will be common between different encapsulations.</t>
      <section anchor="threat-model" numbered="true" toc="include" removeInRFC="false" pn="section-9.1">
        <name slugifiedName="name-threat-model">Threat model</name>
        <t pn="section-9.1-1">Attackers might attempt to perturb the operation of a LOOPS segment
for a number of purposes:</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-9.1-2">
          <li pn="section-9.1-2.1">Denial of Service: Damaging the ability of LOOPS to recover packets,
or damaging packet forwarding through the LOOPS segment in general.</li>
          <li pn="section-9.1-2.2">Attacks on Confidentiality or Integrity: Obtaining the content of
data packets, modifying them, injecting new or suppressing specific
data packets.</li>
        </ul>
        <t pn="section-9.1-3">For the purposes of these security considerations, we can distinguish
three classes of attackers:</t>
        <ol spacing="normal" type="1" start="1" pn="section-9.1-4">
          <li pn="section-9.1-4.1" derivedCounter="1.">
            <t pn="section-9.1-4.1.1">on-path read-write: The attacker sees packets under way on the
segment and can modify, inject, or suppress them.  </t>
            <t pn="section-9.1-4.1.2">
In this case there is really nothing LOOPS can do, except for
acting as a full security protocol on its own, which would be the
task of the encapsulation protocol.  Without that, attackers
already can manipulate the packet stream as they wish.  This class
of attackers is considered out of scope for these security
considerations.</t>
          </li>
          <li pn="section-9.1-4.2" derivedCounter="2.">
            <t pn="section-9.1-4.2.1">on-path read + inject: The attacker sees packets under way on the
segment and can inject new packets.  </t>
            <t pn="section-9.1-4.2.2">
For this case, LOOPS itself similarly cannot add to the
confidentiality of the data stream.  However, LOOPS could protect
against denial of service against its own protocol operation and,
in a limited fashion, against attacks on integrity that wouldn't
already have been possible by packet injection without LOOPS.</t>
          </li>
          <li pn="section-9.1-4.3" derivedCounter="3.">
            <t pn="section-9.1-4.3.1">off-path inject: The attacker can inject new packets, but cannot
see existing packets under way on the segment.  </t>
            <t pn="section-9.1-4.3.2">
Similar considerations apply as for class 2, except that the
"blind" class 3 attacker might need to guess information it could
have extracted from the packet stream in class 2.</t>
          </li>
        </ol>
      </section>
      <section anchor="discussion-1" numbered="true" toc="include" removeInRFC="false" pn="section-9.2">
        <name slugifiedName="name-discussion-2">Discussion</name>
        <t pn="section-9.2-1">Class 2 attackers can see e.g. sequence numbers and can inject, but
not modify traffic.  Attacks might include injecting false ACKs, initial
PSN flags, ... (TBD)</t>
        <t pn="section-9.2-2">Class 3 ("blind") attackers might still be able to fake initial PSN
bits + false ACKs, but will have a harder time otherwise as it would need
to guess the PSN range in which it can wreak havoc.  Even random
guesses will sometimes hit, though, so the protocol needs to be robust
to such injection attacks. ... (TBD)</t>
      </section>
    </section>
  </middle>
  <back>
    <references pn="section-10">
      <name slugifiedName="name-references">References</name>
      <references pn="section-10.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="BCP" value="14"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="BCP" value="14"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
        </reference>
      </references>
      <references pn="section-10.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="RFC0793" target="https://www.rfc-editor.org/info/rfc793" quoteTitle="true" derivedAnchor="RFC0793">
          <front>
            <title>Transmission Control Protocol</title>
            <seriesInfo name="STD" value="7"/>
            <seriesInfo name="RFC" value="793"/>
            <seriesInfo name="DOI" value="10.17487/RFC0793"/>
            <author initials="J." surname="Postel" fullname="J. Postel">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1981" month="September"/>
          </front>
        </reference>
        <reference anchor="RFC1982" target="https://www.rfc-editor.org/info/rfc1982" quoteTitle="true" derivedAnchor="RFC1982">
          <front>
            <title>Serial Number Arithmetic</title>
            <seriesInfo name="RFC" value="1982"/>
            <seriesInfo name="DOI" value="10.17487/RFC1982"/>
            <author initials="R." surname="Elz" fullname="R. Elz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Bush" fullname="R. Bush">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1996" month="August"/>
            <abstract>
              <t>The DNS has long relied upon serial number arithmetic, a concept which has never really been defined, certainly not in an IETF document, though which has been widely understood.  This memo supplies the missing definition.  It is intended to update RFC1034 and RFC1035.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC3708" target="https://www.rfc-editor.org/info/rfc3708" quoteTitle="true" derivedAnchor="RFC3708">
          <front>
            <title>Using TCP Duplicate Selective Acknowledgement (DSACKs) and Stream Control Transmission Protocol (SCTP) Duplicate Transmission Sequence Numbers (TSNs) to Detect Spurious Retransmissions</title>
            <seriesInfo name="RFC" value="3708"/>
            <seriesInfo name="DOI" value="10.17487/RFC3708"/>
            <author initials="E." surname="Blanton" fullname="E. Blanton">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Allman" fullname="M. Allman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="February"/>
            <abstract>
              <t>TCP and Stream Control Transmission Protocol (SCTP) provide notification of duplicate segment receipt through Duplicate Selective Acknowledgement (DSACKs) and Duplicate Transmission Sequence Number (TSN) notification, respectively.  This document presents conservative methods of using this information to identify unnecessary retransmissions for various applications.  This memo defines an Experimental Protocol for the Internet community.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5052" target="https://www.rfc-editor.org/info/rfc5052" quoteTitle="true" derivedAnchor="RFC5052">
          <front>
            <title>Forward Error Correction (FEC) Building Block</title>
            <seriesInfo name="RFC" value="5052"/>
            <seriesInfo name="DOI" value="10.17487/RFC5052"/>
            <author initials="M." surname="Watson" fullname="M. Watson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Luby" fullname="M. Luby">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Vicisano" fullname="L. Vicisano">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2007" month="August"/>
            <abstract>
              <t>This document describes how to use Forward Error Correction (FEC) codes to efficiently provide and/or augment reliability for bulk data transfer over IP multicast.  This document defines a framework for the definition of the information that needs to be communicated in order to use an FEC code for bulk data transfer, in addition to the encoded data itself, and for definition of formats and codes for communication of that information.  Both information communicated with the encoded data itself and information that needs to be communicated 'out-of-band' are considered.  The procedures for specifying new FEC codes, defining the information communication requirements associated with those codes and registering them with the Internet Assigned Numbers Authority (IANA) are also described.  The requirements on Content Delivery Protocols that wish to use FEC codes defined within this framework are also defined.  The companion document titled "The Use of Forward Error Correction (FEC) in Reliable Multicast" describes some applications of FEC codes for delivering content. This document obsoletes RFC 3452.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5862" target="https://www.rfc-editor.org/info/rfc5862" quoteTitle="true" derivedAnchor="RFC5862">
          <front>
            <title>Path Computation Clients (PCC) - Path Computation Element (PCE) Requirements for Point-to-Multipoint MPLS-TE</title>
            <seriesInfo name="RFC" value="5862"/>
            <seriesInfo name="DOI" value="10.17487/RFC5862"/>
            <author initials="S." surname="Yasukawa" fullname="S. Yasukawa">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Farrel" fullname="A. Farrel">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="June"/>
            <abstract>
              <t>The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks.</t>
              <t>Extensions to the MPLS and GMPLS signaling and routing protocols have been made in support of point-to-multipoint (P2MP) Traffic Engineered (TE) Label Switched Paths (LSPs).  The use of PCE in MPLS networks is already established, and since P2MP TE LSP routes are sometimes complex to compute, it is likely that PCE will be used for P2MP LSPs.</t>
              <t>Generic requirements for a communication protocol between Path Computation Clients (PCCs) and PCEs are presented in RFC 4657, "Path Computation Element (PCE) Communication Protocol Generic Requirements".  This document complements the generic requirements and presents a detailed set of PCC-PCE communication protocol requirements for point-to-multipoint MPLS/GMPLS traffic engineering. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6040" target="https://www.rfc-editor.org/info/rfc6040" quoteTitle="true" derivedAnchor="RFC6040">
          <front>
            <title>Tunnelling of Explicit Congestion Notification</title>
            <seriesInfo name="RFC" value="6040"/>
            <seriesInfo name="DOI" value="10.17487/RFC6040"/>
            <author initials="B." surname="Briscoe" fullname="B. Briscoe">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="November"/>
            <abstract>
              <t>This document redefines how the explicit congestion notification (ECN) field of the IP header should be constructed on entry to and exit from any IP-in-IP tunnel.  On encapsulation, it updates RFC 3168 to bring all IP-in-IP tunnels (v4 or v6) into line with RFC 4301 IPsec ECN processing.  On decapsulation, it updates both RFC 3168 and RFC 4301 to add new behaviours for previously unused combinations of inner and outer headers.  The new rules ensure the ECN field is correctly propagated across a tunnel whether it is used to signal one or two severity levels of congestion; whereas before, only one severity level was supported.  Tunnel endpoints can be updated in any order without affecting pre-existing uses of the ECN field, thus ensuring backward compatibility.  Nonetheless, operators wanting to support two severity levels (e.g., for pre-congestion notification -- PCN) can require compliance with this new specification.  A thorough analysis of the reasoning for these changes and the implications is included.  In the unlikely event that the new rules do not meet a specific need, RFC 4774 gives guidance on designing alternate ECN semantics, and this document extends that to include tunnelling issues.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6298" target="https://www.rfc-editor.org/info/rfc6298" quoteTitle="true" derivedAnchor="RFC6298">
          <front>
            <title>Computing TCP's Retransmission Timer</title>
            <seriesInfo name="RFC" value="6298"/>
            <seriesInfo name="DOI" value="10.17487/RFC6298"/>
            <author initials="V." surname="Paxson" fullname="V. Paxson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Allman" fullname="M. Allman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Chu" fullname="J. Chu">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Sargent" fullname="M. Sargent">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="June"/>
            <abstract>
              <t>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC6330" target="https://www.rfc-editor.org/info/rfc6330" quoteTitle="true" derivedAnchor="RFC6330">
          <front>
            <title>RaptorQ Forward Error Correction Scheme for Object Delivery</title>
            <seriesInfo name="RFC" value="6330"/>
            <seriesInfo name="DOI" value="10.17487/RFC6330"/>
            <author initials="M." surname="Luby" fullname="M. Luby">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Shokrollahi" fullname="A. Shokrollahi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Watson" fullname="M. Watson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T." surname="Stockhammer" fullname="T. Stockhammer">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Minder" fullname="L. Minder">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="August"/>
            <abstract>
              <t>This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.</t>
              <t>RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053.  RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data.  The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.</t>
              <t>The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8610" target="https://www.rfc-editor.org/info/rfc8610" quoteTitle="true" derivedAnchor="RFC8610">
          <front>
            <title>Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures</title>
            <seriesInfo name="RFC" value="8610"/>
            <seriesInfo name="DOI" value="10.17487/RFC8610"/>
            <author initials="H." surname="Birkholz" fullname="H. Birkholz">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Vigano" fullname="C. Vigano">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Bormann" fullname="C. Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2019" month="June"/>
            <abstract>
              <t>This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049).  Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8087" target="https://www.rfc-editor.org/info/rfc8087" quoteTitle="true" derivedAnchor="RFC8087">
          <front>
            <title>The Benefits of Using Explicit Congestion Notification (ECN)</title>
            <seriesInfo name="RFC" value="8087"/>
            <seriesInfo name="DOI" value="10.17487/RFC8087"/>
            <author initials="G." surname="Fairhurst" fullname="G. Fairhurst">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Welzl" fullname="M. Welzl">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="March"/>
            <abstract>
              <t>The goal of this document is to describe the potential benefits of applications using a transport that enables Explicit Congestion Notification (ECN).  The document outlines the principal gains in terms of increased throughput, reduced delay, and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking.  It also discusses challenges for successful deployment of ECN.  It does not propose new algorithms to use ECN nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers, or other network devices.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="I-D.ietf-tcpm-rack" target="http://www.ietf.org/internet-drafts/draft-ietf-tcpm-rack-08.txt" quoteTitle="true" derivedAnchor="I-D.ietf-tcpm-rack">
          <front>
            <title>RACK: a time-based fast loss detection algorithm for TCP</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-rack-08"/>
            <author initials="Y" surname="Cheng" fullname="Yuchung Cheng">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N" surname="Cardwell" fullname="Neal Cardwell">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N" surname="Dukkipati" fullname="Nandita Dukkipati">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="P" surname="Jha" fullname="Priyaranjan Jha">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="March" day="9" year="2020"/>
            <abstract>
              <t>This document presents a new TCP loss detection algorithm called RACK ("Recent ACKnowledgment").  RACK uses the notion of time, instead of packet or sequence counts, to detect losses, for modern TCP implementations that can support per-packet timestamps and the selective acknowledgment (SACK) option.  It is intended to be an alternative to the DUPACK threshold approach [RFC6675], as well as other nonstandard approaches such as FACK [FACK].</t>
            </abstract>
          </front>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-nvo3-geneve" target="http://www.ietf.org/internet-drafts/draft-ietf-nvo3-geneve-16.txt" quoteTitle="true" derivedAnchor="I-D.ietf-nvo3-geneve">
          <front>
            <title>Geneve: Generic Network Virtualization Encapsulation</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-nvo3-geneve-16"/>
            <author initials="J" surname="Gross" fullname="Jesse Gross">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="I" surname="Ganga" fullname="Ilango Ganga">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="T" surname="Sridhar" fullname="T. Sridhar">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="March" day="7" year="2020"/>
            <abstract>
              <t>Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters.  As a result of their role in tying together different elements in the system, the requirements on tunnels are influenced by all of these components.  Flexibility is therefore the most important aspect of a tunnel protocol if it is to keep pace with the evolution of the system.  This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.</t>
            </abstract>
          </front>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.li-tsvwg-loops-problem-opportunities" target="http://www.ietf.org/internet-drafts/draft-li-tsvwg-loops-problem-opportunities-05.txt" quoteTitle="true" derivedAnchor="I-D.li-tsvwg-loops-problem-opportunities">
          <front>
            <title>LOOPS (Localized Optimizations on Path Segments) Problem Statement and Opportunities for Network-Assisted Performance Enhancement</title>
            <seriesInfo name="Internet-Draft" value="draft-li-tsvwg-loops-problem-opportunities-05"/>
            <author initials="L" surname="Yizhou" fullname="Li Yizhou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="X" surname="Zhou" fullname="Xingwang Zhou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M" surname="Boucadair" fullname="Mohamed Boucadair">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J" surname="Wang" fullname="Jianglong Wang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F" surname="Qin" fullname="Fengwei Qin">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="July" day="6" year="2020"/>
            <abstract>
              <t>In various network deployments, end to end forwarding paths are partitioned into multiple segments.  For example, in some cloud-based WAN communications, stitching multiple overlay tunnels are used for traffic policy enforcement matters such as to optimize traffic distribution or to select paths exposing a lower latency.  Likewise, in satellite communications, the communication path is decomposed into two terrestrial segments and a satellite segment.  Such long- haul paths are naturally composed of multiple network segments with various encapsulation schemes.  Packet loss may show different characteristics on different segments.  Traditional transport protocols (e.g., TCP) respond to packet loss slowly especially in long-haul networks: they either wait for some signal from the receiver to indicate a loss and then retransmit from the sender or rely on sender's timeout which is often quite long. Non-congestive loss may make the TCP sender over-reduce the sending rate unnecessarily.  With the increase of end-to-end transport encryption (e.g., QUIC), traditional PEP (performance enhancing proxy) techniques such as TCP splitting are no longer applicable.  LOOPS (Local Optimizations on Path Segments) is a network-assisted performance enhancement over path segment and it aims to provide local in-network recovery to achieve better data delivery by making packet loss recovery faster and by avoiding the senders over-reducing their sending rate.  In an overlay network scenario, LOOPS can be performed over a variety of the existing, or purposely created, tunnel-based path segments.</t>
            </abstract>
          </front>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.ietf-tsvwg-tunnel-congestion-feedback" target="http://www.ietf.org/internet-drafts/draft-ietf-tsvwg-tunnel-congestion-feedback-07.txt" quoteTitle="true" derivedAnchor="I-D.ietf-tsvwg-tunnel-congestion-feedback">
          <front>
            <title>Tunnel Congestion Feedback</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-tunnel-congestion-feedback-07"/>
            <author initials="X" surname="Wei" fullname="Xinpeng Wei">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L" surname="Yizhou" fullname="Li Yizhou">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S" surname="Boutros" fullname="Sami Boutros">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L" surname="Geng" fullname="Liang Geng">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" day="5" year="2019"/>
            <abstract>
              <t>This document describes a method to measure congestion on a tunnel segment based on recommendations from RFC 6040, "Tunneling of Explicit Congestion Notification", and to use IPFIX to communicate the congestion measurements from the tunnel's egress to a controller which can respond by modifying the traffic control policies at the tunnel's ingress.</t>
            </abstract>
          </front>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="I-D.bormann-loops-geneve-binding" target="http://www.ietf.org/internet-drafts/draft-bormann-loops-geneve-binding-01.txt" quoteTitle="true" derivedAnchor="I-D.bormann-loops-geneve-binding">
          <front>
            <title>Embedding LOOPS in Geneve</title>
            <seriesInfo name="Internet-Draft" value="draft-bormann-loops-geneve-binding-01"/>
            <author initials="C" surname="Bormann" fullname="Carsten Bormann">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="June" day="12" year="2020"/>
            <abstract>
              <t>LOOPS (Local Optimizations on Path Segments) aims to provide local in-network loss recovery.  It can be used with tunneling protocols to efficiently recover lost packets on a single segment of an end-to-end path instead of leaving recovery to the end-to-end protocol, traversing the entire path.  [I-D.welzl-loops-gen-info] defines the information to be carried between LOOPS ingress and egress nodes in a generic way, giving a guideline on defining the common elements to embed LOOPS functions in various tunnel protocols.  The present document specifies how to embed LOOPS in the overlay tunnel protocol chosen for the initial LOOPS specification, Geneve [I-D.ietf-nvo3-geneve].</t>
            </abstract>
          </front>
          <refcontent>Work in Progress</refcontent>
        </reference>
        <reference anchor="IEN74" quoteTitle="true" derivedAnchor="IEN74">
          <front>
            <title>Sequence Number Arithmetic</title>
            <seriesInfo name="Internet Experiment Note" value="74"/>
            <author initials="W.W." surname="Plummer" fullname="William W. Plummer">
              <organization showOnFrontPage="true">BB&amp;N Inc</organization>
            </author>
            <date year="1978" month="September"/>
          </front>
        </reference>
      </references>
    </references>
    <section anchor="sec-proto" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-protocol-used-in-prototype-">Protocol used in Prototype Implementation</name>
      <t pn="section-appendix.a-1">This appendix describes, in a somewhat abstracted form, the protocol
as used in a prototype implementation, as described by Yizhou Li, and
Xingwang Zhou.</t>
      <t pn="section-appendix.a-2">The prototype protocol can be run in one of two modes (defined by
preconfiguration):</t>
      <ul spacing="normal" bare="false" empty="false" pn="section-appendix.a-3">
        <li pn="section-appendix.a-3.1">Retransmission mode</li>
        <li pn="section-appendix.a-3.2">Forward Error Correction (FEC) mode</li>
      </ul>
      <t pn="section-appendix.a-4">Forward information is piggybacked in data packets.</t>
      <t pn="section-appendix.a-5">Reverse information can be carried in a pure acknowledgement packet or
piggybacked when carrying packets for the inverse direction.</t>
      <t pn="section-appendix.a-6">The forward information includes:</t>
      <ul spacing="normal" bare="false" empty="false" pn="section-appendix.a-7">
        <li pn="section-appendix.a-7.1">Packet Sequence Number (PSN) (32 bits): This identifies a packet
over a specific overlay segment from a specific LOOPS Ingress.  If a
packet is retransmitted by LOOPS, the retransmission uses the
original PSN.</li>
        <li pn="section-appendix.a-7.2">Timestamp (32 bits): Information, in a format local to the LOOPS
ingress, that provides the time when the packet was sent.  In the
current implementation, a 32-bit unsigned value specifying the time
delta in some granularity from the epoch time to the sending time of
the packet carrying this timestamp. The granularity can be from 1 ms
to 1 second. The epoch time follows the current TCP practice which
is 1 January 1970 00:00:00 UTC.  Note that a retransmitted packet
uses its own Timestamp.</li>
        <li pn="section-appendix.a-7.3">FEC Info for Block Code (56 bits): This header is used in FEC mode.
It currently only provides for a block code FEC scheme.  It includes
the Source Block Number (SBN), Encoding Symbol ID (ESI), number of
symbols in a single source block and symbol size. <xref target="sec-fec" format="default" sectionFormat="of" derivedContent="Appendix A.1"/> gives
more details on FEC.</li>
      </ul>
      <t pn="section-appendix.a-8">The reverse information includes:</t>
      <ul spacing="normal" bare="false" empty="false" pn="section-appendix.a-9">
        <li pn="section-appendix.a-9.1">ACK Number (32 bits): The largest (in sequence number arithmetic
<xref target="RFC1982" format="default" sectionFormat="of" derivedContent="RFC1982"/>) PSN received so far.</li>
        <li pn="section-appendix.a-9.2">ACK List (variable): This indicates an array of PSN numbers to
describe the PSN "holes" preceding the ACK number. It conceptually
lists the PSNs of every packet perceived as lost by the LOOPS
egress.  In actual use, it is truncated.</li>
        <li pn="section-appendix.a-9.3">Echoed Timestamp (32 bits): The timestamp received with the packet
being acknowledged.</li>
      </ul>
      <section anchor="sec-fec" numbered="true" toc="include" removeInRFC="false" pn="section-a.1">
        <name slugifiedName="name-block-code-fec">Block Code FEC</name>
        <t pn="section-a.1-1">The prototype currently uses a block code FEC scheme (RaptorQ
<xref target="RFC6330" format="default" sectionFormat="of" derivedContent="RFC6330"/>).  The fields in the FEC Info forward information are:</t>
        <ul spacing="normal" bare="false" empty="false" pn="section-a.1-2">
          <li pn="section-a.1-2.1">Source Block Number (SBN): 16 bits. An integer identifier for the
source block that the encoding symbols within the packet relate to.</li>
          <li pn="section-a.1-2.2">Encoding Symbol ID (ESI): 16 bits. An integer identifier for the
encoding symbols within the packet.</li>
          <li pn="section-a.1-2.3">K: 8 bits. Number of symbols in a single source block.</li>
          <li pn="section-a.1-2.4">T: 16 bits. Symbol size in bytes.</li>
        </ul>
        <t pn="section-a.1-3">The LOOPS Ingress uses the data packet in <xref target="fig-loops-packet" format="default" sectionFormat="of" derivedContent="Figure 1"/> to
generate the encoding packet.  Both source packets and repair packets
carry the FEC header information; the LOOPS Egress reconstructs the
data packets from both kinds of packets.  The LOOPS Egress currently
resequences the forwarded and reconstructed packets, so they are
passed on in-order when the lost packets are recoverable within the
source block.</t>
        <t pn="section-a.1-4">The LOOPS Nodes need to agree on the use of FEC block mode and on the
specific FEC Encoding ID to use; this is currently done by
configuration.</t>
      </section>
    </section>
    <section anchor="sec-trans" numbered="true" toc="include" removeInRFC="false" pn="section-appendix.b">
      <name slugifiedName="name-transparent-mode">Transparent mode</name>
      <t pn="section-appendix.b-1">This appendix defines a very different way to provide
the LOOPS services, "transparent mode".  (We call the protocol
described in the main body of the document "encapsulated mode".)</t>
      <t pn="section-appendix.b-2">In transparent mode, the idea is that LOOPS does not meddle with the
forward transmission of data packets, but runs on the side exchanging
additional information.</t>
      <t pn="section-appendix.b-3">An implementation could be based on conventional forwarding switches
that just provide a copy of the ingress and egress packet stream to
the LOOPS implementations.  The LOOPS process would occasionally
inject recovered packets back into the LOOPS egress node's forwarding
switch, see <xref target="fig-transparent" format="default" sectionFormat="of" derivedContent="Figure 3"/>.</t>
      <figure anchor="fig-transparent" align="left" suppress-title="false" pn="figure-3">
        <name slugifiedName="name-loops-transparent-mode">LOOPS Transparent Mode</name>
        <artwork name="" type="" align="left" alt="" pn="section-appendix.b-4.1"><![CDATA[
           |
   +-------+-------------------------------------------+
   |       |                                           |
   |  +----+--------+   +-------------------+          |
   |  |    | copy   |   |                   |          |
   |  |    |----------------> LOOPS ingress |          |
   |  |    |        |   |     |     ^       |          |
   |  +----+--------+   +-----|-----|-------+          |
   |   data|packets    forward|     |reverse           |
   |       |              info|     |info              |
   +-------+------------------|-----|------------------+
           |                  |     |
   +-------+------------------|-----|------------------+
   |       |                  |     |                  |
   |  +----+---------+   +----|-----|----------+       |
   |  |    | copy    |   |    v     |          |       |
   |  |    |---------|---|---> LOOPS egress    |       |
   |  |    |         |   |                     |       |
   |  |    |<--------|---|---- inject          |       |
   |  +----+---------+   +---------------------+       |
   |       |                                           |
   +-------+-------------------------------------------+
           |
           v
]]></artwork>
      </figure>
      <t pn="section-appendix.b-5">The obvious advantage of transparent mode is that no encapsulation is
needed, reducing processing requirements and keeping the MTU
unchanged.  The obvious disadvantage is that no forward information
can be provided with each data packet, so a replacement needs to be
found for the PSN (packet sequence number) employed in encapsulated mode.
Any forward information beyond the data packets is sent in separate
packets exchanged directly between the LOOPS nodes.</t>
      <section anchor="packet-identification" numbered="true" toc="include" removeInRFC="false" pn="section-b.1">
        <name slugifiedName="name-packet-identification">Packet identification</name>
        <t pn="section-b.1-1">Retransmission mode and FEC mode differ in their needs for packet
identification.  For retransmission mode, a somewhat probabilistic
accuracy of the packet identification is sufficient, for FEC mode,
packet identification should not make mistakes (as these would lead to
faultily reconstructed packets).</t>
        <t pn="section-b.1-2">In Retransmission mode, misidentification of a packet could lead to
measurement errors as well as missed retransmission opportunities.
The latter will be fixed end-to-end.  The tolerance for measurement
errors would influence the degree of accuracy that is aimed for.</t>
        <t pn="section-b.1-3">Packet identification can be based on a cryptographic hash of the
packet, computed in LOOPS ingress and egress using the same algorithm
(excluding fields that can change in transit, such as TTL/hop limit).
The hash can directly be used as a packet number, or it can
be sent in the forward information together with a packet sequence
number, establishing a mapping.</t>
        <t pn="section-b.1-4">For probabilistic packet identification, it is almost always
sufficient to hash the first few (say, 64) bytes of the packet; all
known transport protocols keep sufficient identifying information in
that part (and, for encrypted protocols, the entropy will be
sufficient).  Any collisions of the hash could be used to disqualify
the packet for measurement purposes, minimizing the measurement
errors; this could allow rather short packet identifiers in
retransmission mode.</t>
        <t pn="section-b.1-5">For FEC mode, the packet identification together with the per-packet
FEC information needs to be sent in the (separate) forward
information, so that a systematic code can be reconstructed.  For
retransmission mode, there is no need to send any forward information
for most packets, or a mapping from packet identifiers to packet
sequence numbers could be sent in the forward information (probably in
some aggregated form).
The latter would allow keeping the acknowledgement form described in
the main body (with aggregate acknowledgement); otherwise, packet
identifiers need to be acknowledged.  With this change, the LOOPS
egress will send reverse information as in the encapsulating LOOPS
protocol.</t>
      </section>
      <section anchor="generic-information-and-protocol-operation" numbered="true" toc="include" removeInRFC="false" pn="section-b.2">
        <name slugifiedName="name-generic-information-and-pro">Generic information and protocol operation</name>
        <t pn="section-b.2-1">With the changes outlined above, transparent mode operates just as
encapsulated mode.  If packet sequence numbers are not used, there is
no use for block2 reverse information; if they are used, a new block3
needs to be defined that provides the mapping from packet identifiers
to packet sequence numbers in the forward information.  To avoid MTU
reduction, some mechanism will be needed to encapsulate the actual FEC
information (additional packets) in the forward information.</t>
      </section>
      <section anchor="hybrid" numbered="true" toc="include" removeInRFC="false" pn="section-b.3">
        <name slugifiedName="name-a-hybrid-mode">A hybrid mode</name>
        <t pn="section-b.3-1"><xref target="fig-transparent" format="default" sectionFormat="of" derivedContent="Figure 3"/> can be modified by including a GRE encapsulator
into the top left corner and a GRE decapsulator in the bottom left
corner.  This provides more defined ingress and egress points, but it
also provides an opportunity to add a packet sequence number at the
ingress.  The copies to the top right and bottom right corners are the
encapsulated form, i.e., include the sequence number.</t>
        <t pn="section-b.3-2">The GRE packet header then has the form:</t>
        <artwork name="" type="" align="left" alt="" pn="section-b.3-3"><![CDATA[
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |0|0|0|1|    000000000    | 000 |         Protocol Type         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                         Sequence Number                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <t pn="section-b.3-4">The forward and reverse information can be designed closer to the
approach in the main body of the document, to be exchanged using UDP
packets between top right ingress and bottom right egress using a port
number allocated for this purpose.</t>
        <t pn="section-b.3-5">Rough ideas for both directions are given below in CDDL <xref target="RFC8610" format="default" sectionFormat="of" derivedContent="RFC8610"/>.
This information set could be encoded in CBOR or in a bespoke
encoding; details such as this can be defined later.</t>
        <artwork type="cddl" name="" align="left" alt="" pn="section-b.3-6"><![CDATA[
forward-information = [
  [rel-psn, ack-desired, ? fec-info] /
  fec-repair-data
]

rel-psn = uint; relative packet sequence number
; always given as a delta from the previous one in the array
; starting out with a "previous value" of 0

ack-desired = bool

fec-info = [
    sbn: uint, ; Source Block Number
    esi: uint, ; Encoding Symbol ID
    ? (
      nsssb: uint; number of symbols in a single source block
      ss: uint; symbol size
    )
]

fec-repair-data = [
    repair-data: bytes
    ? (
      sbn: uint, ; Source Block Number
      esi: uint, ; Encoding Symbol ID
    )
]
]]></artwork>
        <t pn="section-b.3-7">If left out for a sequence number, the fec-info block is constructed
by adding one to the previous one.  fec-repair-data contain repair
symbols for the sbn/esi given (which, again, are reconstructed from
context if not given).</t>
        <artwork type="CDDL" name="" align="left" alt="" pn="section-b.3-8"><![CDATA[
reverse-information = [
    block1 / block2
]

block1 = [rel-psn, timestamp]
block2 = [end-psn-delta: uint, acked-bits: bytes]
]]></artwork>
        <t pn="section-b.3-9">The acked-bits in a block2 is a bitmap that gives acknowledgments for received data
packets.  The bitmap always comes as a multiple of 8 bits (all bytes
are filled in with 8 bits, each identifying a PSN).
The end PSN of the bitmap (actually the first PSN that would
be beyond it) is computed from the current PSN as set by rel-psn,
rounded down to a multiple of 8, and adding 8*(end-psn-delta+1) to
that value.</t>
      </section>
    </section>
    <section numbered="false" anchor="acknowledgements" toc="include" removeInRFC="false" pn="section-appendix.c">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t pn="section-appendix.c-1">Sami Boutros helped with sketching the use of Geneve (<xref target="sec-geneve" format="default" sectionFormat="of" derivedContent="Section 7.1"/>). <!-- ,
and Tom Herbert helped with sketching the use of GUE ({{sec-gue}}). -->
      </t>
      <t pn="section-appendix.c-2">Michael Welzl has been supported by the Research Council of Norway under its "Toppforsk" programme through the "OCARINA" project.</t>
      <!--  LocalWords:  timestamp acknowledgement PSN ONs retransmit ACK
 -->
<!--  LocalWords:  RTT timestamps retransmitted acknowledgements
 -->
<!--  LocalWords:  codepoint Geneve TLVs codepoints resequencing
 -->
<!--  LocalWords:  resequences retransmissions
 -->

</section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.d">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author initials="M." surname="Welzl" fullname="Michael Welzl">
        <organization showOnFrontPage="true">University of Oslo</organization>
        <address>
          <postal>
            <street>PO Box 1080 Blindern</street>
            <city>Oslo</city>
            <code>N-0316</code>
            <country>Norway</country>
          </postal>
          <phone>+47 22 85 24 20</phone>
          <email>michawe@ifi.uio.no</email>
        </address>
      </author>
      <author initials="C." surname="Bormann" fullname="Carsten Bormann" role="editor">
        <organization showOnFrontPage="true">Universität Bremen TZI</organization>
        <address>
          <postal>
            <street>Postfach 330440</street>
            <city>Bremen</city>
            <code>D-28359</code>
            <country>Germany</country>
          </postal>
          <phone>+49-421-218-63921</phone>
          <email>cabo@tzi.org</email>
        </address>
      </author>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAC2GDF8AA81963YbR3rg/3qKinxODEoATVKyLVPjSSiKtrmxKEWkxptk
sjkNdIHoUaMb7m4Qgi3NmQdJztkf+yS7bzJPst+1Lo2GLGdmL5zEIoHuunz1
3W81mUxM22VV/m9ZWVfu1HbN2pm8nlXZEv7Km2zeTTau/KmclHW9aie3rpoU
1byelFnn2s7Msu7Utl1u2vV0WbRtUVfddgWvXl7cfGOKVUNDtt3J0dFXRydm
VZwaa2f1cpXN4MVPt679FD7o3NtuUhZtN2m3y2ldtqe2vv9gAt/AsOHpqsaH
27rpGjdvwwfbpfwtw7VdUyTD1zP9oyu6Elb3/YsXL6/tt65y8KS9hA01y6yD
xdtr15lsOm3cnTxlNren9ub6dz98az6xOez61J4cnRxNjk4mJ49Mtu4WdXNq
JpYh9ryYLTJX2h8QZjB13cDbr6vizjVt0W1tPbcv2rLmRToHi3z5wj6t39rj
o8dH9mlZVLlrKoJRDsNdTY4eHn+Bf8LLp/rqrF5XXQN/X9XNJtvCJ6sFnd6D
R1/akxP7+HN78ghWCV+4ZVaUp3aJy9q4vy/mxeG6qA+r2iB0rS0qgNv5ISwB
AFBV9Bnv5Dxr2s5VyTfpbv7X/+js08Yt4aGbf76kB/ym6rabZ7OFffjw6NGj
I/qOt8Av8Ae0xWeTk8cPP/9KPpGNfetw0i196Pf21eTRyfHk5Pjx5IuHX50c
05eyv1k2rf+++6k4hBXS502Nx+zyoqsbYwo94DuH+Pfqm/OjL796CKg5W8Gh
4t/Hxycnp3YBywZ0W/Izx189hs9aQJGslMfgMB7DsLOKn3j45RH8mbfZ7E27
Wjf84edHn8NrczebTuUt+AQma7IVLkY+enT8OS57tclW8trjL/C1SdPV/MEX
R4+OaK5uXVWulA9PvoIZwzMAXx35Rxn6i8f4GVCT7u3Lhycw/bRoj+EX/9kj
GOfubZnJVh5/cQxvzfJcJnp89PhLeAkoZF50LXx2OXl2WLhuPgGgLScNbBkn
nr2Jv6ru6ofIIhzA2fK/OJ//vqi6rHHZ5HaN3wOn4e/KYtK1d5tb4TGrpp6W
bjmpVysg9XVVdIVrhRrpS/omWRK9zXCazOrqFlgTEPNk7lw+pZXu/07GmTKa
BzYHa59MgRyL6lb3on/rnjZZpWtum7svwuPxXzj+xdWXj04JLyeIUD/Sr8KK
rt2Pa1fNnL1aL6eusWdN0S2Writm9JQyGGsDaf5QlGWRLe0Ph/ZluV4uXSNf
E30+ffq3V8DS+HVmWNdu1Tka/firLx8zpQJauxYJQ8e+rDpgPa6zF29X8CVQ
aQcMBl//8pExk8nEZlOgb2DFxjD/HH1fz7LSvlh1xbL4ifhna4GHvsy6Bcx5
i0O0BzYrli3wYAtHd1fkzpb4lhlVdWddlU+6egL/2Om6A240gQVs6ubNgW3c
rAY+QyyzBLq0IATeuI5GAs5SIG5NXQdrxk1mNndlQc8Xle0WDmZzLcGV329d
e2jtzz9Pemj0/r2RdbU2qyxOeVe4Df0i4xA24re5raOt2gQ/TbfIOpErwMbK
3GZ5DktoD4258cvpLMjWNYG2gBGRX2YbwDsL/IlmawH+sOAikkg4sNnQkFMH
38COgZkDHue41UzmhGWCmKvLsd0A/tQAzKwEUsu3AJh5UQEi2sy0KzcDETBj
iDFALc8ky7wVkRgvANdUAbUQ6GEJy2y1gsnxHKyOaADU2apdl/yKroYPq1tn
Zbm1zZpPhhccgxKAdMZaQYVvexgBuXYZiCicCJYK8gRgk1mhLBwcxxP+uGcF
3xLp4skzEb9/D1sldF4WwO0c/PEJ4n5T5+sZvgqAqPNs+2lrBRdb694uimkB
IAXgAgLfZUA7LMwJkA3qQogfY8DaksQMrA0wom7dGFcyAzzABa/qDWAVItLS
LWvAVVhxNiP8wcGqmrAQVoGn1ZoGjhEkLeDtN4AeAAfQ1GYwol8X4Zxbrsp6
K1AQsEzXRZkbxOEy24bnl/DHqgbRTRDCxczXpb0rGjwhy9PJKpiKjLwq5wiL
knmQclc1ICOuDhEHdzItSt5LdgdSOQOy0WFgsy5MOMuAGj07qJDaYlIiYuih
x//PHGcPX7F7+Yr5FXzF7ucrLyrgFwWcfjHfMsa06+WKhhj9/HPrZhP6dvv+
/UHKFBMuFDOuViAIS3CI1BbV0RXACj4EAp439dI6VOtqGKwZ8++AE5lZZUXD
xMkjXVa3uEjanH52wR8hfv1fZorwTLdxjmDQOsZwzyjNLqO0H2SUuHJQOys7
rXNCFlyj3wKNgodulzCNfp2uh2EOm50CJeSIwLDlnMgSsNtT8phevScUh8Pd
OzR8svB81QKOFYRdgJkVku8tnEoAHx0Hjjsj9psX87lrYIlj2DGKemZUtEpa
zwapuCxhQhx8leGzPOsYDxnMwJIPuy2L2wUiBJE1MGmYXtZ+b7GdNkXOryEa
8t+AggQ3AL5fBj3DPAmOEGRKCQtFngHkFh5at9ktYMDMVcB069YgQm1A/8F3
cth3Wa/4zGG9sHgnAhB2zuQ2t+sSaAuQudyyqZs1efETHjOYFaAx8Sb4mJaA
l8hqI4iPiVj/X4lFKzZogWTTgcooE1TbgKLK5YMGQIwNIOsyACA8DjMYVP/y
nEBFK4xkmOxW3/ezJrsFRpHR+4ABAOqOsav3ql0AIaGE66IdFcoKWtMu6k2F
h/Xzz/PCq/tEXSiWB3UAL7hVoQas/z+nF/wRfowoxPjzYPIRPw+iF96FX+0L
kqcCk/jn3X9+hs+iGW4Y+k+Bidjv0ll0hs8+eobfGx1PNrH/tQeyU3jFT/tH
v3kVAAF3PFj+6NfM78kif//xU4Jx0rkK3UytB8nvP3KH9rM95/QsYvJ/6Tkx
Bv18aj/pYzgbfF9/+pL/AioQWBC/2oHap+8BHWM6IU44UU7IvN+9JYMMyJJk
cyJpvHZhUoUipqwdpeXQXsLSynKNUqQj9cOhlAJWloGELToHbAv4JbJhQO5l
qwIu4t+6RPyKJgCGAoYkGCSlkaeBgGdgk6KayYo38/ABvWho5bAUF/jnug0v
z9YNSQ0vA5VLEkifmFQtssA2YQPALdt6uU+XEg0s0p7QYAQtGqTdMnvjUDml
M7e//ufF1ddeRwdZ858Z4vXV12v0GfoxTEDUB79yrOhNg/RxtlpZpJTf9NE8
1qJ7X/3WRm/+tdZyQwoJYMKvXkt4868IF/5594E3hn6iN4dGeUDrWqEhE/8u
KvmJfvgLo8Av734zgZeOJ7/l33dP511/lCsx8t75SV5cDf7OkPAfRm/Ga5lM
3r2+wv/u+R3+eH1lw4fRWpIzevDB//q1+A/9GYGUAGT4Dk24X/2jbw7S4g7y
7fz8dpiGmSnnNZoNp8nBAg+vgGuyo3DgJ7EM0SAiWzayW73ZOiR5UpmhEohX
85o062v5DsXNJ5/YG+DpRVWX9e2WTbQ3bmthGtBy7z1/fX0DpgD9a69e0O+v
Lv7x9eWri2f4+/V3Z99/738x8sT1dy9ef/8s/BbePH/x/PnF1TN+GT61yUfm
3vOzf0LLAw7k3ouXN5cvrs6+v8eMvoikGMoCVsDJCgQe3ZGWasC4mDXFlIXD
0/OX//O/Hz8Cmfc3r745Pzk+/grYP//x+PjLR/DHZuEqnq2uQKrwn8D1twb1
+qwhu7JE58Wq6LKyJZuIFVqwutCiBXjFCyPhgNJJRWQXYCtWIi4NZNLH+sBR
RaU5QIgRPnhbMw/GYzQJScbpNgUYLDTSd9pTc0r+m1W2LessDz4Pci0hRAkm
7i25vxI3gffKiOMFhzoLxkEVc2ZCecJTXhIo7oDy5CBir5YAydgdfyZ5ANbT
CQ0RGfIDngb/KbIA+hhUj2tQ7sE07Ls4xO4E6wCDTrQugGiyasM8WCxKoD11
rRKmgdGLmoI66RQYsh6Fa+XN6zkG65CQIp8CL1u+Se2tiq0YDxBZ+Niu6g7N
bdJ9Vq7BV2gdjsx2CcLG42IYsGlg+bMatCPGHO94gGVU9aZ0+a1juLB3MmvX
jXwAr7jizuEwPSVTQKw7v9izcRmAdcmP2jzOg3Hbvg05BihUefsRi8bIjqUo
2a4hOmoQI1oXT3mQwlV4Kp8VoQEvmACgK94BarwFhZqHzhV6OxA453VZ4gt3
zBGIqe+icuIyCy4tY5Xa2FVBC4msBpzgsucnIycR2e5iGGOUNlt697VuTny1
1m8wLzy6bHcpDhbwSgD5SwuYl/VGx7cKfT/6uIdXnnj1FAfnvnbdevUxWyfH
CZLGHA4sdWDguArEmsK3uxvy7pT4pZYmT3x7dL6wrpfXV7gSsfJ60b0xMj79
qOKAX4HeVTU74hOB9XyY3V0EWKAJgNO+aIrbAuVASx+xX0Tszz57Y6bMYKpm
5Rq9cXXljPrEEr4zag/owAmraarX4ldTVP/Vk5nYATcw2Sf2fIEuPQzZKhUt
MnbsM99jn+RAwI/suZl/Gzj4opgtyG7Mi3a2br3NGKTpISlAV7U9m2G8Bqe5
4OWjTugNiRg3dFUoXkWgqyri/eY2mLxd9KcS3dSh6icU5/JT/BJWSXhrdZDZ
VnzEvIQJGHsI7sYuCnT5mojxSDimoMnYcYdreuPcSmAMWgEGYcRLCoPO0Yu4
LN6yVxrlovjXUDg22xXqU37u4CYEoczef9AAzyMHsQlv/e7llU7A0KU4zVm7
XS5BWoGGeZaeewxI9DRbUHw8mwCkFjBRKA1GYle8OmvRJ42wbxcZkrnsrzc+
o0pREZkbP/YTxgT4jpQ85FaIZcXt7ZZ40ABfgBOJXIsuaE7KeryW9HTdJad6
u84Amp1zwbMgC4o4LmlQWxMIiPWfWUOh7GQGkIoxi0w8yEAwd84wUsrB0/oc
hmvYF0tBHD8xn9MrByq/axDQd6BDXa/WYCKsW/g8VjLYQohoPGAJY6h3tiJS
4UpsgQDaVKanrSwdRm+Kdknuaha+SQzu0PyAZ8M79NI5o8j+GFkoiW06RDaQ
fDCPg0SNW5XZzJGA64BH3vLmOETS05z4SKJtMS8FyMAa8CB5HhQJMHuBLi8m
VDl7F3zz0SB+i4bUcopthYWkawAipu1Gr/cWiXE7fpv1aebBErxSAYMCfk1u
uc7t6Exm9Oz1y7Pzf2gP2OoheiFWDLiF+sbcbWLVYE5Bn7GIcFHljXB7BHvx
xuEREKp1dW2RKvDPOUZr8K1F7QPCfo1GhGC74tNB4PO+WF3kNQJ8O4+eo28L
DHfhuWVtXbHL0XWdnCfGgYC7wAC8VkWHBHEpgtR2+N+saVAVAwuvLOhos6p/
/gOqNQ5g5PjB0KqmMM0bdYJqoEHD/jL2E4ZxK8TUpwG/x7FwCzAyax/rKosO
bHfYTXU7IbXRzefwuFGMo3UCxA8PEE2LUrkBW6EVUtWP60LV4zoVzcrSgZLo
LMHg7xYGFCeKpmCoFefYZG1HSDUFCGyKHNlRpjZmJkc1YcsiMqJ625wBfDHe
d1cXqJKind2HNxJ1AAfieoiTFku2GR3YqijoU2UKduAObw/FYnsF6wHzmpLV
0LVtyXgWQBD3AEbZKdEGI9og6qLQjULjdA6guazJEYBsLOs6t1x1McdifGtb
Q0hXYmbAZRp4p8xJZu+JVT6OXN1ERIDRhgWsrBKgIAkF3tu9owKL8OcXBNB0
QDAghtbWyAcMMMu8BBlLPCg9HVZ2CfH6ry/qGgTUNxfnJlAYA4h0C4pEWAUc
SFCg1N/8zWRivOz4MB5QCJtOLcYjM4Sltoj1bsf6MMKXUSHYmUaFB7BTHBkW
L4ZvKiPGnqFr+g7QNDAXPAgjmR/e9l/SoQSHC9AhnBtM8WJ6h/ss/XAa2gCN
KAEObRVhn/hallmO4hH+oEC+UDUJeONTugi7Do1FRyPKaT57plI3rK7+/AmG
PGaz98ac++xH0vAaEMz7hB0CQ48+yzNAc8wCxe9IWglrx1fVDRlSK4GxZt26
FeTfrjD/wN6cvzQ8NNCoSA2icwq6wKFF7yODLQFJOfMGDkUys9BbFi9Bz1X1
HsxZobSJeHzBs2XWvpEwmVGGib6t1hNtUFKmaHIJCQdZd2guxWDA/KUxAyGs
bUkBmI61/7saJ2PgyraV/VCKC1g/RUOSSywZcoEBKIDCHWuq87CwDWVdwInm
YCazxkM2KfHqBRqvCKd25hrS2hGdgPou56r8rsmgAd2v3HLkDQg8hjenRwYr
PGLeu3r/WNCV1G1giCiFHWsFghWApZiYwYJDpmkjivVqK6X3ZB1LEQxmksCE
AwBCXjtSZhiCif8GVcGQsbTQHCBNHVF6ZbundB7BKbtbzt3wEYVlR+foVVEV
Tay4Z32IwWmbZUbpYOGwVGGlM/Ooo8gEp3LWimVSxSl7AbixDymbItFH0yLn
ADIE+VfkLspxSPJQ3Fs8r+Dt2bXBQQXm14JX49Bcgz3CsvPnnyX7/P17YlOZ
2swiuBb1BhljXiuf2zG/L86vAN3PWJ1E1RTzorCWZIzieH8u9vv3lC4JepWT
rDtgxng8MKBmg+naG3cLmF8i74cZN14zd0OajW2L2wqxHr8HZDPsoIZhJ5S4
iKjjMX10cX5zIC6DoC1IrtNS9OncZIwvwkE1LVJdMmfKYcTlIaEJRApvWpGJ
yytjzdVzraCcw6sgaTjBdEgRJcQVmZfwRjaY2j3SN2hXIz70uyKz30xe3bzg
48dqBDh+APmza1TA6UMsd6BkQrTxEWi5OgaBu8t+SYUkZameY/mIUua6yhkd
EU5I5xnaZgV8ujGB+ICcG0wsA1Rx7C1HPGr7dl+SnSm0haQDh9R2kl6KqNKj
el4XERGnDswLDPcQK40PRnSPHshGBZnkuH0P1pipV6j+A/I2eFrmo/m6jfi6
ZPoGyjDMmscp96EdJDTPSDRE84GD93IuI01UocuYbno0FAiD54qJZsREAtu/
K9gSFnK4fGlICBzAls57fJO5GAlmkB1FuR3YwRIwy6hVhwOeX9hRDAKqUUB+
kx+A6G3eHJoLMohIeRv7hFn0q6CunqgEsmqfPhoD12AOGZtwByzMYGacQN8i
5bgvD6KXUPJWYp35dfRVcVoWrSpEgplT5DWZa53Zuo6ChzI9Z0UPTsn2ew6o
10YGO5lIYyPpfskcg+PRGDI5DaZjGZTLK/KdoR7r0LOaEVKSOdToCWmtEGLU
a7J7L94isyy6WPG8AqNS83GQ014dYB6SvktW2g/kQMneiPxDQr6HC0KExKXf
s/N15b1knGEkxgZbvoi8SPYtBYdFR8Fw4zZGXj2c5boVk4f0WJTOgLu3GWrq
OhDpKmjUw3mp8229WpHlgbKpcrc1cmnyUJB2bmk9XgfbOA5T0xQ0GYK/AtkH
wkYhzbyTsBKJG4WsSIdd5YN5wHTrzQz2/URojgFqc35BIMMvJRTivY/qq0Yz
f4bqLXGymRJFjt55GJ8MP3yf4ih1ECSdJfORMr/xjGIKU+W5iDTmQ4PVRAw8
HLu/IyDomO28urlBQdOu0XtcOM5k1YT+Xb2NnKDq8tiKb0eEj4lM9GUkOsaS
Nwz7X5dZQ0cyXTdtpwVDZuRljycNEuVYC0Fq3D5eSUfpaRk9b/1HYX8YnMZA
RUllIYDsSIIO3VGSzwcgmhe364aDDTtBTn9WkgJHJH94wAhI+Mep6m+L5Xrp
zU+vs6s7wXifHLoTkhTnHe1aDyBTbzKt3fDa56LQo4mANuxhWAkGbhb8n4gZ
PFMtxLxs0HwjjIkt2kEx5JW6vn5sYvHiFTdQXlGKrIt2IcPC3gm8keTFwwa2
zXmA6L3NSuVyvfdj+Gjuui93oWHRY1O9MewCF/WqdeiuYab1ENnWUPIlyI6n
W58PRIxlR9Uf79oDsTAE+WtiAS3ZCaz5rFtWe9BE5aBjEVQ4kTMaKpuV6LXE
7PTScY5kqqnQ0QqTY/ShHHkB2zh2XyiYUHmuyY+HNsSq9S4V9HMZhXqQa61Y
3HhechZ0PkF3DbZa8OvlEZoa9rHtPUAOIHlvfRjOezUr8k8QvWkePAEDXY8z
QFn4ha1TNskjX6FwcE8xEeWmuQ61xBP87IcmLfeKDjzauoa7vGs01iVMIPYo
kC3ptcho49WQ+YSqDdm68Lwznnj0VNDOlXhipSJXvFD2ek/eLHueJNmWlU+g
2DuSOHj0VI1B/prLBMbsidlI8QI6sCWLSnWzugnBx52QE/4qzmACP7J3VnC0
IACzETi/pnXoy+xc4rinZAX1I5P9y8ka5JQAi7/KOIJiR2f/+Bz12zOsxsDl
qFqSlejERUxpAMFvOS8rCtEZz8FA5XHlXHKX1j3U0vKnfpUUKDtY+lVPW9fc
RbkOkr9cqAfUofIQ9Pui4vKKpmjxjZrDvRIBK4ueERyWmJSgeTF4Hz1l93EY
layOwm2RFsDeaMYosuunVCEImDxjUymbLci2ASuFscTecgwLxBBZgEzv5PPH
wL8rsxUg+5j0ac3WZt0jtvNJv8SCNanmAeE7xuImwk0X78Yng/nIN/nFMbUD
FWLTd50Ml8UBCENRHMr0opJIYz39g2T6+FMI1UjioYJVAUj2OS5QjzBRdI3O
mZIbavF3YnZOyBJZBquGdWqk3rFhZIbZ6im5CGmIRJdgRxwdJHqqm1ukpZDx
0gfFTk2qXw8cXw+4rKZgvJ8qu4gbAohXmKko8VPVSQgicSRI2JjsEE3TZWRz
f5BcxMBFX0xFR7OvWDLFcC5/JT+wDzBuAcGAD7bIwNq6xDAKIWUQ/GK1aije
x/pVCoBamfP6+6WJrEbiaO22mi2aupLYPezzO1Ibxb/Afs0cleJ43z7BTKqH
0UsFC6ckWHLndwjs0a5fkZMAVg498lFM5wDlnqAYxwhWZVa5OEQviVV96LO0
TSou9KywFK3dBUwRZzb54khhisT7K6r+6yumlBzEb51FVSlA7urCJkHDEm9e
Y0IHnXlcwUKpJqJrawaeh+UtEkLVJloM63aVTyPkBMea0pzCJ2PjXSJKPnGa
U4+MsIoX3WTjnUwVdqEJv8Ezu71Fj2fnfMYOrYe6pJDw2R2ZJG4P2wS2wdCn
bBty6fZXIAm1gbeiAkB1OD6LJqSiRRAgFGS0I2PeoHo6E9dDZu/zaeqo9zX8
mmIbbV9VJ8RGc38HC+77Qr9NrTW9nFuGh83e+xqDUY1sBkQeJnLnmPgSwvMA
qAtk3+nuPQYItCnhJ07Q8UaTZPkEYHu45Hlr7w/kt8rCKdeBRn8SRTl8PHNZ
a87sUIpsJqG6lmn1vmRVmv40/Lc4aICrFXWjKWg+nmK+c8TDZUucgojHMB5O
TY7SSTl5KMRaD0MOZfyKOMBaycHyepe6q9hKMlKTKagwoUR8fSQq1DzA3X+G
AVRN0JJcZkPxW0d9GGgRk3BeDF1U7sYoCAo0+AV/NhlrEYOpyBqkYq0RXRkN
2Fq5hNpTZEberE6+xFXhuPoUDJDVQE6nl5RyAIDPITWt9fzW5w35bXPm0A64
D2NlW8sgGJXSYnKM0fSLvXEPSelEUnCuYRHPQOAVUcJ2UruNtyeCr5ryVDD2
NQRr9LDjk3iAQf3+5uL8gCO/KdKMvT3reWOeML37e6q27/u6iQ3HZhLU9l4R
LO/os5xBghhLIGbgHO4/5ZLk9j6Wh2u8LK0hR6ioBZoyQXLJEm3Rn3Gajmdz
vmlBL+9sVtPXlF5KmEMBIeLMfdoDOe6dDIH2o3yLMMiBqYLjsKUgbuZtxNfP
Xkr2j6eHOEYREjsNZooKAWEdOsanpHa7xd4ddOyigiyXYk+JaoUypDI9oxyf
X6JmDZ+GkTyO6prRZQu2jbmF/a+LDqfVMvhYhY60iz0d4sS0RXIp35u0JocL
0ilct69rgGqqqTF4iMVnHXZlIkeMprCO7h+wG7vDolhvqEiqgY+lkXeQbSyg
iOC4K928U02NlBeMJpY9LY1ySXayiQZy7EPYHzO4T43B8svB8npgHGv0A+Gy
MChwh0VTUXIevMk+KO5B0JOcvgCCpeGTXmlF6e7QOzCnnP0GOFrwFw4uRp0F
sXMAFtChmdPtd5CG7DYcO9hbfr11RQUmdPrsd5n40frpTlhlhIdJsB6o3DDq
RxvkMBsn+bPeb0fAF26OLRetHXHO5rRA3ogaN+m8AEDcg+D3bvnAAQwjRnu/
MuHl9ZUdnRw9oCEPxrwHBXXC7X3+OsJDwgNdAF2v/qY4dIfjHoBQ45msJZME
JsZlAb7++U//zvmfki/z5z/9B0ji7Ba4FoYnii5IAaWszEoiDNbtuAaTD9CI
0D4t8bJRwZCJ6pXkc03LejrWVIrZog67YFykx7fdQlMj6SvMLGuB6pci6kQO
zQsMJszrNaoat5yhMGoz4GUPH5w8evDowfGBUBTnhBUd+6UenvApGvQpeqIm
Ngb0CA88ekwPwK9AVWiLw/yIL7hLOKWG3GUYfqfVcPslSrHF/NkQhtHwjC9o
jy00tElBeV6uVC3RcrIIMZ+QY5s1BHQnvH+P+acnj3h1sBg4ScDFolpTaQl+
zMy9h2mZb3o3Rh8QsMDHZold7sivqXKqsSeHj+y3TynILHllirrFTw5MV3Rt
bmoA+gQdxkZjLBx1Jy0KxAjB/wgZdg36s2TrebeJqzj9ThKXv3h0ZJ7Dsj9r
NcaIB7tL2niyN6Co9EK9rMb304+z5bS4XZOTsEpcsZoIA6se3TAh9KI8SUaU
2AqcxykwJYdqL8DdLeDghB41qJ4ZbLyFEzDR9DLQD0A3DF2CfFKjX4wk1OeG
cn9DUJBmKTi5C5NQd+RQVnpS0Aia8STOL3PDJ1T+qROYljQl7CJKghwozpA2
PlG12cdwUzLUIz4we2OPx9ZnecOWya9CDRMnBDrWjKLU+py/S91EQAeYBLWK
DApVv5J37YgYH41ABhuxIsBdcWmNPUPCvpWD6z3Zv15ATIQzwBdV0ZGPG+Cc
IKfLDTbDIGtZMu+yoFPBDh7LKNj2DFiohmlCoI4AIlxWJ/FNOjrlhjgKPug7
YLltTSrCAXJyHG50hvbcBB/6W/vHLw/sA/v4/ohmRX7JGZs4DM6ZzHeIn4a3
C60+hIMHlYD9fOQfvGOVk0+YltOicBR2iKPw6RAWH+EJVAhrjNpnWAfyVN5E
Kcq/nyjhU3gYtKumFQecngLru1t5zvRN192yyKT3GPFMbGwi2ju6j+eGVlXP
ZuuGg2nq2UWsA1rTKfvBv2AvkV2Fb0g0F0EFb+n+eoorexeJMIHg103F9qhJ
8piJsIbEdkveAQVXz+pqOZvBMMlKPaFHUQ7LgtIuCpiIWomtwqQl8FBKnXbO
zOqVNhEk7wQd70p68BFoMGhzjQkCFKX3kTRfzdPV5rZmNxGw8GME/onNQIh2
IGWQiWI2HooaVdVUCK1cJTpIWZI3VPQA1SxBYM1UOaXkf06x0Nw9zJ7bLGo8
0awlqma1pjUD8GTVGswAaoyzkRqGPt9JBJX30caYNSKPAzyOafxIf4LItLgf
QUg54zQFA23tlhlAi0B8vZJK55WvWfNUBesl8M64nqbCDuHUrEiIMnhq97JK
4TFCO9iBjCI47aC7PPGrSA/LNuAGrPu2rsn6FCYwKzT/TY8nlsTqh2BJGuyp
qjbSm4HF1+XFxYU9/vzxY/vy5uXOmkbTdSQDgY8wi7u6EUvZ9F8gjZT8MpKy
iOCbA1pjcCxrpqjJzriAnM4+p7M3yTFLjUykpOU182mKONWWI/t/wLwndcxL
ic+Pa45dClvFHJw2w6AJOlSRi3C66aHpmcjUk1PMI2/ISHur5+hUSjxK3WKn
gWJcCuPTvRMOIX43H53wfUgji+9QiiLYxh0uwSaK9EouqICVsFtUdqdl0S7o
/Mk/nFOgwAe8b8hpKoOjgGkpeneLfHBdFYhGDfPY4XL5p44sSl9EvqCkykJj
kuTiC7aMB1RinRq1TrVKjIKDVBuWZ0tED8lBQSzxGA6rZQnheTUnSPm6Pn7L
i0aN67Vxht0nANvnsP8lt0/0E7RUayD62zj63Nde8EuSUkEQ40QMD8pWqhtQ
zwT2yVRC54HdCuoG9oWeZc4/4RG0XphsGxZfhvvjVLdsu1LZN+XdUU3UG1cW
C2QBGJKhrlurUF1Xb1hYhhbJ6BTOepYrlSmky+JUUK4nkmoAdn32ovmo0adp
DkS/p5ofJ0Uquc8SNJGTGkwVxMQKazckz4ZGIA60AdvJcYLGmhsh2Gs0cSge
b46P4Ce4TIOo6YsO1pg4YBKD3ZxRJB4VlGldc2Jb47BXTOvfoy6vGO3g2cjD
nxh4Jhh46MjnnvqU7V+uKd0DtRKJ0vIYUtIsa0VXHtYjsnaBEMqK4EfDpcb+
GXL1zWbs9yD/s2TGSx9iqQo7YJR+oRr0ZUTanvypYiMLzUFE4QaxyU5N7SZA
VbQepXsOFa1y9ZIA/ZrAMUi4CbZnHJ4m7/8EjaCon6foQQZmuBT3R7TYA88b
i70eJD6iyr4yO69baeqQ+y7BQ65skcCBLQI9+HYplCzWRk4SKV8PDAVLwtzY
LOoNjj22/YRhdUPI4KhnUhWjd+n/er6rPWNM61Bcutwqj1FOzkslHkA1jHG+
ucAZUyYwHInBxKIzZB6FQEbSFiajTtZTB8YqsTfsF7SgiBVZwlNgP04iesS2
TeYd05iCO4+dTBKi5yGjrQ+sHJB/cOWy5NB9JwP8SWvAQwrrK36HXGi+CkzF
1g+LJFrlA5Q6rgeDH+7SD0fsApfYmqhXESYuFTNtYyB5OVq47vfKAQIX7RWU
L2HvPg+1t6Pd0J1LlwcDm3aJjUF8rTdqAimY7Qi1+/1OKkM87EfM2EwWOdid
KFkTdZPwjacrbASGnRsBcdG01yO8y8q1VxMEmEKbfFKaV4GZ5MYnV+gy1lXr
pOLulX8Z1G+B7277pNiI6x8iDYZFDZ0USK5WrgqeT3FxRr0CiHYxy7qoYpaI
gI8kt8TfD21aVNlpbQxvvg2nx+nrhjMgSUINOpdbTb6SlWkfJjpWEfem0wSZ
trdCXw+rzcPi6p4Z2iWcT+6WK5COzTYp38zhrSwXETyQNV4lqan4JmrxnHtX
cIgrBD58bHPF5bESqg6mu/GZCZyzJfqwBsm6Hs+MQM9HiGWE84YxglLlUHU+
66Hut17XwIq2XjN09vgPH4O4k1gwtXT4iTS56bOTtdRsce5ZiwbYptz2jw8U
WIpiRw7De+QxlDpe/FzbKlXqQyNzNM5l6+F/P0lpsHv1rVwEsKxz6vdC65Cp
UNj1ACf+jB22yUldJAONlw7om1h3k3o+oQo07xqkzhQYpcaiFhYb2rMCYIDt
NNp7mrxPGr5CaxzN670pYsOK+ui8qX6yIxaK5dLlBXuZeuCIrFK0ZJiAEOqY
1xl1BBtI/og9XsUverwOg9jZfQ6TQcF4gxXIVQxpQHq1bvxbMdopYOOotIIj
91jAyeqhQZ5hO40ZNWgnnFwk+dIpEqNW2mrNbEQsXR38fZaUqdFNLba0fX7z
Gs1QDMEzqYmaLmOyzogjs3kDn01QcE2wnjsJZ6FCi0T8PHJjSKAaQzMiyLVI
NHhqesc/3t2XOmLY9foBj03S3EpkY0pHgAyxJ+iXXFZsGHeC93DuxudcYgSx
RQc1mZKkpmE7LO/DUK8OOTDAjgGdl9h4dPcBp0hrmuCu0sywl2j38N7Tglxu
gsV8nMCb+lA5IIOSHpVJCfQQ1uH9Dxj452thoiRzz8pDqEc9ALkJjVhwQkQk
Xw/FfWCoT06MiUg51N4gitewFzTkFJA2L2UgUWbKastpqFG8gsh4DxqdDrFa
r5OpaBrVYAyQVSblIyVJQW2Zc0DzmrQzA1EiRkuQ7/hQ2sHBIL75HCQT2s8S
cVNWQpICXQ90w0xapCCwTEJx1mImPuWPhc4DmrE7ZYjGujkKLpMILnKgpoFw
teJIf6EoW5LWFFESVxJq1HwvOcoJ7RxGyAcPBaLe5ee4a7tvUlawDm6UGlB5
JStcHFg7LIOjEiS78DkEAXFGk6SvxW1vsJu3T3cOtdTUaTejEIYTyxIju955
g6Oq83qnRl5DIXirEzkdab+RnzOmT+HuRV4yNNuIFxqFO5UXojKHc2Z4BVBw
r0iJsLQZZP0olp9GzTuublBW3MM638NPK6HETtK+kORy6s/OCc2+6aA2VRrK
hxFfnjgmJ+HOKo34t+z1iLIivGk+TtgR5fsSInYd3QVkybaiyCUW7Khwzvqh
Eun7wdqhqBAaAUazQxry4ThGG/MNZWNYaca0hwlJUSuOwPkCel8ArkmXHBId
uEqIggvwrE9ZMzKl7PoJxo+5QlmTqvYB8tDsBNFdQsDkd8jSXItCmxqoD26M
hlM9K8hm8fZZFG79ZaAaBmoUjyFCCfwqrMB35NrHNkQvlUL3gpx2wXpLmRTu
j6Tb7I0uVrYmCVMNVY7CSlYM+NH3QNoH0cVI8MaozdAEIFasrqqwXsk05WVh
moBK5kj731FxokQIsRvMswj97OgZ/XuQxuJGrfSSptkpBEirpQqmDEuXPguZ
mZmn77BWoILPtF+KqLlIaRE+s0/Hqf6wu/Y0FY589xleArvr7/GtaBRjnkVu
GQotpEWACHmjHvUMo8poJlC6DubP+U6MZ0DkNfpq8/Qsbf8sr/8Nh1T9XxqQ
sdbgvdvkZg9dP+FcqNUI3s+KzQDOtH0MxRDWy+Aa0dWSCHyDDQpgGHiK5sQA
L0+uedPUagMvMmm9DlLTWZYG22Vy78CB/irkuIwUMrJx4mQX9U9oV3yfqTP3
zfp34WNiXI+iwsKZkXBvE9N7LzK0wYIJRBN3g9SsrRgZMkEF0SvwDMQW/CC2
aZxecQT0+D9QZUdtNHE5Yc5wCt8Gra6P5KGiBalv6i0njdj+Q9QjN3biB8P1
SRI8QaBjhZkG6v0Z4wVM1HajxA52JI1AsZe0FpoXCRkWQR3LDNvg1KaD87rU
HzXgFg+SP1QBkZbE/SSkhFWS3jX9JuqySQEdVHuyOL1Bcdw89HVDWkKNV0pG
3dt3K6NAdVBJNw6A1SvuWl9aNKUYOKkLBBxZm7pkGyc+UQKxmQ5kbZBb8HIe
nVNOnmxiHUtykogpTErgLgIQWOKG04kLcmjKUKQonZwq2pDfZsEGjs/TGT3z
jatO2c7iezCn6GCSTjyyInwvcdTWSCfohSfhcv1vyEyoAwOwGPw98rJFHiy9
hUBxRTQ2QiFtzwkE/n3a4RLfeqXXeEh8mu612CASbduoR3y/c+EAy/rm4lz4
CN+W2W/a+4NK/6SfrGeTvnOur/gbEOzih+131hGTJ+I/jPW9pDfOVTLeaOEK
sZiDYajq5oVQgnTe8Yk6yjC5mIBKVPDabHbHS9S/tz9xfpHiI2auuG5dTshn
Aj1KJhX8SaLE29G7IBPlihpcjEIm7GwmndM2i23IMELv9dQdWMxbHFKVZD1t
pCQN3PKCSVKRQaoKjPe4fLNuSCHrG5XCQHwGkdFGVKKZ4SkVtAgsRybvJWfm
8UmQDYaxF/W0SlqC2UmalzYzDeZeUfSOMBH7hhrKUm59oFfMZu3lnmK2tkCW
d3w5AQ0iV+qpPCJ+kVYfhesqpecul6hwuxof60huRZj7JIBQRxPldRN5aADX
hPtb6N2dQomxj+qGullMQZDuakefn/BlLpw6TorWCATXmjUx9OJUeYZwpSWS
hhkSO7tFnHFuQoJwHAvNckzw2eefZ/ymzp6gLJqwyETx3tOzgtNsAm8FCpFO
HmAm+vG7hVbWZZ3vpDTYSB6mxouYQwM2bc2kkmpdhf4z3Phob3dmuc829L3m
/qxWM2w4R6+oBvtCY8eRLm7mHbW69aZW1LFrE/cDp/bIuZH5cKrQi8BSGwLt
3IAQzbFsDe+w7KK3Q4IA+s6K6FJqxoqQ4p1esRnfrKsxK62oN6LmUnjDM2um
Wm5a4oNUErTxpMzZu3HpPxGZXB/iKR+z/pAiMYBB/RNIdBNn0sM2WoGDjQI9
OUsTgaj5hjbH5ChQWr6hTblwiKjDF+rooUdU1HU7vZE6TpuPwDVOoaoNfbAd
ImIcxmRniSfMJM/782ph3cjvYJ1zuURK8IhMC05hNfvp6SYIRw4qUZicOY8q
fVs5bVXm/P3SHV3UrU0Vh0Lgyb6lGxagXrMWJ7xPVOnfCTMUC6P6uGstc4M3
tMgRR5akv5eeuKULjDz+PvVkRq43rQ6kolVySWr5HDIRnyAld+wGx/RQHmBy
l+2Z3hGrwJA2MP2bYNGUos7yU4elvnKFtq85Zm7NJNGbTTNmneSk0OrvsdPn
ntlwfB9s346bwfN1tRzn5+JHVzotABZhdPP97+S+6dCAY2iDvs5Cumlrk4ip
ogfhEfa+cwbGZE1SfXF7ylbpc0nBw0xLOQfji0rRbEL1GGg8b/s+VH8rGull
ev0zi4wLuoQ4tAiBR/Qa3k8iYBuzezmv3nTN178ibfbvPZbGC9RWEufRim9p
ygOoIKOSok7AQCMva/DGd/FzJtFCTSi++t0F4hH8Q8mW9a04EolwMlRfuYxR
KhNCNw6ha5lWlJYFeSKWeBF1h7Ge3xUNoZRepXipNSmNHf3u6vLAwK9lfpjq
JfCF6Mb+ao988I4is58bMBnAGp+j7QX6fFaUGryUJeuFysH8EDybkyeDNe/+
7cxaJ7XnvF9f6GGv6aTx75/pj484Y21O9oEzhvHogNG/0XIHBA5esvgOXYoB
sG/RheWqW8BlOR3nrxemm3DJjJcLYZBYSSjwGyY8Koewopvh7L2XDTctRkZ6
z8rxnZE9LVkhyGFJSGr0/t5q953B4ulEPeOQwlCVsS/b5xLl94c+KXvg9q0N
G0U9xt8kfe0wQSgK24x9csEu94hytYkRimsIhF9LN056d+T5RGu9BAp4dnwO
ooeTFPlsRuWtBBMT3fytLicdl56ivZyTl4WsAzSJqLsF59KZwZdCdr+C2Ts9
k20mKSy+/dnl2dUZNjWMAvjGXNX8eaZXWIT2dBpNazvOahbrUmeSWi/2/ImN
eatrCjfLDzYPRxQDHu1WdVF1rU938lP7/M5bsPGaQhPwVto4XnKH4jgRdi1c
N8je+lskhqRfUumHX9tAKxtWhlhuMPoabkVH6pmwrH0F86F6gF0j5GSpuSfc
/jAXsIhVWW+jXh2y2DTb4hcGYV8lqKjbMZuTcpsNPqDuG1T5c6mFxGZwOpHo
e6GphPeP7onLYSs5CaMmTyTl+nzxt3hMooyy3RZPgEty6V3SSdTDO5nE7MAt
7jMR7UlMRe7cljQFNftA7C8sFZtRvBazegliI2rFGHo1RS3ns2JJimj08p55
2PZTq5GbR3gxnhdzAAYbj9G2W1ZNbhaYE0gdUEpjzjA2+AbNPvbdRHe9IMqu
myl7l+OWAL3+SYbpNaSIrdYNNbY/Nea+feaqgru+X3Mu7Kl9huUbChnJCAyt
BqIWtupzNhaVv1xfSxPzeKBwlcjOPWiSb3EIi+HdksF7jniScxIuzd/Yy6pz
twjsU/uCsgXC6emNdrCSWHiMpSuMPLhEPKJGeNhFGFgUMVfunkyHKcjdG+Uw
FPEq6EJW6B4EoNJe1A6inp+GygLtrMxazR/Q04WjOD6EbfPdamhVTaiagm8w
1cewODR01l5zJ/lsq2zM2qRlFs7O29dtj+MNE0Bga9Ymma+cp8JygpRL9JEF
xYm2VI+ttOLmxhckXPQaAcoG81DxpFxXeuXaQFE4rb3L2jeD/CCwJb5mhXvG
YXdfDz9ahFijtG9gDCv2/EfeXvEXsHqM1ajtQr0UdCg4SnwqpEHIsbp8sMlf
hAH4dooEAN2T9FTtAzmKv/RgeRRC4oCllt0YURazaLvca00inSWBiNwsufoc
Ze0pxUV9KhhyUc6o72uPZygSiA5BXEm5ZyuSYu+/ESyIMMPzLtgc8hLW1qTq
ws6zdkHaoQ6QBSZRKEdgdYEwqvq0i7EhZGv5qtqpbw4q3EAKmGrtmwugfHiI
DhQ+uMETGz4E9mMxePnYMKbALGDv+YbWbfjKtcSje4KLBD+iLiIeYSuW2AsZ
aggI37+HPZvze/LMw7Bicf5LpQfYOW0aaNImCTgIQY0uiyLZ7ksxUkLCRq68
kl1H7Dl/ERET9UqVu112rkvrITbB0cRtveTyTutlRNIAKOLrczCVKJJL3ako
uc9Qcwk0w8b28PDQjm6ePjvQJT60oz//6d8JaH/+038cRAvmGZIG7tSNA/sA
x8UEFPF7kEyMWLDhRNE71PjxbiSp+eburJuCk5aTPvvGn4um1TRZdUtOKOnl
yP6VTYMpPzB0jQC5QFcRVxQZettpWLPGGhHMD1kUvhW6v6NzsDVWU0/XbWe4
bm0R0YcQ3WEMPwwXUwMIUM7VzaYd4PkDMmp6xYZsc9Ps2rGKygDy4m1oETdm
HoA7oNZo2bT1uAgIO052gA3SdNqMP6WJ095cY87uUP0dmMA/FT8BSOz3BXf+
/a+APRuAt/1n+NTfUaKDeXCJ46FZV5rsi4xyQwn5AOpRSCChXq2xuntAzT3S
KCi9Bp9qI6YLusv7PNzlPaK2c/SUv2e73ykuTWjv6S4fyIRPzGNKVu9nXfiu
D0mfCDJuyWEV87WQUtuz7LUJ0eDt8nwFM0FmuE6am5HYkfQiOpAAum+ZEkK/
qIdyDYo3ANVvk/ZO7RuIWhkNqhCIf3/NOmtBvTZS0mSdzdfkJLVyhNRhaRVD
pXKwtRufeRXtIwnT0RmIp5VDQkmnbuvLCL1p7H3uzFd8ulx08VfLVSWXqkfg
NSlcWNEjDfvwhJwg60qMfHbqMZxUf6Z5UDmWxivilQUY4K0VKIZDzd6qnkk3
4S4U0GoOGmvq0Vo9LqUpgOxsjCdQtx/Oc2yXqLJRZwzuocTPR3OzGcdA0r1j
2GaFzAS1EnbjWTzpY/tfYB4MXBx/9eWRPTo6pf+zr2/OkwzkfpMhj3t0/qre
3ITMS6Tui3M6baIR7jxyjhmro8+/SJA6xJOVoeGbS3LhWvQDyiaw2Tf1JFUs
YBuPU1XQ8RKFZQ/pRX/XOcP9ul43sH1eitLZ9VNswHOh3vXr7XIKDO/ymR1d
XF/CN96EhEFa+rIVPk1+fUAHGlSuoMV4GI+APbEOxQ84d5iTQK21YJRl7PGt
K8kYuVkMlv6mzALzBHThMWsIhVuj3fLvuHTSxgXgByxutcjLJ+7wPN9jY/SR
+l09B/LFKBjBbppsKx0Oorb/RC0sc7xQl4Ipav3h8ijzU94jhy9dj7jipkUw
CFY1ebWAbMekyz3FJ2nlmVxKFgfb4X2fB4e1Jxw6ojQGdk92IM1m0rZ0Yi84
vXmQZd0soqTiAC/vSvXEsNuQSir7IuxHHGV1ALGiL3EDqnNC0zB229GrbNXV
zT8avi3w4cOjUA1LrlqfAxAT4W5ZesNdJPcSxqk9Zlo9tGdieSClhiCJiD+k
jZgOfHqWj1op6Uh6T8QGuWswoA2fwx5C/BUr+eU5aaZ/OLWPZcQr7yb6JQpn
uRYt5jpQO75E3YmSgpHLOEHN25beFgN6BF1pUtb1qp3wp8AqsAeSVgomYPSZ
Rk/RlSsri7r+6pVQensYB9gUEZTTxt1pdgLUUXSaJXvaaxKFUBp/DOU4N/2x
PDqHwH3aVdu36fJzhqRe1dq3iKdmhQ6knA1gqdT0wj+5kTBr/BXpZL2E0ze9
kwzLvSI1Vs1E6tqpdqq0jKHbiwm3qU2zJBl0cc8SfMSjL+BtR8VBkiZbRMDQ
1lMmUZS5rc9NvyE08wpuAL1rOnAn5cwSXww+Vk3u8hfxBBck1/6P7b1+62ls
SD36gfL7go+dTI1fah/kfPcgey84sSi1D4c94PBXbzqpxshdtu+Sk6XL8zJE
rHyD8ET/7KVMsBUKnL31fgb0jbu36DZHR62JLo9Ok0DOdm4b8vklPu5HdwdW
8nrk65UEFHGBU2+ncFcXFe+lXd/jrv2pe4FuhvEpGunNPAmFSa6NWNJxoYQR
F024ANencmO6oc9ySCrGMGL+aRvtyfCextJjFJlUdIQU1Pwj/KDjRH/e4R8P
Jvyj/37MzwN88Z2OYj/+5528+CCZ8UG0jGSa3Rff8Yx0RPzX0PTv9r3Yn+G3
vUS/vS/GI7+L5vhv+2fct8d30X8H90gE8k5xAH7kkGVeVToHXuytBH+QZuRF
anmbwukXECBdah8BBqCdfvSXDf8B/Hq394tB2Afg78z4oPdiil/huO/6M74b
fDHZGv7/b1Oq3ftiMu4wRQ2/+Jv+jBP1+O59cR9wdo+h9+I+qO/9+csYTDKK
/twxF/v51H7SY3Gg8nel+/pTBngsl7Gn3qeiutdTbrGU5dgUXVtd797qwBKu
qntRnqI12uuQisclo0CzKCV3gNPTMql6VePp+c1rAyYMCjYfZdfl5EUbVhTN
PmAFGO0QoVFyErj+ahHfjBVzcbTxsG/SKD5UM4+uoHTSxCcbamt+4OPbqEzs
aAschB+yVSQhvqdBt6EsKlxs4jPMRexjn0Zyy5XJVQPxlVPsyxdfnFoVMykA
G3BeaqkH/8GKl2hHoH0zZBAaWjOcjCiZt83usOPY/5vc2Wa4JHDmNYnV0FoJ
Gj4f19/gwWOb4Vck/4Y0LvTyw3o6+Le1I44ZgmhgHaPkSi4zz7DvA7eH2dXa
5QrmAZhhK/K2NzlF7tUflswSZ+s69A8ndQU4rutnn0fl7AUeKftFqCugr1an
rLOQUy1k09UlWAuIpQixaGojU2+kF8W8ZGQmNHRsJ8ytPxvNc8+KJXvtARiD
SKU+vVByY2fNFmz62yZbLcCYoMtaJflUKTCu4dy9ssG38lH+QNmRWXlbk/vH
jIAaJJ1EXARSsQyLWWjIhcCJgROfMn7z/WeLesWRSUnDpbVxnN9TVVTnmWRS
RymyJrqDKDIB0xqzpDu5H6vXym8c2oVKmQeYRAVdJoWElV52OIj16gTKSrqS
mHPve9cd0zZpob7LFl8f8MWjA2lDnNDiE2o8jL6farDQgrvchSlkRduid68t
1WYh/WM66Qjjw9xOuSIMceGCF21Vg0l1q61POAtT6P2YUVNQWTEfYdLbnq4H
bKk3w5xbQYeclqQWRfNBxtpaVBFul260RpQmokxOrLZZcD+kpuufDaUfVGaA
McrJel72ARa40+AeHYXiWjF6VYPCOo4Dxrg5UllyMHTxQnQbjm23befw4xl7
6TRUFvNGZvhD+4r6yEb3FX7onibKbErv0SY3uJCAtJLdhSvdxkow2AlDhzqK
X6DOkb8NQzuXR83M8bGDlOlGxx4rLgNtaZZJj2KTOhlGzAx8xXLv/YMnIbw8
7ktc3F90a1Lim+XMGkFRYoFxx5GdYtnBZH3vaI30Ok0cCpcLkXbx7UB+ZRbd
NhqSQrikiwM4tC7qZluGEo3xrooptxW27H3IWrOrW1Gkb1gtY7cZ6gDrVjqY
cZtMbvTFl7Oj++tkCAxPpJyXPHUygjTkxHcemqFk6t2I3i+gsPEovLv6/UiL
Eh4017u6oB5NJrmzfhnfrKk6AivkfBeqB6EgLgURsJwyIYvIp6Ra0IdWxM3+
LFdnqJdPajWMGfC1+AIczAuRNtxxq4tvX11EawVO43082J6ULv+Y1U3F3ZHl
+dyF53Wx07rr8IpxeMHwC5oq5s9Jgldaf7nrzaLkZ3bDFR1X4vuXsyrpOISu
1jzflfI+bsX5PYUPVN9Q3uMq6siI+5M2HJzfjOvnD3gDjNhdUsLjEyr4KqSo
w1h/CVpDAvDSFl7sQu/Q9bzIvC97eWrUqjwaMFyPBz47GfjsYRjkGB54aB/Z
z+0X9kv72H71az6TYR5M/sL/yTjvjuh/x2SrH+kPfYN/Rja8T4m5oUuxehb3
X209A6Djn34axfDPX289SY7HvoqufoUatcLQ+y+NXsb9i851fy+Wt2pZ13/9
7KW3eL156+kiptGEPhJ7IaPb2bRTNorsmdIJy0dR+jC1hrKa0XHPJi4Fg6IL
M5He4lI+2M35s2ffY+B5luclV14P3MTotRAKdrGVc/70xSvL/CnDvhGr+o3z
lXBPfBDdX0cfNSRRHkU12eKstrgAjSNM4gV8bf8FcOJfGldOVi3mhszeTHxP
/b8D3X9Gj/+r/Qwew784zjahCyL/1Rh5EcZZA/97Yn0zqmHWZp5ouS9Diuwm
zjAJaYfavRuDRYIbFHCHl/1FQfXaN5W551+gNJZ7iD5HxkQ7gdVN67o0Rrcj
27a2nVantPKxfTIUDaaHYJDw0G6clp75OzsS2qratp2eCjiqjw6wytttq69G
6RT03QGCu3cCfh/RZ6dsovVW9VEb/bit4kLId4htWPwFW1InlB639LhUqHMc
UfKsxUSg6pVc6pV9/lCMA4c7iGelHksbKyhs1Q0Hm/0MdiI4xn08JKV47MOk
wYGDmEclWu5tx7cudfzqgZIP0rHRy313ycdq183PRFfEo5KPvo6Iy+dS/KsR
nRK+RZ8MfDshKlDgU+Yd5mi1cpwK8hs2I+RLG1phnvCVEHIFFumYfKVd0Pzj
3pKSyhHdoax6hoygrZRrTCnl4tH4Wi7u2jOirnuEbghWvLqO+ReR5mO5FJJc
qrHRn9H9AWwyffQVXuH+LjKv0KkSbvFipBIvkeckmgTGnaiJ2U7Re8fHwU3g
XO6vXOptcawXTOCSH//+/ig5KbwUjGKWsCDiO1S2dtbrqYj+dSYFl399r6rv
gZ57nS0L+xRopqkxB6xcqeuZC8bVWJT4u9TE7tSFW2r/MqYLWG9gv9+5Bmbp
PmLA1xd+tDUPRSWFz4FIMlfaH1z5Uxk6tsrttaGI7JVrHV5pb88BfLOC0v6v
ULJsJdcdEePPf/r3G9B4AdfaN3gLF3XoyJbUsjNUB8FTL87PXl1enckzGG+R
Ql7LbYR+qJscaCBuvNczovFwX1zFuZvUmYk2NTAQNVHyHSd72X1Z//j2jeLL
HfV8qLA7KoKM+zXsHSXODen3E6F3/jfqz4SjKccAAA==

-->

</rfc>
