<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC7413 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7413.xml">
<!ENTITY RFC8095 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8095.xml">
<!ENTITY I-D.ietf-tls-tls13 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tls-tls13-21.xml">
<!ENTITY I-D.grinnemo-taps-he SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.draft-grinnemo-taps-he-03.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt"?>
<rfc category="info" docName="draft-fairhurst-taps-neat-01" ipr="trust200902">
  <front>
    <title abbrev="Transport Encryption">The NEAT Interface to Transport
    Services</title>

    <author fullname="Godred Fairhurst" initials="G." surname="Fairhurst">
      <organization>University of Aberdeen</organization>

      <address>
        <postal>
          <street>Department of Engineering</street>

          <street>Fraser Noble Building</street>

          <city>Aberdeen</city>

          <code>AB24 3UE</code>

          <country>Scotland</country>
        </postal>

        <email>gorry@erg.abdn.ac.uk</email>

        <uri>http://www.erg.abdn.ac.uk/</uri>
      </address>
    </author>

    <author fullname="Tom Jones" initials="T." surname="Jones">
      <organization>University of Aberdeen</organization>

      <address>
        <postal>
          <street>Department of Engineering</street>

          <street>Fraser Noble Building</street>

          <city>Aberdeen</city>

          <code>AB24 3UE</code>

          <country>Scotland</country>
        </postal>

        <email>tom@erg.abdn.ac.uk</email>

        <uri>http://www.erg.abdn.ac.uk/</uri>
      </address>
    </author>

    <author fullname="Anna Brunstrom" initials="A." surname="Brunstrom">
      <organization>Karlstad University</organization>

      <address>
        <postal>
          <street>Universitetsgatan 2</street>

          <city>Karlstad</city>

          <code>651 88</code>

          <country>Sweden</country>
        </postal>

        <email>anna.brunstrom@kau.se</email>
      </address>
    </author>

    <author fullname="David Ros" initials="D." surname="Ros">
      <organization>Simula Research Laboratory</organization>

      <address>
        <postal>
          <street>Martin Linges vei 25</street>

          <street>1364 Fornebu</street>

          <city>Oslo</city>

          <country>Norway</country>
        </postal>

        <email>dros@simula.no</email>
      </address>
    </author>

    <date day="13" month="November" year="2017" />

    <area>Transport</area>

    <workgroup>TSVWG</workgroup>

    <keyword>transport design, operations and management</keyword>

    <abstract>
      <t>The NEAT System provides an example of a system designed to implement
      the TAPS Transport Services. This document presents the transport
      services that the NEAT User API provides to an application or
      upper-layer protocol. It also describes primitives needed to interface
      to the NEAT Policy Manager and how policies can be adjusted to match the
      API behaviour to the properties required by an application or
      upper-layer protocol using the NEAT User API.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The NEAT (New, Evolutive API and Transport-Layer Architecture for the
      Internet) <xref target="NEAT"></xref> System provides a call-back driven
      API to the network transport layer. It presents a set of transport
      services <xref target="RFC8095"></xref> that the NEAT User API provides
      to an application or upper-layer protocol.</t>

      <t>The NEAT System has been implemented in the NEAT User Module. The
      focus of the present document is on the NEAT User API providing
      transport services to applications. This utilises a lower interface
      provided by a Kernel Programming Interface (KPI), to access the
      traditional Socket API or a transport service implemented in
      userspace.</t>

      <t>This has been designed to support one-sided deployment, and a NEAT
      System can therefore exchange data with a variety of transport peers,
      including:</t>

      <t><list style="symbols">
          <t>Another endpoint using the NEAT System</t>

          <t>An endpoint using native TCP, UDP, or UDP-Lite.</t>

          <t>An endpoint using SCTP (with explicit use of multi-streaming)</t>

          <t>WebRTC broswers</t>
        </list></t>

      <t>Applications that use the NEAT User API can provide information about
      the features desired from the transport layer and determine the
      properties of the offered transport service. It is this additional
      information that enables the NEAT System to move beyond the constraints
      of the traditional Socket API, since the stack then becomes aware of
      what the application/user actually desires or requires for each traffic
      flow. The additional information can be used to automatically identify
      which transport components (protocol and other transport mechanisms)
      could be used to realise the required transport service. This can drive
      the selection by the NEAT System of the best transport components to use
      and determine how these need to be configured <xref
      target="I-D.grinnemo-taps-he"></xref>. In making decisions, the NEAT
      System can utilise policy information provided at configuration,
      previously discovered path characteristics and probing techniques. This
      can be provided by a policy manager acting below the NEAT User API.</t>

      <t><figure>
          <artwork><![CDATA[
         +-------------+
         | Application |
         +-------------+
              | /\  Events & Primitives, Set/Get Properties
             \/  |
          -+-+-+-+-+-+  Callback-based NEAT User API
              | /\
             \/  |          
         +------------+ Properties +-----------+     +-----------+
         |    NEAT    |----------->|   Policy  |<----| Policy    |
         |    Logic   |<-----------|  Manager  |     | Info Base |
         +------------+ Candidates +-----------+     +-----------+ 
           |        |                    |
  +-----------+     +-----------+  +-----------+
  | Transport |     | Transport |  | Path Char.|
  | Protocol  |     | Protocol  |  | Info Base |
  +-----------+ ... +-----------+  +-----------+
           |         |                   |
   -------------------------------------------
      |                  |
  +-----------+      +-----------+
  |  Network  |      |  Network  |
  | Interface |      | Interface |
  +-----------+ ...  +-----------+


Figure 1: An abstract presentation of the NEAT Architecture and User API.]]></artwork>
        </figure></t>

      <t>The architecture of the NEAT System is presented in <xref
      target="D1.1"></xref>, and depicted in Figure 1. Some important features
      of NEAT compared to the existing Sockets API are:</t>

      <t><list style="symbols">
          <t>Event-driven call-back driven interface, enabling applications to
          be designed to respond to events, such as a signal indictaing
          reception of data blocks, the ability to send data blocks, or the
          successful transmission of data blocks. This concrete API is
          described in <xref target="D2.3"></xref>.</t>

          <t>High-level transport interface, independent of the selected
          transport protocol, allowing applications to be written without
          depending on the features of specific transport protocols, and hence
          allowing the most suitable transport protocol to be matched to the
          application, based on the transport features an application requires
          <xref target="RFC8095"></xref>.</t>

          <t>Support for either unordered/unreliable or reliable transport
          services.</t>

          <t>A choice between automatized and explicit support for
          multistreaming.</t>

          <t>Explicit support of multipath transport protocols and network
          architectures.</t>

          <t>A flexible policy framework, allowing applications to describes
          the properties they expect or those they require of the transport
          system and thus enabling the transport services to be configured to
          match the capabilities of the network that is being used.</t>

          <t>Ability to work with other network-layer protocols (e.g., network
          signalling) to realise the required transport service.</t>
        </list></t>

      <t>The NEAT Library is an open source implementation and is available
      for download <xref target="NEAT-GIT"></xref>. This also provides
      tutorials and examples of code utilising the API and descriptions of the
      way in the which callback mechanisms can be used to build applications
      that use this interface. Further documentation for the current NEAT
      System is available at the NEAT Project web page, <xref
      target="NEAT-DOC"></xref>.</t>
    </section>

    <section title="The NEAT Context">
      <t>Applications interact with the network by sending, receiving and
      controlling NEAT Flows.</t>

      <t>The first step in establishing a flow with the NEAT System is to call
      a primitive to create and configure a Context. In the remainder of this
      document, the label P: is used to identify a primitive that may be
      called for a NEAT Context, and the label E: to identify an event
      provided by the NEAT System. Each primitive/event is associated with a
      particular NEAT Context. Most primitives specify the Context and provide
      a handle to the NEAT Flow upon which they operate, and the primitives
      and events for manipulating data can only be used after a NEAT Flow has
      been created.</t>

      <t><list style="hanging">
          <t hangText="P:">INIT_CTX()</t>
        </list>The INIT_CTX primitive sets up the datastructures needed by the
      NEAT System.</t>

      <t>After all network operations are completed it can free the context.
      It returns a pointer to the newly allocated and initialized NEAT
      context.</t>

      <t><list style="hanging">
          <t hangText="P:">FREE_CTX()</t>
        </list>The FREE_CTX primitive is called when an created context is no
      longer needed. It frees the memory associated with the datastructures
      used by the NEAT System.</t>
    </section>

    <section title="NEAT User API Primitives and Events">
      <t>An application using the NEAT System needs to take the following
      steps to use the network after establishing a context:</t>

      <t><list style="numbers">
          <t>Initialisation: create a flow by calling P: INIT_FLOW; and then
          calling P: SET_PROPERTIES to express the application requirements.
          This is used by the NEAT policy manager. Finally, it needs to bind
          call-back functions to respond to the events generated by the NEAT
          System.</t>

          <t>Establishment / Availability: Connect the NEAT Flow (either
          actively to a destination endpoint or passively to receive from the
          network).</t>

          <t>Writing and reading data: Call primitives to write data or
          respond to events requesting it to read data.</t>

          <t>Maintenance: Call maintenance primitives, as needed, to configure
          attributes of the flow (e.g., while writing reading data).</t>

          <t>Termination: Close (or abort) the NEAT Flow.</t>
        </list></t>

      <section title="NEAT Flow Initialisation">
        <t>An application needs to create and initialise a flow object before
        it can be used.</t>

        <t><list style="hanging">
            <t hangText="P:">INIT_FLOW()</t>
          </list>The INIT_FLOW primitive creates the essential data structures
        required to use a NEAT Flow. The application also needs to then call a
        primitive to associate functions with each of the events that it
        wishes to process.</t>

        <t><list style="hanging">
            <t hangText="P:">SET_PROPERTIES( property_list )</t>

            <t hangText="">property_list : A set of flow properties expressed
            in JSON.</t>
          </list></t>

        <t>Each NEAT Flow has a set of properties that are set at the flow
        initialisation time. The SET_PROPERTIES primitive sets properties for
        the NEAT Flow. Properties are related to Transport Features and
        Services. For instance: link-layer security, transport-layer security,
        certificate verification, certificate and key properties can be set at
        initialisation time are related to a Confidentiality Transport
        Feature. A flow can also have attributes that can be read by an
        application using maintenance primitives after a flow has been
        initialised.</t>
      </section>

      <section title="NEAT Flow Establishment">
        <t><list style="hanging">
            <t hangText="P:">OPEN( destname port [stream_count] )</t>

            <t hangText="">destname : a NEAT-conformant name (which can be a
            DNS name or a set of IP addresses) to which to connect.</t>

            <t hangText="">port : port number (integer) or service name
            (string) to which to connect.</t>

            <t hangText="">stream_count : the number of requested streams to
            open (integer). Note that, if this parameter is not used, the
            system may still use multi-streaming underneath, e.g., by
            automatically mapping NEAT Flows between the same hosts onto
            streams of an SCTP association. Using this parameter disables such
            automatic functionality.</t>

            <t hangText="">Returns: success or failure. If success, it also
            returns a handle for a NEAT Flow.</t>
          </list>The OPEN primitive opens a flow actively for transports that
        require a connection handshake (e.g., TCP, SCTP), and opens the flow
        passively for transports that do not (e.g., UDP, UDP-Lite). Calling
        P:OPEN alone may not actually have an effect &ldquo;on the
        wire&rdquo;, i.e., a P: ACCEPT at the peer may not be triggered by it.
        Since it is possible that the remote endpoint only returns when data
        arrives, this may only happen after the local host has called P:
        WRITE. (This does not result in a problem, since P: ACCEPT does not
        block).</t>

        <t><list style="hanging">
            <t hangText="E:">on_connected</t>
          </list>The on_connected event indicates a successful connection
        setup. An application that receives this event can then use other
        primitives with this flow.</t>

        <t><list style="hanging">
            <t hangText="P:">OPEN_WITH_EARLY_DATA( destname port
            [stream_count] [flow_group] [stream] [pr_method pr_value]
            [unordered_flag] data datalen)</t>

            <t hangText="">destname : defined in the same way as in P:
            OPEN.</t>

            <t>port : defined in the same way as in P: OPEN.</t>

            <t>stream_count : defined in the same way as in P: OPEN.</t>

            <t>flow_group : defined in the same way as in P: OPEN.</t>

            <t>stream : the number of the stream to be used. At the moment
            this function is called, a connection is still not initialised and
            the protocol may not be known. If the protocol chosen by the NEAT
            Selection components supports only one stream, this parameter will
            be ignored.</t>

            <t>pr_method and pr_value : if these parameters are used, then
            partial reliability is enabled and pr_method must have an integer
            value from 1 to 2 to specify which method to implement partial
            reliability is requested. Value 1 means: pr_value specifies a time
            in milliseconds after which it is unnecessary to send this data
            block. Value 2 means: pr_value specifies a re- quested maximum
            number of attempts to retransmit the data block. If the selected
            NEAT transport does not support partial reliability these
            parameters will be ignored. (See P: WRITE for more
            information).</t>

            <t>unordered_flag : The data block may be delivered out-of-order
            if this boolean flag is set. Default: false. If the protocol
            chosen by the NEAT Selection components does not support unordered
            delivery, this parameter will be ignored.</t>

            <t>data : the data-block to be sent.</t>

            <t>datalen : the amount (positive integer) of data supplied in the
            data-block.</t>

            <t>Returns: success or failure. If success, it also returns a
            handle for a NEAT Flow and the amount of supplied data that was
            buffered.</t>
          </list></t>

        <t>The OPEN_WITH_EARLY_DATA primitive allows data to be sent at the
        time when a flow is opened. To accommodate TLS 1.3 <xref
        target="I-D.ietf-tls-tls13"></xref> early data and the TCP Fast Open
        option <xref target="RFC7413"></xref>, application data need to be
        supplied at the time of opening a NEAT Flow. This primitive opens a
        flow and sends early data if the protocol supports it. If the protocol
        chosen does not support early application data. The data will be
        buffered then sent after connection establishment, similar to calling
        P: WRITE. For this reason, in addition to the parameters of P: OPEN,
        this primitive also needs the same parameters as P: WRITE. The
        supplied data can be delivered multiple times (replayed by the
        network); an application must take this into account when using this
        function. This is commonly known as idempotence.</t>
      </section>

      <section title="NEAT Flow Availability">
        <t>This section describes how an application prepares a flow to accept
        communication from another NEAT endpoint.</t>

        <t><list style="hanging">
            <t hangText="P:">ACCEPT( [name] port [stream_count] )</t>

            <t>name : local NEAT-conformant name (which can be a DNS name or a
            set of IP addresses) to constrain acceptance of incoming requests
            to local address(es). If this is missing, requests may arrive at
            any local address.</t>

            <t>port : local port number (integer) or service name (string), to
            constrain acceptance to incoming requests at this port.</t>

            <t>stream_count : the number of requested streams to open
            (integer). Default value: 1.</t>

            <t>Returns: one or more destination IP addresses, information
            about which destination IP address is used by default, inbound
            stream count (= the outbound stream count that was requested on
            the other side), and outbound stream count (= maximum number of
            allowed outbound streams).</t>
          </list></t>

        <t>The ACCEPT primitive prepares a NEAT Flow to receive network data.
        UDP and UDP-Lite do not natively support a POSIX-style accept
        mechanism; in this case, NEAT emulates this functionality. P: ACCEPT
        can only return once data arrives, not necessarily after the peer has
        called P: OPEN (The callback-based implementation does not have this
        problem because P: ACCEPT does not block).</t>

        <t><list style="hanging">
            <t hangText="E:">on_connected</t>
          </list>The on_connected event indicates a NEAT peer endpoint has
        connected, and other primitives can then be used.</t>
      </section>

      <section title="Writing and reading data">
        <t>The primitives in this section refer to actions that may be
        performed an open NEAT Flow, i.e., a NEAT Flow that was either
        actively established or successfully made available for receiving
        data. It permits an application to send and receive data-blocks over
        the API.</t>

        <t><list style="hanging">
            <t hangText="E:">on_writable</t>
          </list>The on_writable event indicates there is buffer space
        available and the application may write new data using P:WRITE. <list
            style="hanging">
            <t hangText="P:">P: WRITE( [stream] [pr_method pr_value]
            [unordered_flag] data datalen )</t>

            <t>stream : the number of the stream to be used (positive
            integer). This can be omitted if the NEAT Flow contains only one
            stream.</t>

            <t>pr_method and pr_value : if these parameters are used, then
            partial reliability is enabled and pr_method must have an integer
            value from 1 to 2 to specify which method to implement partial
            reliability is requested. Value 1 means: pr_value specifies a time
            in milliseconds after which it is unnecessary to send this
            data-block. Value 2 means: pr_value specifies a requested maximum
            number of attempts to retransmit the data-block. If the selected
            NEAT transport does not support partial reliability these
            parameters will be ignored</t>

            <t>unordered_flag : The data block may be delivered out-of-order
            if this boolean flag is set. Default: false. If the protocol
            chosen by the NEAT Selection components does not support unordered
            delivery, this parameter will be ignored.</t>

            <t>data : The data block to be sent.</t>

            <t>datalen : the amount (positive integer) of data supplied in
            data.</t>
          </list></t>

        <t>The WRITE primitive provide a NEAT Flow with a data block for
        transmission to the remote NEAT peer endpoint (with reliability
        limited by the conditions specified via pr_method, pr_value and the
        transport protocol used). NEAT Flows can support message delineation
        as a property of the NEAT Flow that is set via the INIT_FLOW primitive
        (&sect; 2.2.1). If a NEAT Flow supports message delineation, the data
        block is a complete message.</t>

        <t><list style="hanging">
            <t hangText="E:">on_all_written</t>
          </list>The on_all_written event indicates that all data requested to
        be written using P:WRITE has been sent.</t>

        <t><list style="hanging">
            <t hangText="E:">on_send_failure</t>
          </list>The on_send_failure event may be returned instead of
        E:on_all_written when the NEAT System was temporarily unable to
        complete a P:WRITE call, and it not known that all data has been
        written.</t>

        <t><list style="hanging">
            <t hangText="E:">on_readable</t>
          </list>The on_readable event indicates there is data available for
        the application that may be read using P:READ.</t>

        <t><list style="hanging">
            <t hangText="P:">READ( )</t>

            <t>data : the received data block.</t>

            <t>datalen : the amount of data received.</t>

            <t>Returns: [unordered_flag] [stream_id] data datalen. If a
            message arrives out of order, this is indicated by the
            unordered_flag. If the underlying transport protocol supports
            streams, the stream_id parameter is set.</t>
          </list></t>

        <t>The READ primitive reads a data block from a NEAT Flow into a
        provided buffer. If a NEAT Flow supports message delineation, the data
        block is a complete message.</t>
      </section>

      <section title="Flow Maintenance Primitives">
        <t>The primitives and events below are out-of-band calls that can be
        issued at any time after a NEAT Flow has been opened and before it has
        been terminated.</t>

        <t><list style="hanging">
            <t hangText="P:">CHANGE_TIMEOUT( toval )</t>

            <t hangText="">toval : the timeout value in seconds.</t>
          </list></t>

        <t>The CHANGE_TIMEOUT primitive adjusts the time after which a NEAT
        Flow will terminate if the written data could not be delivered. If
        this is not called, NEAT will make an automatic default choice for the
        timeout.</t>

        <t><list style="hanging">
            <t hangText="P:">SET_PRIMARY( dst_IP_address )</t>

            <t hangText="">dst_IP_address : the destination IP address that
            should be used as the primary address.</t>
          </list></t>

        <t>The SET_PRIMARY primitive is to be used with NEAT Flows that have
        multiple destination IP addresses, with protocols that do not use load
        sharing. It should not have an effect otherwise. This will overrule
        this general per-flow setting. If this is not called, the NEAT System
        will make an automatic default choice for the destination IP
        address.</t>

        <t><list style="hanging">
            <t hangText="P:">SET_LOW_WATERMARK( watermark)</t>

            <t hangText="">watermark : upper limit of unsent data in the
            socket buffer, in bytes.</t>
          </list></t>

        <t>The SET_LOW_WATERMARK primitive allows the application to limit the
        amount of unsent data in the underlying socket buffer. If set, NEAT
        will only execute E: WRITABLE when the amount of unsent data falls
        below the watermark. This allows applications to reduce sender-side
        queuing delay.</t>

        <t><list style="hanging">
            <t hangText="P:">SET_MIN_CHECKSUM_COVERAGE( length )</t>

            <t hangText="">length : The number of bytes that must be covered
            by the checksum for a datagram to be delivered to the
            application.</t>
          </list></t>

        <t>The SET_MIN_CHECKSUM_COVERAGE primitive allows an application to
        set the minimum acceptable checksum coverage length. This primitive
        only has effect for a received UDP-Lite datagram. A receiver that
        receives a UDP-Lite datagram with a smaller coverage length will not
        hand over the data to the receiving application. This is ignored for
        other protocols, where all data are fully covered by the checksum.</t>

        <t><list style="hanging">
            <t hangText="P:">SET_CHECKSUM_COVERAGE( length )</t>

            <t hangText="">length : sets the number of bytes covered by the
            checksum on outgoing UDP-Lite datagrams. This is ignored for other
            protocols, where all data are fully covered by the checksum.</t>
          </list></t>

        <t>The SET_CHECKSUM_COVERAGE primitive allows an application to set
        the number of bytes covered by the checksum in a UDP-Lite datagram.
        This only has effect when the UDP-Lite protocol is selected.</t>

        <t><list style="hanging">
            <t hangText="P:">SET_TTL( ttl )</t>

            <t hangText="">ttl : the hop limit to be used for reception.</t>
          </list></t>

        <t>The SET_TTL primitive sets the minimum IPv4 TTL or IPv6 Hop Count
        on a datagram that is required for it to be passed to the
        application.</t>

        <t><list style="hanging">
            <t hangText="E:">on_network_status_changed</t>
          </list>The on_network_status_changed event informs the application
        that something has happened in the network; it is safe to ignore
        without harm by many applications. A status code indicates what has
        happened in accordance with a table that includes at least the
        following three values: 1) ICMP error message arrived; 2) Excessive
        retransmissions; 3) one or more destination IP addresses have become
        available/unavailable.</t>

        <t><list style="hanging">
            <t hangText="P:">GET_PROPERTY( property )</t>

            <t>property : string with a property name, expressed as JSON.</t>

            <t>Returns: value set to the property returned by the Policy
            Manager, expressed as JSON.</t>
          </list></t>

        <t>The GET_PROPERTY primitive allows an application to discover the
        value assigned to a property by the Policy Manager. Properties are
        expressed as part of policies and handled by the NEAT Policy Manager
        and can only be read by an application once a flow has been
        initialised.</t>

        <t>These currently are:</t>

        <t><list style="symbols">
            <t>Transport parameters: Parameters used (e.g., congestion control
            mechanism, TCP sysctl parameters, . . . ). This property gives the
            application a more concrete view of the choices that were
            made.</t>

            <t>Interface statistics: Interface MTU, addresses, connection type
            (link layer), etc.</t>

            <t>Path statistics: Experienced RTT, packet loss (rate), jitter,
            throughput, path MTU, etc</t>

            <t>UsedDSCP: The DSCP assigned to an active NEAT Flow. This may
            differ from the requested DSCP when the QoS has been mapped by the
            policy system</t>
          </list></t>
      </section>

      <section title="NEAT Flow Termination">
        <t>This set of primitives and events are related to gracefully or
        forcefully closing a NEAT Flow, or being informed about this
        happening.</t>

        <t><list style="hanging">
            <t hangText="P:">CLOSE( )</t>
          </list>The CLOSE primitive terminates a NEAT Flow after satisfying
        all the requirements that were specified regarding the delivery of
        data that the application has already given to NEAT. If the peer still
        has data to send, it cannot then be received after this call. Data
        buffered by the NEAT System that has not yet been given to the network
        layer will be discarded.</t>

        <t><list style="hanging">
            <t hangText="E:">on_close</t>
          </list>The on_close event informs the application that a NEAT Flow
        was successfully closed. This can be received at any time for an
        active NEAT Flow.</t>

        <t><list style="hanging">
            <t hangText="P:">ABORT( )</t>
          </list>The ABORT primitive terminates a connection without
        delivering remaining data.</t>

        <t><list style="hanging">
            <t hangText="E:">on_aborted</t>
          </list>The on_aborted event informs the application that the other
        side has aborted the NEAT Flow. The event can be received at any time
        for an active NEAT Flow.</t>

        <t><list style="hanging">
            <t hangText="E:">on_timeout</t>
          </list></t>

        <t>The on_timeout event informs the application that the NEAT Flow is
        aborted because the default timeout has been reached before data could
        be delivered. This timeout adjusted by the P: CHANGE_TIMEOUT NEAT Flow
        maintenance primitive. The event can be received at any time for an
        active NEAT Flow.</t>
      </section>

      <section title="NEAT Error Events">
        <t>Errors that occur within the NEAT System or that are notified by
        the network result in an on_error event:</t>

        <t><list style="hanging">
            <t hangText="E:">on_error</t>
          </list>This event notifies a hard or soft error to the upper layer
        using the NEAT System.</t>
      </section>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

    <section anchor="Security" title="Security Considerations">
      <t>This document is about the design and usage of a transport API. The
      transport protocols accessed via this API each have security
      considerations.</t>

      <t>The API may be used to request the use of security protocols accessed
      via the transport API.</t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This work was partially funded by the European Union's Horizon 2020
      research and innovation programme under grant agreement No. 644334
      (NEAT). The views expressed are solely those of the author(s).</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>XX RFC ED - PLEASE REMOVE THIS SECTION XXX</t>

      <t>This memo includes no request to IANA.</t>
    </section>
  </middle>

  <back>
    <!--
    <references title="Normative References">
      &RFC2119;
    </references>
