One document matched: draft-barnes-atoca-delivery-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced.
     An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-barnes-atoca-delivery-00.txt"
     ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
         full title is longer than 39 characters -->

    <title abbrev="ESCAPE">Scalable Robust Alerting Protocol (SCRAP)</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <author fullname="Richard Barnes" initials="R.L." surname="Barnes">
      <organization>BBN Technologies</organization>

      <address>
        <postal>
          <street>9861 Broken Land Parkway</street>

          <city>Columbia</city>

          <region>MD</region>

          <code>21046</code>

          <country>US</country>
        </postal>

        <phone>+1 410 290 6169</phone>
      </address>
    </author>

    <date month="October" year="2011" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
	 in the current day and month for you. If the year is not the current one, it is
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to
	 specify just the year. -->

    <area>RAI</area>

    <workgroup>ATOCA</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>atoca, alert, emergency, s/mime</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>Emergency alerts need to be delivered reliably from one source to
      many recipients at once. TCP is unsuitable for this style of delivery,
      because the large number of acknowledgements would likely cause network
      congestion. This document defines a UDP-based protocol for delivering
      alerts that supports fragmentation and retransmission for reliability,
      and allows the sender of a datagram to control whether acknowledgements
      are sent. </t>

      <t>Please send feedback to the atoca@ietf.org mailing list.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro-sec" title="Introduction">
      <t>[TODO]</t>

      <section title="Open Questions">
        <t>Should we include hash value in URI format? Or leave that to the
        metadata/configuration protocol? </t>

        <t>Should we randomize the order in which fragments are transmitted in
        order to deal with correlated loss?</t>
      </section>
    </section>

    <section anchor="def-sec" title="Definitions">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119">RFC 2119</xref>.</t>
    </section>

    <section title="Packet Format">
      <t>[Sent over UDP. Default port is XXX.]</t>

      <t>[Payload format: Alert ID (2 octets / 16 bits); Fragment number (1
      octet / 8 bits); Number of fragments in alert (1 octet / 8 bits); Alert
      data (remaining octets)]</t>

      <t>[Content of reassembled packets MUST be an ESCAPE-formatted
      alert]</t>
    </section>

    <section title="URI Format">
      <t>[Specifies the format/source of an alert that will be sent]</t>

      <t>[alert-src:[host/IP]:[srcport]?:[dstport]]</t>
    </section>

    <section title="Sender Processing">
      <t>[Choose an alert ID]</t>

      <t>[Divide payload into fragments that will fit within an MTU]</t>

      <t>[Attach headers to fragments]</t>

      <t>[Transmit fragments in order]</t>

      <t>[Re-transmit the sequence to deal with loss:]</t>

      <t>[Probability of receipt given loss (p=P(success)), #fragments (F),
      #retransmissions (R), : q = (1 - (1-p)^R)^F]</t>

      <t>[Number of retransmissions given loss (1-p), resilience (q),
      #fragments (F): R = log(1-q^(1/F)) / log(1-p)]</t>
    </section>

    <section title="Receiver Processing">
      <t>[Maintain a set of alert buffers identified by alert ID (possibly an
      empty set)]</t>

      <t>[Alert buffer contents: alert id; fragments to be received; list of
      fragment numbers; list of fragments]</t>

      <t>[When an alert packet arrives...]</t>

      <t>[If there is a buffer for its ID, add it to the buffer; if the buffer
      is complete, re-assemble, validate ESCAPE, and deliver alert to higher
      layer]</t>

      <t>[If there is not a buffer for its ID, then allocate a new one and add
      the fragment.]</t>

      <t>[If all fragments for an alert do not arrive within T1 milliseconds,
      discard the buffer; default T1=5000]</t>
    </section>

    <section anchor="iana-sec" title="IANA Considerations">
      <t>[Default port number]</t>
    </section>

    <section anchor="sec-cons-sec" title="Security Considerations">
      <t>[This protocol provides no security protections; security provided by
      ESCAPE.]</t>

      <t>[Main concern is DOS, mitigated by buffer timeouts; at worst, have to
      buffer 2^32 octets, if all buffers full for all alert IDs. MAY impose
      limits on buffer size / number of buffers active simultaneously. ]</t>
    </section>

    <section anchor="ack-sec" title="Acknowledgements">
      <t>[TODO]</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      <reference anchor="CAP">
        <front>
          <title>Common Alerting Protocol v1.1</title>

          <author fullname="" initials="A" surname="Botterell">
            <organization></organization>
          </author>

          <author initials="E." surname="Jones">
            <organization>J</organization>

            <address>
              <postal>
                <street></street>

                <city></city>

                <region></region>

                <code></code>

                <country></country>
              </postal>

              <phone></phone>

              <facsimile></facsimile>

              <email></email>

              <uri></uri>
            </address>
          </author>

          <date month="October" year="2005" />
        </front>
      </reference>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1421.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1952.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2045.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3370.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4648.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5652.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5754.xml"?>
    </references>

    <references title="Informative References">
      <?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-atoca-requirements"?>
    </references>
  </back>
</rfc>