    Independent Submission                                         T. Ritter
    Request for Comments: 6217                                  1 April 2011
    Category: Experimental
    ISSN: 2070-1721

               Regional Broadcast Using an Atmospheric Link Layer

    Abstract

       Broadcasting is a technology that has been largely discarded in favor
       of technologies like multicast.  This document builds on RFC 919 and
       describes a more efficient routing mechanism for broadcast packets
       destined for multiple Local Area Networks (LANs) or Metropolitan Area
       Networks (MANs) using an alternative link layer.  It significantly
       reduces congestion on network equipment and does not require
       additional physical infrastructure investment.

    Status of This Memo

       This document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This is a contribution to the RFC Series, independently of any other
       RFC stream.  The RFC Editor has chosen to publish this document at
       its discretion and makes no statement about its value for
       implementation or deployment.  Documents approved for publication by
       the RFC Editor are not a candidate for any level of Internet
       Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6217.

    Copyright Notice

       Copyright (c) 2011 IETF Trust and the persons identified as the
       document authors.  All rights reserved.

       This document is subject to BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents
       (http://trustee.ietf.org/license-info) 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.

    Ritter                        Experimental                      [Page 1]

    RFC 6217                   Regional Broadcast               1 April 2011

    Table of Contents

       1. Introduction ....................................................2
       2. Terminology .....................................................2
       3. Limitations .....................................................2
       4. Physical Layer ..................................................3
       5. Frame Format in the OSI Model ...................................3
          5.1. Data Link Layer ............................................3
          5.2. Network Layer ..............................................3
          5.3. Transport Layer ............................................4
       6. Reception .......................................................6
       7. Datagram Transmission ...........................................6
          7.1. Chemical Approach to the Atmospheric Link Layer ............6
          7.2. Location ...................................................7
          7.3. Physical Layer Conditions ..................................7
       8. References ......................................................8
          8.1. Normative References .......................................8
          8.2. Informative References .....................................8

    1.  Introduction

       RFC 919 [1] defines a method for broadcasting packets to a local
       network.  It assumes that data link layers support efficient
       broadcasting.  In the years since RFC 919 was written, Local Area
       Networks have grown exponentially in size, and frequently they are
       not geographically local.

       This RFC proposes a new data link layer that scales efficiently to a
       geographically local network and, depending on visibility, to an
       entire Metropolitan Area Network.  By using a different transmission
       medium, the broadcast traffic does not impact current inter- or
       intra-network routed traffic.  It also makes use of a widely
       available infrastructure that is in use in all major cities and,
       surprisingly, rural and under-developed locations as well.

    2.  Terminology

       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 RFC 2119.

    3.  Limitations

       This RFC does not propose solutions to all problems.  Just as RFC 919
       was unconcerned with reliability, we also do not guarantee that hosts
       receive datagrams sent.  Hosts may not receive packets for a variety
       of reasons, among them weather conditions, line of sight, sleep
       patterns, and distraction.  A best-effort delivery approach is taken.

    Ritter                        Experimental                      [Page 2]

    RFC 6217                   Regional Broadcast               1 April 2011

       These limitations do impact the usefulness of the proposal, but
       organizations serious about distributing information in this fashion
       can overcome these obstacles with relatively little difficulty.

    4.  Physical Layer

       The physical layer used is made up primarily of nitrogen and oxygen,
       at a pressure of 101.3 kilopascal at sea level, but dropping to about
       half that pressure at operating altitudes.  Microscopic residue or
       trace elements may exist in the transmission medium, depending on
       local formation properties.

       This residue may include argon, carbon dioxide, neon, helium,
       chloride anions, sulfur dioxide, and other molecules occurring at
       very low mixtures.  It is common for there to be some degree of
       gaseous dihydrogen monoxide present.  These trace molecules usually
       do not impede the broadcast, although further details on datagram
       transmission follow.

    5.  Frame Format in the OSI Model

       It is always a challenge to design a protocol that allows enough
       flexibility for future adaptation while keeping it efficient in size
       -- and for this medium, size and complexity of the header are of
       particular concern.  For this reason, this RFC proposes
       recommendations for the Data Link, Network, and Transport Layers.

       Implementations MAY use any protocol that fits their needs for the
       Network and Transport Layers.  They SHOULD consider how different
       protocols may be interpreted by recipients of the message and choose
       the most effective protocol available.  The protocols defined have
       been designed to allow maximum ease of interpretation, so their use
       is encouraged.

    5.1.  Data Link Layer

       The Data Link Layer is primarily concerned with transmitting
       datagrams between adjacent nodes, and it is unnecessary here since we
       only support broadcast transmission.  Implementers MUST NOT
       encapsulate packets in a link layer protocol.

    5.2.  Network Layer

       When designing a protocol for the Network Layer, it makes sense to
       consider existing protocols in this layer and reference their
       strengths and weaknesses.  Looking at IPv4/6, we can see their header
       structures include several fields unnecessary for our purposes:

    Ritter                        Experimental                      [Page 3]

    RFC 6217                   Regional Broadcast               1 April 2011

       Destination, TTL (Time to Live), DSCP (Diffserv Code Point), ECN
       (Explicit Congestion Notification), Hop Limits, and so on.  We can
       design a much more compact protocol thusly:

          +-------------------------------+-----------------------------+
          |            Content            |           Source            |
          +-------------------------------+-----------------------------+

                         Figure 1: Layout of the Datagram

       Content - A variable-length field containing the encapsulation of
       higher-level protocols.

       Source - The sender of the message.  A transmission MUST choose one
       of the following representations of the source:
          - IPv4 address in dot-decimal notation (e.g., 192.168.1.1)
          - IPv6 address in standard notation (RFC 5952 [2])
          - telephone number in E.123 notation
          - electronic mail address in E.123 notation
          - Uniform Resource Identifier (RFC 3986 [3])
          - geographic address

       The Source field MUST be present -- to send a message anonymously, a
       sender MUST use one of the reserved entries of the different types.
       Reserved Entries for telephone numbers vary by region; for example,
       in North America they are 555-0100 to 555-0199.  Reserved entries for
       IPv4 (RFC 5735 [4]), IPv6 (RFC 5156 [5]), and URIs (RFC 2606 [6]) may
       be found in their respective RFCs.  The concept of a region defined
       by homogeneous communication characteristics has been put forward
       already in [7], so geographic addressing ambiguities may be resolved
       by community standards.

       Because the message is sent to a specific geographical region, more
       leniency is available in source addressing, but requirements may be
       imposed by higher-level protocols.

       We call this protocol the Asynchronous Dumb Visual Exchange of Raw
       Transmissions or ADVERT.

    5.3.  Transport Layer

       Similar to the Network Layer, a Transport Layer protocol is able to
       omit several constructs that are used in existing Transport Layer
       protocols.  Consider TCP -- sequence, acknowledgement, and many of
       the flags are discarded as there will be no SYN, SYN/ACK, or ACK
       handshake in a broadcast message.  Likewise, fields such as Window
       Size and Urgent -- created primarily as a benefit to router
       manufacturers -- are unnecessary in this medium.

    Ritter                        Experimental                      [Page 4]

    RFC 6217                   Regional Broadcast               1 April 2011

       In fact, in the event of a plain text message, content SHOULD be
       embedded directly in the ADVERT Protocol without the need of a
       transport protocol.  Consider the following packet:

                  Content                          Source
       +------------------------------------------------------------+
       | Lobster Dinner - only $14.99    500 Boardwalk, Pt Pleasant |
       +------------------------------------------------------------+

                     Figure 2: Example ADVERT Datagram

       For UTF-encoded payloads, one SHOULD use the default UTF-encoding so
       the packet is human-readable.  This will minimize accidental
       misinterpretation.  This transmission structure lends itself most
       easily to human-parsable messages.

       For messages intended to be responded to by a computer (for example,
       binary content), a Transport Layer protocol MUST be used, and an
       implementer SHOULD use UDP, as it is one of the more compact
       protocols available in this layer.  An implementer SHOULD encode the
       UDP ports, length, and checksum in base-10 (leading zeros omitted)
       and the data in Base64 encoding.  The Base64 encoding, combined with
       the UDP checksum, resolves ambiguities with trailing whitespace or
       non-printable characters.

       The usage of UDP or other protocols that compute a checksum over
       source and destination addresses necessitates the use of either an
       IPv4 or IPv6 address as the Source in the ADVERT Protocol.  The
       Destination address 255.255.255.255 MUST be used in the calculation
       of an IPv4-based checksum, as it has already been specified as a
       local hardware broadcast that must not be forwarded (RFC 919).  For
       IPv6, the All Nodes link-local multicast destination
       FF02:0:0:0:0:0:0:1 MUST be used, defined in RFC 4291 [8].

         ADVERT Datagram           UDP Embedded            Sample Data
       +-----------------+     +--------+--------+     +--------+--------+
       |                 |     |Src Port|Dst Port|     |      0 |     80 |
       |                 |     +--------+--------+     +--------+--------+
       |                 |     | Length |Checksum|     |     24 |  62670 |
       |   UDP Packet    |     +--------+--------+     +--------+--------+
       |                 |     |                 |     | R0VUIC8gSFRUUC8 |
       |                 |     |      Data       |     | xLjENCg0K       |
       |                 |     |                 |     |                 |
       +-----------------+     +-----------------+     +-----------------+
       |  Source Address |     |  Source Address |     |     203.0.113.8 |
       +-----------------+     +-----------------+     +-----------------+

       Figure 3: Example of Encapsulating Binary Data in an ADVERT Datagram

    Ritter                        Experimental                      [Page 5]

    RFC 6217                   Regional Broadcast               1 April 2011

    6.  Reception

       Upon receipt, the datagram should be optically scanned into an
       electronically transmittable form, similar to the methods used in RFC
       1149 [9].  If present, any checksums SHOULD be computed and compared
       with supplied values.  If the checksum does not match, the packet
       MUST be discarded.

       Physical layers always have advantages and disadvantages depending on
       their condition, maintenance, prevalence, and economic factors; the
       atmosphere is no different.  The protocols defined herein do not
       specify a TTL specifically because it is often out of their control,
       and dependent on the conditions present.  The intrinsic TTL produces
       a curve of error rates where, after time, meaning cannot be
       deciphered from the datagram either because of a non-matching
       checksum or, in the absence of a checksum (such as the ADVERT
       protocol), because of an unintelligible transmission.  If the Source
       field is sufficiently distinguishable, the recipient MAY contact the
       sender for message clarification.  RFC 919 is in agreement in stating
       that broadcasts MUST NOT be assumed to have been reliably delivered.

       Reconsidering Figure 3, a broadcast HTTP Request is sent, and
       recipients should return the request from each of their computer
       systems that are listening on the requisite port.  It is important to
       remember the security implications of the systems' acceptance of data
       from unknown senders.  It is the responsibility of each organization
       to utilize host-protection mechanisms and egress filtering to avoid
       exposing their systems to undue risk or exposing internal or NAT-ed
       devices.

       Although it may be easy for an operator to silently discard the
       packet, it would be inappropriate for a network operator to
       unilaterally discard data, in the absence of policy.  RFC 1087 [10]
       classifies an action that destroys the integrity of computer-based
       information as unethical and unacceptable; and the Code of Ethics of
       SAGE, USENIX, and LOPSA recognize the important of maintaining
       integrity, reliability, and availability.

    7.  Datagram Transmission

    7.1.  Chemical Approach to the Atmospheric Link Layer

       Information is sent by transmitters producing a specialized form of
       smoke, most often by emitting a specialized oil onto the exhaust
       manifold.  The oil, held in a pressurized container, is vaporized in
       a thick white smoke, producing readable display.  The makeup of the
       smoke is often subject to patents, and any organization interested
       should consult with their attorneys.  Further details on transmission

    Ritter                        Experimental                      [Page 6]

    RFC 6217                   Regional Broadcast               1 April 2011

       on the Physical Layer is beyond the scope of this RFC, but
       implementers MAY refer to references for help.  It is by design that
       the broadcast mechanism does not result in incompatibilities if
       implementers choose different Physical Layer implementations.

    7.2.  Location

       The datagram MUST be displayed in the atmosphere, at an altitude of
       7000 to 17000 feet (2133 to 5181 meters).  It SHOULD be written using
       a "skytyping" method, similar to dot-matrix printing (Figure 4).
       This method will provide better persistence of the datagram in the
       presence of air currents.  Additionally, it provides the ability for
       parallelism by using additional avionic instruments.

                    #######   #######   #######   #######
                       #      #            #      #
                       #      #            #      #
                       #      ####         #      ####
                       #      #            #      #
                       #      #            #      #
                    #######   #######      #      #

                   Figure 4: Skytyping Method in the Sky

       The most efficient method for broadcasting a datagram on this link
       layer is the hire of specialized companies that perform this service
       on a regular basis.  For a large organization interested in using
       this method frequently, it may be more cost-effective to develop
       one's own methods.

    7.3.  Physical Layer Conditions

       Transmission ability varies by atmospheric and regional conditions.
       Adverse conditions, such as an accumulation of moisture or ice
       crystals in the Physical Layer, may preclude transmission for a
       period of time.  During these periods, it is suggested broadcasts be
       delayed, as higher-than-expected error rates may occur, and receivers
       may not be prepared to process the transmission immediately.

       Additionally, solar radiation conditions affect transmission in a
       predictable, cyclic manner.  Depending on latitude, the medium may be
       unusable for a lengthy period, during which alternate arrangements
       must be made.

       Conditions may worsen before, during, or after a transmission,
       resulting in higher-than-expected transmission error rates.  Regional
       operators should be familiar with their operating conditions and

    Ritter                        Experimental                      [Page 7]

    RFC 6217                   Regional Broadcast               1 April 2011

       consider the feasibility of implementing a casual or robust
       infrastructure on this transmission medium.  Some locales lend
       themselves better to regular operation than others.

    8.  References

    8.1.  Normative References

       [1]  Mogul, J., "Broadcasting Internet Datagrams", STD 5, RFC 919,
            October 1984.

    8.2.  Informative References

       [2]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
            Address Text Representation", RFC 5952, August 2010.

       [3]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
            Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
            January 2005.

       [4]  Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153,
            RFC 5735, January 2010.

       [5]  Blanchet, M., "Special-Use IPv6 Addresses", RFC 5156, April
            2008.

       [6]  Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names",
            BCP 32, RFC 2606, June 1999.

       [7]  Hooke, A., "Interplanetary Internet", GSAW 2003,
            <http://sunset.usc.edu/gsaw/gsaw2003/s3/hooke.pdf>.

       [8]  Hinden, R. and S. Deering, "IP Version 6 Addressing
            Architecture", RFC 4291, February 2006.

       [9]  Waitzman, D., "Standard for the transmission of IP datagrams on
            avian carriers", RFC 1149, April 1 1990.

       [10] Defense Advanced Research Projects Agency and Internet
            Activities Board, "Ethics and the Internet", RFC 1087, January
            1989.

    Ritter                        Experimental                      [Page 8]

    RFC 6217                   Regional Broadcast               1 April 2011

    Author's Address

       Thomas Ritter
       PO Box 541
       Hoboken, NJ 07030
       USA

       EMail: tom@ritter.vg
       URI:   http://ritter.vg

    Ritter                        Experimental                      [Page 9]