<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-tiesel-taps-communitgrany-03" category="info">

  <front>
    <title abbrev="Communication Units Granularity">Communication Units Granularity Considerations for Multi-Path Aware Transport Selection</title>

    <author initials="P.S." surname="Tiesel" fullname="Philipp S. Tiesel">
      <organization>TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstr. 23</street>
          <city>Berlin</city>
          <country>Germany</country>
        </postal>
        <email>philipp@inet.tu-berlin.de</email>
      </address>
    </author>
    <author initials="T." surname="Enghardt" fullname="Theresa Enghardt">
      <organization>TU Berlin</organization>
      <address>
        <postal>
          <street>Marchstr. 23</street>
          <city>Berlin</city>
          <country>Germany</country>
        </postal>
        <email>theresa@inet.tu-berlin.de</email>
      </address>
    </author>

    <date year="2018" month="November" day="03"/>

    <area>Transport</area>
    <workgroup>TAPS Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>This document provides an approach how to reason about the composition of multi-path aware transport stacks. It discusses how to compose the functionality needed by stacking existing internet protocols and the fundamental mechanisms that are used in multi-path systems and the consequences of applying them to different granularities of communication units, e.g, on a message or stream granularity.
This document is targeted as guidance for automation of destination selection, path selection, and transport protocol selection.</t>



    </abstract>


  </front>

  <middle>


<section anchor="intro" title="Introduction">

<t>Today’s Internet architecture faces a communication endpoint with a
set of choices, including choosing a transport protocol and picking an
IP protocol version.
In many cases, e.g., when fetching data from a CDN, an endpoint
has also the choice of which endpoint instance,
<xref target="I-D.brunstrom-taps-impl"/> calls these instances <spanx style="verb">Derived
Endpoint</spanx>, to contact as DNS can return multiple alternative addresses.</t>

<t>If endpoints want to take advantage of multiple available paths,
there is another bunch of, partially interdependent, choices:</t>

<t><list style="symbols">
  <t>Which path(s) between the endpoints could be used?</t>
  <t>Which path(s) between the endpoints should be used?</t>
  <t>Should the paths be used in an active/active way or only as active/fallback?</t>
  <t>Which protocols or sets of protocols should be used?</t>
  <t>Which role will other on-path elements, e.g. middle-boxes, take
in servicing this flow?</t>
</list></t>

<t>Implementing an heuristic or strategy for choosing from this
overwhelming set of transport options by each application puts a huge
burden on the application developer.
Thus, the decisions regarding all transport options mentioned so far
should be supported and, if requested by the application, automated
within a the transport layer.
In order to build such automatization, we need to be able to compare
the product of all transport options (destinations, paths, transport
protocols and protocol options) available to choose the most
appropriate.</t>

<t>As the protocols to be used are not known a priori and can differ
depending on other transport options, this reasoning has to be
independent of a specific protocol or implementation and allow to
compare them even if they operate on different communication unit
granularities.</t>

<section anchor="communication-units-vs-layering" title="Communication Units vs. Layering">

<t>When reasoning about network systems, layering traditionally has been the main guidance on where functionality is placed.
Looking at modern systems, the classical concept of layers and their mapping to protocols becomes blurry.
Protocols can operate on different granularities of communication units, i.e., the semantic units such as messages that the protocols distinguish.
These communication units often do not match the PDUs used by the protocols, e.g., TCP segments do not necessarily align with messages at the application layer.</t>

<t>In this document, we do not want to take a protocol-centric perspective, but we focus on mechanisms a multi-access system is composed of and the communication units they operate on.
This has several advantages:</t>

<t><list style="symbols">
  <t>We can much easier abstract from the protocols used and look
at the composition itself.</t>
  <t>By disseminate on which kind of communication unit these mechanisms can operate, we can reason about the overall design space.</t>
  <t>If seeing the same mechanism multiple times within the same
system composition, we can reason about possibly conflicting
optimizations.</t>
</list></t>

<t>Overall, this perspective allows us to compare mechanism like
distributing requests of an application among different paths, MPTCP
and using bandwidth aggregation proxies (as discussed within the IETF
in the BANANA working group) despite their different nature and layer
of implementation.</t>

</section>
</section>
<section anchor="unit-h" title="Abstract Hierarchy of Communication Units">

<t>These communication units definitions are primarily used for reasoning
about automatic stack composition. Therefore, depending on the protocol
stack instance, a communication unit can span multiple protocol
instances.</t>

<t>Some of these hierarchy levels correspond to objects in
<xref target="I-D.ietf-taps-minset"/>, but in case of Association and Association
Set, we have to split categories as they may indeed be separate on the
transport.
Note the naming confusion concerning the term “flow” deriving from different perspective.</t>

<t>We also annotate the corresponding terminology used in <xref target="I-D.ietf-taps-arch"/> if it differs from the one used in this document.</t>

<section anchor="message" title="Message">

<t>An Message is a piece of data that has a meaning for the application.
It is the smallest communication unit that we consider.</t>

<t><xref target="I-D.ietf-taps-minset"/> correspondent: Message</t>

<t>Examples:</t>

<t><list style="symbols">
  <t>A HTTP-Request/Response-Header/Body for HTTP/2</t>
  <t>An XML message in XMPP</t>
</list></t>

</section>
<section anchor="stream" title="Stream">

<t>A Stream is an ordered sequence of related Messages that should be treated the same by the transport system.</t>

<t><xref target="I-D.ietf-taps-minset"/> correspondent: Flow</t>

<t>Examples:</t>

<t><list style="symbols">
  <t>A Stream in QUIC or SCTP</t>
  <t>A TCP connection used as transport for XMPP</t>
</list></t>

</section>
<section anchor="association-connection-group" title="Association / Connection Group">

<t>An Association multiplexes a set of Messages or Streams within the same Flow
with common source and destination. Therefore these communication units become
indistinguishable for the network.
Association and flow describe the same concept, the former from the perspective
of the application, the latter from the perspective of the network.</t>

<t><xref target="I-D.ietf-taps-minset"/> correspondent: Flow-Group</t>

