Regional Broadcast Using an Atmospheric Link Layer
RFC 6217
|
| Document |
Type |
|
RFC - Experimental
(March 2011; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
ISE
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
ISE state
|
|
(None)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 6217 (Experimental)
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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]
Show full document text