-->

    <references title="Informative References">
      &RFC7413;

      &RFC8095;

      &I-D.ietf-tls-tls13;

      &I-D.grinnemo-taps-he;

      <reference anchor="NEAT" target="https://www.neat-project.org/">
        <front>
          <title>The EU New, Evolutive API and Transport-Layer Architecture
          for the Internet (NEAT) Project</title>

          <author></author>

          <date year="2017" />
        </front>
      </reference>

      <reference anchor="NEAT-GIT"
                 target="https://github.com/neat-project/neat">
        <front>
          <title>NEAT Source Code Repository</title>

          <author></author>

          <date />
        </front>
      </reference>

      <reference anchor="D1.1"
                 target="https://www.neat-project.org/wp-content/uploads/2016/02/D1.1.pdf">
        <front>
          <title>The NEAT Architecture (D1.1)</title>

          <author fullname="Fairhurst G." initials="G." surname="Fairhurst"></author>

          <author fullname="Jones T." initials="T." surname="Jones"></author>

          <author fullname="Damjanovic D." initials="D." surname="Damjanovic"></author>

          <author fullname="Eckert K." initials="K." surname="Eckert"></author>

          <author fullname="Grinnemo K." initials="K." surname="Grinnemo"></author>

          <author fullname="Hansen A." initials="A." surname="Hansen"></author>

          <author fullname="Mangiante S." initials="S." surname="Mangiante"></author>

          <author fullname="McManus P." initials="P." surname="McManus"></author>

          <author fullname="Papastergiou G." initials="G."
                  surname="Papastergiou"></author>

          <author fullname="Ros D." initials="D." surname="Ros"></author>

          <author fullname="Vyncke E." initials="E." surname="Vyncke"></author>

          <author fullname="Welzl M." initials="M." surname="Welzl"></author>

          <author fullname="Tuexen M." initials="M." surname="Tuexen"></author>

          <date year="2015" />
        </front>
      </reference>

      <reference anchor="D2.3"
                 target="https://www.neat-project.org/wp-content/uploads/2017/10/D2.3.pdf">
        <front>
          <title>The Final Version of Core Transport System (D2.3)</title>

          <author fullname="Khademi N." initials="N." surname="Khademi"></author>

          <author fullname="Bozakov Z." initials="Z." surname="Bozakov"></author>

          <author fullname="Brunstroem A." initials="A." surname="Brunstroem"></author>

          <author fullname="Dale O." initials="O." surname="Dale"></author>

          <author fullname="Damjanovic D." initials="D." surname="Damjanovic"></author>

          <author fullname="Evenson KR." initials="KR." surname="Evensen"></author>

          <author fullname="Fairhurst G." initials="G." surname="Fairhurst"></author>

          <author fullname="Fischer A." initials="A." surname="Fischer"></author>

          <author fullname="Grinnemo K." initials="K." surname="Grinnemo"></author>

          <author fullname="Jones T." initials="T." surname="Jones"></author>

          <author fullname="Mangiante S." initials="S." surname="Mangiante"></author>

          <author fullname="Petlund A." initials="A." surname="Petlund"></author>

          <author fullname="Ros D." initials="D." surname="Ros"></author>

          <author fullname="Ruengeler I." initials="I." surname="Ruengeler"></author>

          <author fullname="Stenberg D." initials="D." surname="Stenberg"></author>

          <author fullname="Tuexen M." initials="M." surname="Tuexen"></author>

          <author fullname="Weinrank F." initials="F." surname="Weinrank"></author>

          <author fullname="Welzl M." initials="M." surname="Welzl"></author>

          <date year="2017" />
        </front>
      </reference>

      <reference anchor="NEAT-DOC" target="http://neat.readthedocs.io/">
        <front>
          <title>NEAT Programming API Documentation</title>

          <author fullname="Stenberg D." initials="D." surname="Stenberg"></author>

          <author fullname="Weinrank F." initials="F." surname="Weinrank"></author>

          <author fullname="Khademi N." initials="N." surname="Khademi"></author>

          <author fullname="Dreibholz T." initials="T." surname="Dreibholz"></author>

          <author fullname="Jones T." initials="T." surname="Jones"></author>

          <author fullname="Bozakov Z." initials="Z." surname="Bozakov"></author>

          <author fullname="Dale O." initials="O." surname="Dale"></author>

          <date />
        </front>
      </reference>
    </references>

    <section title="Revision Information">
      <t>-00 This is an individual draft for the IETF community, for
      consideration by the IETF TAPS WG.</t>

      <t>-01 Contains corrections to INIT_FLOW; fixes to typos; and includes
      the Acknolwkedgment text omitted by mistake in -00.</t>
    </section>
  </back>
</rfc>