<t><xref target="I-D.ietf-taps-arch"/> correspondent: Connection Group</t>

<t>Examples:</t>

<t><list style="symbols">
  <t>A TCP connection carrying HTTP/2 frames</t>
  <t>A set of IP packets that carry TCP or UDP segments and share the same 5-tuple of src-address, dst-address, protocol, src-port, dest-port.</t>
</list></t>

</section>
<section anchor="association-set-flow-group" title="Association Set / Flow-Group">

<t>An Association Set or Flow Set is a set of Associations or Flows that belong
together from an application point of view.</t>

<t><xref target="I-D.ietf-taps-minset"/> correspondent: Flow-Group</t>

<t>Examples:</t>

<t><list style="symbols">
  <t>Two flows, one carrying RTP payloads and one used for RTCP control messages.</t>
</list></t>

</section>
</section>
<section anchor="mechanisms-used-in-multi-path-systems" title="Mechanisms Used in Multi-Path Systems">

<t>Transport protocols on the Internet provide a large variety of functionality.
While the functionality of simple protocols like UDP is easy to describe (multiplexing streams of messages), describing the functionality of complex protocols such as QUIC, MPTCP or SCTP is manyfold as these protocols provide a set of commonly used functionality.
Also, the same functionality can be provided at many places throughout the whole stack.
In the following, we explore the set of functionality that can be provided by transport protocols.</t>

<section anchor="destination-selection" title="Destination Selection">

<t>Destination Selection refers to selecting one of multiple
different destinations. This mechanism is applicable to any kind
of communication unit and can occur on all layers.</t>

<t>Typical cases for destination selection include:</t>

<t><list style="symbols">
  <t>Choosing one address of a multi-homed server for an upcoming communication.</t>
  <t>Choosing a server among a list of servers retuned by DNS,
 e.g for servers that host the same content as part of a CDN.</t>
  <t>Choosing a backend server within a load balancer.</t>
</list></t>

<t>In practice, destination address selection is often tied to name
resolution.
As name resolution relies on both local decisions on the endpoint as well
as decisions within the DNS infrastructure, this mechanism spreads
across different administrative domains which each independently
contribute to the overall selection result.</t>

</section>
<section anchor="path-selection" title="Path Selection">

<t>Path Selection refers to choosing which of the available paths to use.
and can occur on the network layer and any layer below.</t>

<t><list style="symbols">
  <t>Within an end-host, path selection is usually realized by choosing
the source IP address and thus choosing one of the local network
interfaces for the communication to the remote endpoint.</t>
  <t>Within a path layer traffic system like an MPTCP-Proxy or
a BANANA-Box, path selection is usually realized by choosing the
outer source and destination address.</t>
  <t>In case of an ECMP router, path selection is usually done based on
a 3- or 5-tupel and just determines the interface to the next hop.</t>
  <t>Within MPTCP, each TCP segment has to be assigned to one or more
subflows for transmission to the receiver.</t>
</list></t>

<t>While path selection involves a choice of access network it does not
need knowledge of or changes to the routing choices within the core
network.</t>

<t>When doing path selection on small communication units like TCP
segments, it is not uncommon to split path selection into two
subproblems: <spanx style="emph">Candidate Path Selection</spanx> determines feasible and
preferred choices, e.g., in case of MPTCP by establishing subflows.
Afterwards, <spanx style="emph">Per-Chunk Path Selection</spanx> selects among these alternatives
for each chunk. Thus, the first can be more expensive while the latter
should be easy to execute.</t>

<t>TODO: Discuss difference between Multiple Provisioning Domains
<xref target="RFC7556"/> or multiple access networks within the same provisioning
domain – especially when it comes to integrating 3GPP mechanisms like
<xref target="RFC5555"/> or <xref target="RFC7864"/>.</t>

</section>
<section anchor="chunking" title="Chunking">

<t>Chunking refers to splitting an message, a stream or a set of associations into one or more parts.
Typically, chunking splits only large messages or streams into multiple
ones while keeping smaller entities untouched.
Associations or Flows are typically not split, but sets
of Associations or Flows might be partitioned.
Once split into chunks, each chunk can be transferred individually over
different transfer options.</t>

<t>Chunking can and does occur at different layers within a system:</t>

<t><list style="symbols">
  <t>A Web site consists of multiple objects or files.
Thus, the files can be seen as the natural chunks of a Web site.</t>
  <t>TCP takes as input a byte stream and chunks it into segments.
TCP chunking (segmentation) occurs at arbitrary byte ranges,
thus it will most likely not align with boundaries of Messages that
were multiplexed within an application layer Association on top of
a TCP connection.</t>
</list></t>

<t>In practice, chunking is often constrained in order to maintain certain
properties that are desirable for the overall system.
Examples such restrictions include the following:</t>

<t><list style="symbols">
  <t>Segmentation in TCP restrict the chunk size,
i.e. TCP segment size, to the IP MTU  or IP Path MTU to avoid
fragmentation at the IP layer.</t>
  <t>Equal cost multipath routing does not distribute packets, but
Flows to avoid reordering.</t>
</list></t>

</section>
<section anchor="scheduling" title="Scheduling">

<t>Scheduling refers to distributing chunks or sets of chunks across
multiple pre-chosen path. Thus, depending on the objectives, it can
make sense to see scheduling as is nothing else than per-chunk path
selection as defined above. In other cases, e.g. when trying to balance
traffic, it makes sense to look at scheduling as a concept itself that
uses chunking and per-chunk path selection as sub-mechanisms.</t>

<t>Examples of scheduling strategies include:</t>

<t><list style="symbols">
  <t>Schedule all chunks on one path as long as this path is available, otherwise fall pack to another.</t>
  <t>Distribute chunks based on path capacity.</t>
</list></t>

</section>
</section>
<section anchor="cost-of-transport-option-selection" title="Cost of Transport Option Selection">

<t>Transport option selection mechanisms are often intertwined.
 Which mechanism is used by which layer or which network component
depends on the transfer objectives as well as the state of the network,
e.g., availability, path throughput, path RTT, server load.</t>

<t>The cost and complexity of transport option selection depends on the
network state used and the number of transfer options.
If the transfer option selection only uses local state e.g., link
availability, and the mechanism is predetermined and/or uses simple
mechanisms, e.g., a simple hash function, the cost can even be
negligible.
An example where transfer option selection is cheap is ECMP
within a router.
In other cases, the cost can be non-trivial, e.g. when the selection
involves queries to remote entities or even active network performance
measurements.
Such examples include DNS or DHT lookups, as used by some file sharing
protocols, or network measurements like RTT and bandwidth estimations
used by many video streaming applications. Indeed, costs may be
prohibitive, e.g when requiring multiple DNS lookups for every 1 second
chunk of a 20 minute video.</t>

</section>
<section anchor="involvement-of-on-path-elements" title="Involvement of On-Path Elements">

<t>It may become necessary to take path layer components (middle-boxes)
into account that interfere with the transport layer.</t>

<t>While the classical “End-To-End Arguments in System Design”
<xref target="End-To-End"/> advocates for a dumb network and placing functionality
as close to the edge and up in the stack as possible, there are always
tussles of moving functionality up or down the stack.
This document does not argue against pushing some multi-path
functionality down the stack, but advocates to maintain the control
of the overall system composition at the end host.
Functionality provided by a path can indeed be a reason to choose this path for a given communication unit.</t>

<t>Some flow off-loading mechanisms that come in gestalt of of logical interfaces, e.g., <xref target="RFC7847"/>.
These interfaces treat some association sets differently, which can be considered on-path functionality.</t>

</section>
<section anchor="overview-of-mechanisms-provided-by-selected-ietf-protocols" title="Overview of Mechanisms provided by selected IETF Protocols">

<texttable>
      <ttcol align='left'>Protocol</ttcol>
      <ttcol align='center'>Congestion Control</ttcol>
      <ttcol align='center'>Ordering</ttcol>
      <ttcol align='center'>Reliability</ttcol>
      <ttcol align='center'>Integrity P.</ttcol>
      <ttcol align='center'>Confidentiality P.</ttcol>
      <ttcol align='center'>Authenticity P.</ttcol>
      <ttcol align='center'>Chunking</ttcol>
      <ttcol align='center'>Multiplexing</ttcol>
      <c>HTTP</c>
      <c>r</c>
      <c>r</c>
      <c>r</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>bytes</c>
      <c>requests</c>
      <c>HTTPS</c>
      <c>r</c>
      <c>r</c>
      <c>r</c>
      <c>r</c>
      <c>r</c>
      <c>r</c>
      <c>bytes</c>
      <c>requests</c>
      <c>XMPP</c>
      <c>r</c>
      <c>r</c>
      <c>r</c>
      <c>(r)</c>
      <c>(r)</c>
      <c>(r)</c>
      <c>&#160;</c>
      <c>messages</c>
      <c>SIP</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>+</c>
      <c>(r)</c>
      <c>(r)</c>
      <c>(r)</c>
      <c>&#160;</c>
      <c>messages</c>
      <c>DTLS</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>&#160;</c>
      <c>services,name</c>
      <c>TLS</c>
      <c>&#160;</c>
      <c>r</c>
      <c>r</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>&#160;</c>
      <c>services,name</c>
      <c>RTP</c>
      <c>+(prf)</c>
      <c>+(prf)</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>messages(prf)</c>
      <c>messages</c>
      <c>SRTP</c>
      <c>+(prf)</c>
      <c>+(prf)</c>
      <c>&#160;</c>
      <c>+</c>
      <c>+</c>
      <c>r(sig)</c>
      <c>messages(prf)</c>
      <c>messages</c>
      <c>QUIC</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>+(tls)</c>
      <c>bytes</c>
      <c>connection-id,+(tls)</c>
      <c>UDP</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>ports</c>
      <c>DCCP</c>
      <c>+</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>ports</c>
      <c>TCP</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>bytes</c>
      <c>ports</c>
      <c>MPTCP</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>bytes</c>
      <c>ports</c>
      <c>SCTP</c>
      <c>+</c>
      <c>+</c>
      <c>+</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>bytes</c>
      <c>ports,streams</c>
      <c>IPsec (ESP)</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>+</c>
      <c>+</c>
      <c>r(ike)</c>
      <c>&#160;</c>
      <c>spi,next-header</c>
      <c>IPsec (AH)</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>+</c>
      <c>&#160;</c>
      <c>r(ike)</c>
      <c>&#160;</c>
      <c>spi,next-header</c>
      <c>IP</c>
      <c>&#160;</c>
      <c>(+(fr))</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>(fragments)</c>
      <c>address,next-header</c>
      <c>NEMO/IFOM</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>&#160;</c>
      <c>r</c>
      <c>r</c>
      <c>assoc.</c>
      <c>&#160;</c>
</texttable>

<t>Legend:</t>

<t><list style="hanging">
  <t hangText='r:'>
  Protocol requires transport service.</t>
  <t hangText='+:'>
  Protocol provides transport service.</t>
  <t hangText='prf:'>
  Realized by content specific profiles.</t>
  <t hangText='tls:'>
  Uses TLSv1.3 as sub-protocol; imports authenticity protection and multiplexing from TLS.</t>
  <t hangText='ike:'>
  Realized externally by external protocol IKE/IKEv2.</t>
  <t hangText='sig:'>
  Realized externally by external signaling protocol (e.g., SIP, XMPP, WebRTC).</t>
</list></t>

<t>fr:
:Only when fragmentation is used and only to re-assemble IP PUDs</t>

</section>
<section anchor="acknowledgements" title="Acknowledgements">

<t>This work has been supported by Leibniz Prize project funds of DFG - German Research Foundation: Gottfried Wilhelm Leibniz-Preis 2011 (FKZ FE 570/4-1).</t>

</section>


  </middle>

  <back>


    <references title='Informative References'>





<reference  anchor="RFC5555" target='https://www.rfc-editor.org/info/rfc5555'>
<front>
<title>Mobile IPv6 Support for Dual Stack Hosts and Routers</title>
<author initials='H.' surname='Soliman' fullname='H. Soliman' role='editor'><organization /></author>
<date year='2009' month='June' />
<abstract><t>The current Mobile IPv6 and Network Mobility (NEMO) specifications support IPv6 only.  This specification extends those standards to allow the registration of IPv4 addresses and prefixes, respectively, and the transport of both IPv4 and IPv6 packets over the tunnel to the home agent.  This specification also allows the mobile node to roam over both IPv6 and IPv4, including the case where Network Address Translation is present on the path between the mobile node and its home agent.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5555'/>
<seriesInfo name='DOI' value='10.17487/RFC5555'/>
</reference>



<reference  anchor="RFC7556" target='https://www.rfc-editor.org/info/rfc7556'>
<front>
<title>Multiple Provisioning Domain Architecture</title>
<author initials='D.' surname='Anipko' fullname='D. Anipko' role='editor'><organization /></author>
<date year='2015' month='June' />
<abstract><t>This document is a product of the work of the Multiple Interfaces Architecture Design team.  It outlines a solution framework for some of the issues experienced by nodes that can be attached to multiple networks simultaneously.  The framework defines the concept of a Provisioning Domain (PvD), which is a consistent set of network configuration information.  PvD-aware nodes learn PvD-specific information from the networks they are attached to and/or other sources.  PvDs are used to enable separation and configuration consistency in the presence of multiple concurrent connections.</t></abstract>
</front>
<seriesInfo name='RFC' value='7556'/>
<seriesInfo name='DOI' value='10.17487/RFC7556'/>
</reference>



<reference  anchor="RFC7864" target='https://www.rfc-editor.org/info/rfc7864'>
<front>
<title>Proxy Mobile IPv6 Extensions to Support Flow Mobility</title>
<author initials='CJ.' surname='Bernardos' fullname='CJ. Bernardos' role='editor'><organization /></author>
<date year='2016' month='May' />
<abstract><t>Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to the same PMIPv6 domain through different interfaces.  This document describes extensions to the PMIPv6 protocol that are required to support network-based flow mobility over multiple physical interfaces.</t><t>This document updates RFC 5213.  The extensions described in this document consist of the operations performed by the local mobility anchor and the mobile access gateway to manage the prefixes assigned to the different interfaces of the mobile node, as well as how the forwarding policies are handled by the network to ensure consistent flow mobility management.</t></abstract>
</front>
<seriesInfo name='RFC' value='7864'/>
<seriesInfo name='DOI' value='10.17487/RFC7864'/>
</reference>



<reference  anchor="RFC7847" target='https://www.rfc-editor.org/info/rfc7847'>
<front>
<title>Logical-Interface Support for IP Hosts with Multi-Access Support</title>
<author initials='T.' surname='Melia' fullname='T. Melia' role='editor'><organization /></author>
<author initials='S.' surname='Gundavelli' fullname='S. Gundavelli' role='editor'><organization /></author>
<date year='2016' month='May' />
<abstract><t>A logical interface is a software semantic internal to the host operating system.  This semantic is available in all popular operating systems and is used in various protocol implementations. Logical-interface support is required on the mobile node attached to a Proxy Mobile IPv6 domain for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming, and flow mobility support.  This document explains the operational details of the logical-interface construct and the specifics on how link-layer implementations hide the physical interfaces from the IP stack and from the network nodes on the attached access networks.  Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in conjunction with various mobility management features.</t></abstract>
</front>
<seriesInfo name='RFC' value='7847'/>
<seriesInfo name='DOI' value='10.17487/RFC7847'/>
</reference>

<reference anchor="End-To-End" >
  <front>
    <title>End-to-end arguments in system design</title>
    <author initials="J." surname="Saltzer" fullname="J. H. Saltzer">
      <organization></organization>
    </author>
    <author initials="D." surname="Reed" fullname="D. P. Reed">
      <organization></organization>
    </author>
    <author initials="D." surname="Clark" fullname="D. D. Clark">
      <organization></organization>
    </author>
    <date year="1984" month="November"/>
  </front>
  <seriesInfo name="ACM Transactions on Computer Systems" value="Vol. 2, pp. 277-288"/>
  <seriesInfo name="DOI" value="10.1145/357401.357402"/>
</reference>



<reference anchor="I-D.ietf-taps-minset">
<front>
<title>A Minimal Set of Transport Services for End Systems</title>

<author initials='M' surname='Welzl' fullname='Michael Welzl'>
    <organization />
</author>

<author initials='S' surname='Gjessing' fullname='Stein Gjessing'>
    <organization />
</author>

<date month='September' day='27' year='2018' />

<abstract><t>This draft recommends a minimal set of Transport Services offered by end systems, and gives guidance on choosing among the available mechanisms and protocols.  It is based on the set of transport features in RFC 8303.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-taps-minset-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-taps-minset-11.txt' />
</reference>



<reference anchor="I-D.ietf-taps-arch">
<front>
<title>An Architecture for Transport Services</title>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<author initials='A' surname='Brunstrom' fullname='Anna Brunstrom'>
    <organization />
</author>

<author initials='G' surname='Fairhurst' fullname='Gorry Fairhurst'>
    <organization />
</author>

<author initials='C' surname='Perkins' fullname='Colin Perkins'>
    <organization />
</author>

<author initials='P' surname='Tiesel' fullname='Philipp Tiesel'>
    <organization />
</author>

<author initials='C' surname='Wood' fullname='Christopher Wood'>
    <organization />
</author>

<date month='October' day='22' year='2018' />

<abstract><t>This document provides an overview of the architecture of Transport Services, a system for exposing the features of transport protocols to applications.  This architecture serves as a basis for Application Programming Interfaces (APIs) and implementations that provide flexible transport networking services.  It defines the common set of terminology and concepts to be used in more detailed discussion of Transport Services.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-taps-arch-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-taps-arch-02.txt' />
</reference>



<reference anchor="I-D.ietf-taps-interface">
<front>
<title>An Abstract Application Layer Interface to Transport Services</title>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<author initials='M' surname='Welzl' fullname='Michael Welzl'>
    <organization />
</author>

<author initials='T' surname='Enghardt' fullname='Theresa Enghardt'>
    <organization />
</author>

<author initials='G' surname='Fairhurst' fullname='Gorry Fairhurst'>
    <organization />
</author>

<author initials='M' surname='Kuehlewind' fullname='Mirja Kuehlewind'>
    <organization />
</author>

<author initials='C' surname='Perkins' fullname='Colin Perkins'>
    <organization />
</author>

<author initials='P' surname='Tiesel' fullname='Philipp Tiesel'>
    <organization />
</author>

<author initials='C' surname='Wood' fullname='Christopher Wood'>
    <organization />
</author>

<date month='October' day='22' year='2018' />

<abstract><t>This document describes an abstract programming interface to the transport layer, following the Transport Services Architecture.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the lowest common denominator interface to the transport layer, in an environment where endpoints have multiple interfaces and potential transport protocols to select from.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-taps-interface-02' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-taps-interface-02.txt' />
</reference>



<reference anchor="I-D.brunstrom-taps-impl">
<front>
<title>Implementing Interfaces to Transport Services</title>

<author initials='A' surname='Brunstrom' fullname='Anna Brunstrom'>
    <organization />
</author>

<author initials='T' surname='Pauly' fullname='Tommy Pauly'>
    <organization />
</author>

<author initials='T' surname='Enghardt' fullname='Theresa Enghardt'>
    <organization />
</author>

<author initials='K' surname='Grinnemo' fullname='Karl-Johan Grinnemo'>
    <organization />
</author>

<author initials='T' surname='Jones' fullname='Tom Jones'>
    <organization />
</author>

<author initials='P' surname='Tiesel' fullname='Philipp Tiesel'>
    <organization />
</author>

<author initials='C' surname='Perkins' fullname='Colin Perkins'>
    <organization />
</author>

<author initials='M' surname='Welzl' fullname='Michael Welzl'>
    <organization />
</author>

<date month='March' day='5' year='2018' />

<abstract><t>The Transport Services architecture [I-D.pauly-taps-arch] defines a system that allows applications to use transport networking protocols flexibly.  This document serves as a guide to implementation on how to build such a system.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-brunstrom-taps-impl-00' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-brunstrom-taps-impl-00.txt' />
</reference>




    </references>


<section anchor="changes" title="Changes">

<section anchor="since-00" title="Since -00">

<t><list style="symbols">
  <t>Replaced granularity “Object” with “Message” to align with other TAPS documents.</t>
  <t>Removed empty section on protocol instance selection - this topic will go into a separate document later.</t>
  <t>Minor clarifications.</t>
  <t>Removed definition of normative terms not needed for this document</t>
  <t>Added acknowledgments and updated authors’ affiliation (compliance).</t>
</list></t>

</section>
<section anchor="since-01" title="Since -01">

<t><list style="symbols">
  <t>Updated drafts references</t>
  <t>Added Overview of Mechanisms provided by selected IETF Protocols</t>
  <t>Minor clarifications</t>
  <t>Removed superfluous IANA and Security Considerations section</t>
</list></t>

</section>
<section anchor="since-02" title="Since -02">

<t><list style="symbols">
  <t>Prevent expirary (minor formatting fixes)</t>
</list></t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIADOD3VsAA81c7XLbRpb9j6focn6MNCHpj9iTWe2PWUWyE9VEttaSy1u7
tbUBiSaJMQggaEA0E7tq3mHfcJ9kz7m3G2iQkuNkdrZGqZRJoNF9+36ee2+D
0+k0afO2sCfmrNpsujJfpG1eleZNmbfOfNukZVekTd7ucL90eWYbue/MsmrM
ZVe0+fQqbdfmdJs21txgvKurpjXXtrALjkzS+byxt784f5JVizLdgJCsSZft
tM2ts8W0TWs3Xeij7QrDd9NHXyVZ2mLgk0eP/zh9/JgXMKtdVc3uxOTlskqS
vG5OTNt0rn3y6NE/PXqSgLr0ZKAv2VbNu1VTdTUunl5dm7f4npcrUIRryTu7
w4DsxFyUrW1K207PSVSSuDYts/9Ki6rE+jvrkjo/Mf/RVouJcZi2sUuHT7sN
P/xnkqRdu66ak8RME4O/vHQn5mpmrmfmRrYnV3XXV+u8yOt6717VrNIy/0l4
BkrfmG9sU+Sl3HNYzrYn5jJtFmt8mZknX8mNBdh5Eo9cVF3Zkjnf2mYDFspF
u0nz4sTUuu6/5NjlrO2mc3lsltkR0Tcz87xcrdMmayOab9a2sS4d3/r7k9zq
sneQnJQVRrf5rT2BDkAT+m/GvH5x9gx//uPXz579IXz84x+e9h+ffs2Pz8ts
elNN8c+JOX91MXv8aPb48dNnD7969vXTR49n8s8TjLuYns9y2y5VTTdgFXZ3
cJ2bPbyaU7WW6cKGW/OmK8GTauPvb+oCu8DfdDo16Ry30gVU8GadOwNj6Ta2
bE3dVLewSmfS0qQ1vqWLtVlXW9NWBirvYGrpvOpaMg1M3dSVy8UAq6XZiPnW
NN9UzLftzRd6vnjnZuaiNVnuFp1zWMJPq7NYmXHZlWLlaUEXUVqb2czMd/o8
7cm+z13LD7m3JFIMe6kKkpyFSbKUu0kLs7GLNdTHbRxupa0hWZ3DpHkZ0+t2
rrWbYYoFXJL9sbPlAnRia2BFseOyuLkh0Vm+XEJrwLFV73NyHbsYOSb6Gdiw
na0mhswDRc6lKwu9FvVNN9EMu9meOPC5TZuVbUFx6syqy7MUNIm3hDOoNmlg
PmQGvuhXF5zlxOjuhu+ywV4sgXfDiJmqxybPsgL6n3xBl9VUWSd3Tfj7+Yuc
lz9Cfaos3f3O9Z7NUDvzFrN1YDX1EVzd44kts7rCBGabU1cSaLkwbl3lGD6B
bBZFl5HduAQFw4f0Lqq5mTpXxUjL5OJquHVrGyfbuYCcYe9mkTqrcphNzHZt
S7O0LSjFo/D+qVnCULDK2flLMqknMVmD7WnhKlULoZC0btc5DKPfCCy1pWAm
yc8/32N7Hz+ChqKgHsId908488MP57aBU8mS5366H36YqGFAhRctBX/+8hpP
lzBBsNVrbl1YUEaui08yaZbBjWGXkOHFsqfNmW0KCjFfm77jqFt8FQVcRvPc
whOmc3yiwrhJIj6R6peWFT+bOSxzjWeoUk2bYyc7tcHM1lgKyjoJAoSXmZq3
wiDOduSOzdy2Wwuek4kDYXDKBcxbLfJPn/mQW+8/da1XOEyoD/do43RjC7Ln
of4DZuxoelUJ+ilavbnEfuZwMRERvVuhodpWTHu4eEiFPtZU4OE2LwqjbKtK
dTCwLxq010BvX9N59Z5KScEkjIxYqLnNF+powPxlUW3/BGlCfeRxVXSztl1D
N7jwToRgZSc+obcXUWfOkVQwBeh7seFlb2mDLVW1wi/4WEtXT0cXzLTuWtru
ulvZZN5B0CU9GNkcj8rsrS2q2jb0XR13gwGZXeROJm7sCqFcCAdTDheWbQH+
ZAA8cBdNMnDWdTWH0vWVGbzCEpPBJ7tWY8IeIZPgEGFI9CsUvowZ1izSHcmE
SwAYg3BgE/Mux2Ku49a9P/3JT7e1EoBkFFaicfhohSCSiLapY5QAcefmjiKv
7CbetoZxyTh29c7LP34cmSVXpmw1TG4q1yYSnusmx45h8afOeJL8jEq22AGD
HszYvCurLbmCh6omlzXpVDSWJWrIlBQjimjvwY4mqpeKBDiU7lFWAjzqPYEw
xLgaSrCEkg77akweVFmVhySAdQIEEs9ajbHQqpIixxcYbM08wZKwIfAextlk
FItnDF9f3Jkn3AKKfE9lwBaS5C2jwbAlxTcIZcT0ARlMVHnEMps0yxWkwIeQ
AfPgpYAnyyFIY7mtuNExqgH/6gJxMZsl31eVBq8WIoVGlsNyEm6K1DlQXjAU
LGwtjBU6eqSSN1i0roWuKpL+3II9CC7zomsawIqr/g4lfic/Pw/I5DM7U+oc
4HNJJyR3vA25gG883hrrZKbgrcvdmt6CcfCORbB2C4ZmlSgtTBITc56r8zdO
Fdpbfz9xiOs3Z1cgayWeNjxf2gUpanI6/CJflYo6ejI9kbFL836CjqKN4Zj4
BD/tOKj2pEwXGNdQ6SGk2kp0mcDLtHx0iXkcmR6h0tTD0HRBMr38qSMeFmdi
TD0sPWTWnoF4BEm1dLChBsrTh3wfma3owIbygtLnsPOQDYSwEctMPQgIKKCs
iFLpIfYHGbZYEjqab3YUMlSDXs+bAOMi1Dy7W6c8HopYEmmocFyBz17uUcne
CuJeytTVsCihANDHWeuxunFIBIa5B8DT5rQOHyfCQOzO8z/a3d0k4K7L51Ap
WOYSikO1xuN0kxsfQeiAXimV3m1GOqFej9yNgkpEaJEDEtBcmhzKw9342Kfp
SDnS13RTEcb2luzjzOUV7CGh6DrBBHN83OYZIfdqxbisUb6p3tPgj1LX52ZZ
zJmL5zcvEv/5m9OX+M9sfXVDKh7HlEENyO/90UAHVIBJgCgPTSoB6eMAQB+N
HOM06N930EYmEDvu8i7P/fMX1JnpmpnHvf4js8u8zDUEk62Idxt1AKLMBEq9
u09UniH4LzTVjBVgpnUJPAV1HAXJ2FASfa5PBA6SHtF16hFUNULw/fN9QgCe
XMN3C06TLa57phTEWnQNDZB+XZUCTqr5X6BTDkv75GO/gvDxo3ogyJBZECc+
da5a5EMMjr4n11Yd3Tq9FdzhoGikXCpi1JTUO51NyhQgI0YiWrNQYW/zuJ30
2GGWvKxUOVjmkawONtMRHmpca8pgrUgnNuYBUe8DcBpJUQ9lI+UejAicems1
O0tLOOXULzPwRybGpHlZFdVq16cF+4wie5GgAW/krV/LDc4Q8LR/chQQZoIw
LjWUAIOV4bNkTshNrWaLkmFKPJR0Enaeyp6piXvBB/BU0376pA28BGz+bq+Z
SkxZ+DIqSLlP+hE/QPPJQO/z9ymtUcPCqfnu5uZq+lrdzMPX8oCz0+9siukf
flNlmmJw1MMnfKA0/3b5fV/PyPn16kpB17VUNsAR/0kzSYXdhPq+tkLeNLYg
Zg9UedwwZAF8nvd7b+6Df1RcEp/9KxjwAgp2sPtAaGn+9c3FGbHq9dnNldwi
rACfSy2R+IjoIgrIl2HzsXE9ZJ07PKjFYKpJPCS4gvdSKfEZWs8N0iGUHUQr
3YaAGeoH6z5V1yzU30aJR+S/vEO5y2cqYCSKHzCaZB5BRz0gniX7voPmyvUW
CFV2oM5DVsWKrJwCZwzwYjDiRP3cOJXjBahFe88z3jcONP0q0U+9HO5xAntP
HMpvT3H2tGORAnDTuNVQQD+44WSkly3rVIgVtvW6Lk/INGD1m/MIwpK9EEMT
sfXZtO0YNzCPaxZTX/RBYHLt8CUElYmMoYpORCOm6o8PtBQuH5oa82ZPRzkA
xHGEfM4jVY3GuTDI72xuCyCTpK1WVvJJLbKNwYsW0DDPbW63v1GSI4ncbCvR
STcRx93L4/UN+b4rqjRTzvZunSr+2ouxbaqiTw48PLkcsOkbHwaiVtW1pmwA
JAcVShdQwkVUrWZ9HdwrWNc1t8AlthW4M8oSZ8hK8+KuojgFLyAqWoVoUTQH
cgGw2UmFOljkUe9gpALknQmrf36Xx5MwOMThgxUJhzBBXADz6R6dpYeawWeS
CtZcl1WRebDgYmoHHoTCr7ivHp6N+XCK8D4Z9H9MGvHU3IYZM0mkWe2VBJsr
Qz9W65AzbNeszglQm2lyR89EII6NC+ax7+uiCuamxI0X9AY7XpUR6VD23s7O
o8L80MVM7ryMYCjIg6hLrwnQHNVqkwEKxdUlennyvc8gaKJqZr5+RL4wDUvu
TsNCNahaLLpGWhXIrrTYgJ3c7GotRLCMLgZzZ8PBl+6tGOJZKEZyB943aWlI
U941Ak4mJU+6BnY0QEoN0hQjRhTO4tnS8IimPbAkRCwxC7nspEheqljOX15P
2OqzMwVbYYhiscq1o3jVkqlQWFa4ldCz85d7a7NKbMue7L7SSLeCmwUhvK8d
1Exp8oWdjHgVGBHxLFQ82lzLjeyGJhhUFZ3u/tTJNTNcI2ySMg00sYITKipK
Zyi7VuOyOXe1tUWRMMnrB0WAgg2GvESsgn/opHfjc9ZBoVwNz5G5JF00SH4j
RJ5mkFgudWjG5qxiGcyFFgmrylFtsNgl4mWZ1opaxsm8iwzBQUe8CambHWxn
/D0ymr78rWsHZDFubnAgHM0sOdD4CFKo5mt9Enaj3xjOtlJkeOvFLo2iKRVp
v9VGqXaukxoh+FbkP6lGBhKhlaJ6CtkACYJeaK2nc8NmvAMQTCRi9jRKy8A3
fV2P08am7Rnc2A1zsKAOs2gLSrduECJcsmLrqyASVrBH8e7Tq6Z6z94Ja0C+
EDD9pnr/azcuyaEx8MlY8G7EGnhBMi+GpBWUPD+7vDKNPPupdTOybJ5K9awU
er+aMjoJeLLaOPxL5+hBNTu0mnD17Ax8K+17+ok6YpgwY6J6HdUbh0q4YdF2
Vaopi+was0FQYXWpmwsyUWExZGxy50ZyWljYEB2Ixv/9PZa3VXGrLdW+F+lL
h0FzmcFWGIKEOJEGBsv+hc205SdNorSURMuvWWmByXfvYq+wINkDyJZCeVZx
8B5djAFMVu9MLUSNWIoKuHZCGnOhEEN88tJXGg62TDq3VQLmIbbCjDfuxPz+
DDLMeW5nzzv8PpbpkvVNGj4GJ7X4CaaffaNZq8ZRXURxDJthQAlzBBZpEAex
wRHDTzfbtMnw8O+vbDM9W3fluwMSlHrnI5Tin6hV6xLKXzRowecZu0PnbJk3
rkcYVBtiEoscn73LHhJqbhT1ygLqQxa56KQhdPPq/NWJOdeKXu+toTGhrXoZ
SlBXxDHUQu71XL03YLg/1QLkTQXuO8UjZTtMSutoskRDgfmfv/43GMp2kFin
dN9zqWqoFtLsVoweWP+rb6+u4mKwFEKFGJ62UWKUtj/+4enHj6HJQzZKMyd8
iqEU1Sr0Tj3oZX3OH78g8AhgL41zGdG8yIAFF0AJPBYqdhMVn6gI13DaVlZk
v4ky+AC6ZcYeyFVUUZXpO2ulh6MVH+hG2WobpsMTQNpsFt2dZ0lyGAgSixJS
tOLHvnVyb4q2yVfrVoAsO/rahZ0lr6gjaolCrmzRTSJ1DdopDsybFOsGAMPq
fhnOI5gaxoUm4iySEqcS70+PpYE4bSNs4btdPczSyOQz77d2jlyo9UUwXxvv
NTXURbHfJXiMZc3IznAp7MTRHjRT0aI1ka7sW2FgWIhhgA6CTR+pg+ZlzeIx
PEZrgz4JrNCHAw+D4xMSmGeG7R/5OyKaY2WAtKTSZp6Db81Op27EY08ENHQy
r5wxYB9YLMSLPupvzSuegmp8K29UXMMsW7Ylh8JTX+/fy80VFcSFAHHUNaaU
qDoufeyj3n6XPcClnLCrvNQkuu/C00u09BTAzvyXjfEaH3MbHdtip6cZlaR6
2OgLgKEMoMkpEAQ7ccGWJS8Zp3yiRteRBEgU9xQe9Yd+qPMOOIb8Z/9zFPfl
RoilwHGXN294aJEfJSzwO7Ov2yrP8DwgdrSeb6ZhbOg5Ts3zHzvp+EK0KiHO
EoJ0iOym7w3ZUEwSk8cKvv7il8RehM142PvKa7qTrhBvOXyO/OWo7RTMYDgE
469oGpBEjQw7RWB1EDMpDjHtoGGiZskoKDAAFphs2EPFg077DRZfBrpoZbJl
CcW2kCMQ0FPox1RFw+WSATCkvgHEcsAcKjIjhtTzDNEhMI1CrZaGiNs0dUs8
BBbaNmLmPWFsgFJiY+LSvjmvbVA1sY5pcm8AcrpjRK8Z0QuAMR1i3mwoaEla
Oyznz/rQLOJE20tRmoq9wEoJXXoaE2G0Umq1D8mLrA+ExGii/Nnmjkf2MAlV
SmsGcoN+73xQOL9EANg63yLFQ1KxkZrZWaVJ+VAUe1Xv10CiipmGhogrcYu8
sd5/CD5vt7kEKn/ialTxCKcDNP9T9wXV1a8BIEtvr4QN+iMvfbY8BKpeR0Pi
HKKDkybTuPw8SRRHenbmLBT57MQXoBAk/IXXNzeTUDtgyWAmfUy1dgkcWmjz
Zbf98zcRf8akJ/1xFaGv79kLld1mzj0t7wjEF8u9je8vE8pyzqeeOr/uFyr5
LhlvOqw5Ego8Q4/JhayHEInMqYXMZJB1gORpqHEiq1r3JTh/KqbyAFmOCM25
9xXiHnH+jHVrq7bjz97cvzWesVjbtOYH5pXDqTFNMPWgWOw3RqvPeaaqnLbs
UqbFyKlI8TBoeZ+y/dhZCcdyktqn4x7lMRvgZvwZxSBMuAw5ck6/tAHC7xrr
YcS1HN4ITiIENxZxMNX5dzfiq7oaNKeDUTh2lYl7pKdA/x8doMFzYdl4KU3e
oLUi2uEEAZN1PXzskjC/VF5ZEa08FBLXN8AJnv+WdvFEuOikgQz5gYp1Drgj
R2VYqdvqgawfu1wOXPUhhvvzGxMMwPMtO/MYzIYLzhL1rgLYnjwCui3pq4Qe
75MuVBQbf0TtVakF/Of+bCbGXLSeKOYm/dGhXX/QJ6qV9F7EmaP4OOdxIpAP
eRJfOVD4onUFqqNgsztPJUYF/+Hc14PhzQFz2qw6lQmUVJsOLC4D8T1AgjQM
RI6UZrcVG/bKptRkcAG9eCUYFamcMh0Vt1kcXBSV66sfUjOQ8yO1CTmenHJg
jVQPwEiZkBujk06LbbpzSYuE08euTXV7sAxnY/2YZxH7KfcPvvc4B7lUh5lX
TEpbU3c+I6d4hvP7yXiB8dSaCg0sifGmP+vPpk/oQ45B5eick0drLP+y5DdL
XoyWjfsBaQiKZXREIg1niOLTnCEeq6RW+a3g5P0qSjgUIs3WarmcMniIcey9
4CCKy1OIrGAUouc8NFitRJ+GemHwtD6Xfvo1c+kbfzS9LypK8125HaXGCgX7
JI2JsEZY7xfDmQRBB3r+ea+pQ2vk2Sj2/DQ/6XcRc1G9KD7zDJLpzzAmyYf+
C99G+MAmLTdM2s58D++DeeVxb3hp4YN5bYvcxyp8u5CyAz9fzXSOZc4Sda7i
lIunHSTOU47DsADq/JyXcXetXwoUToc/8+FkevB3cnBxfGXv/uHwz5jjnsd4
GRSyQz0wpzEHf4cXx1c+7N+84+/w4gfJaV08ZzjbNhrmKbz+2yhsPj38njk+
m0Ie+/jVs48pPGqO7/1638V9rn4Y6k37FF5fXN372D0XP5gv/z8pPL/5/vq+
x+6l8H5697/ed/GQQn39As5Rum0RhRGB91H4S1L+O1P4+iaW8pdHdbPcl8f+
xX0efnLpey4OUtXJP6WHr2Nv85so/BweNkeARKM5PptCOfj16dkPJfTl/ffv
m+OoLdyIwn1vM9TUpnk28eNJIc94DMPu+PtlS/mF4Z8xB78TubqDYbTls7NY
yv+AFN6cjSzlrtl/Scq/jcJ9Kd9LoXah/pEplGM+/zAUTkJ/JaLw4gpZoTl6
fn11/PeMKc0R8uN7PZZ47DqfsI08XctB2gMKT787/r+KenfO8TdR+IuzH315
tGyOj+8Z9lulfBSq5OImP4TzAGMqSeHL55evHl68eHX5a2b/JIWfieAkG5p9
cmOkMPnerpAuniRJc5KcDEmLFjdsfIbYR3bkRl+OhvZv5N81FBGNg1/H5yz8
Oab49Tvf/0oQRzj8DWtvgDS3j2dfhfJzKAX9M9/QELNP49SHt0O9Gunv6Eih
nOrEdFgAqjaiB/Ji05tNQTbV/bfhjcCLPz9/iP9vn+BZhO3PeZYFj1Sq4f0s
R5rKAuhOBI9P2LB7fXN2jFmXZPyrMrSdx+2XPHq9SSqdUpubpnyBiY0m9nDe
nDt9R2XRn6MI1SIpWUhNpX8LcHhnFTR/b/N5mf8EWWJDJJdVZfl5AimOnL/4
1kz9D1Jg287yALJ5IY07kndivq3adtnwVNjbvOA7vGHK6VVjsfaTR48fm6MX
f/538+K5efb1o4dPp4+5aXmHnyfVpBKvxz188ydne3f66BG+YvHXVl9FjH+D
wDx4JeXvB1qseuB7hw+kHzA0GLUyKj92Eqo27G9yzk11S/lt6pYpfH9CpJdX
eNUlKsZOtRLSVjU0Vnqbq0p7p+nwZklfHeIbA40sdpmXPNFCypd9mTGmYngX
iCzvf89D3gpx/gVB+ZUJbSpGNSjOcprJqdJe9MOx7K7O5LUE/UkW9zvDtlHh
6yNHUsbPucfj2Yjvj4Xtb/zD8tM0Tltv8lsTw5p/Q3XkHrbEXIGa2mZZdFXn
zAXf6OKWru2iu+uneVzo10T7eCL7gBbeUh72fZ1Ls/poIwvrD6VI/3CZS000
+V9mKlNaGkgAAA==

-->

</rfc>

