IP over ATM (joke): An Experimental Encapsulation of IP Datagrams on Top of ATM
An April 1st joke about sending IP datagrams as Morse-code beeps.
Eriksson, J., "An Experimental Encapsulation of IP Datagrams on Top of ATM", RFC 1926, DOI 10.17487/RFC1926, April 1996, <https://www.rfc-editor.org/info/rfc1926>.
@misc{rfc1926,
series = {Request for Comments},
number = 1926,
howpublished = {RFC 1926},
publisher = {RFC Editor},
doi = {10.17487/RFC1926},
url = {https://www.rfc-editor.org/info/rfc1926},
author = {J. Eriksson},
title = {{An Experimental Encapsulation of IP Datagrams on Top of ATM}},
pagetotal = 2,
year = 1996,
month = apr,
} RFC text
Contents
Network Working Group J. Eriksson
Request for Comments: 1926 KTH NOC
Category: Informational 1 April 1996
An Experimental Encapsulation of IP Datagrams on Top of ATM
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This RFC describes a method of encapsulating IP datagrams on top of
Acoustical Transmission Media (ATM). This is a non-recommended
standard. Distribution of this memo is unnecessary.
Overview
The modern laptop computer of today often contains the hardware
needed to perform wireless communications by using Acoustical
Transmission Media, i.e. sound waves. Until this moment there has
been no standard on how to run IP on such media. This document is an
attempt to fill this silence.
Frame transmission
The IP datagram is divided into four-bit chunks, in network beep
order, and converted to characters according to the table below. A
single "b" character is prepended as a frame start signal, the
characters are then transmitted in ordinary morse code by modulating
a steady tone on and off. The frequency of this tone is also known
as the Acoustical Signature (AS number) of the sender.
Bits Character Bits Character
0000 "i" 1000 "u"
0001 "t" 1001 "m"
0010 "s" 1010 "v"
0011 "a" 1011 "f"
0100 "n" 1100 "w"
0101 "h" 1101 "l"
0110 "d" 1110 "k"
0111 "r" 1111 "g"
To allow more than one Local Acoustical Network (LAN) to coexist the
use of different AS numbers for different LANs is suggested. This
document proposes seven standard AS numbers to be used, see the table
below for details.
Name Frequency
"a" 440 Hz
"b" 494 Hz
"c" 523 Hz
"d" 587 Hz
"e" 659 Hz
"f" 698 Hz
"g" 784 Hz
It is assumed that for normal operation AS number "a", 440 Hz will be
used.
Frame reception
The above process is simply performed backwards.
Security Considerations
The author assumes that the users take whatever precautions that are
necessary before attempting to use this protocol in any crowded area.
Author's Address
Johnny Eriksson
KTH NOC
EMail: bygg@sunet.se
or
-... -.-- --. --. @ ... ..- .- . - .-.-.- ... .
ISO Plain Language
On this page
§1A Joke About Sound-Based Networking
This April 1st joke RFC proposes encapsulating IP datagrams over what it calls Acoustical Transmission Media (ATM). It says laptops could use sound waves, then presents the idea in a formal technical style.
The memo says it is informational and does not specify an Internet standard. It calls the proposal a non-recommended standard in its abstract.
The RFC is an April 1st joke about sending network data as sound. Its ATM means Acoustical Transmission Media in this proposal.
§2Turning Data into Beeps
The sender divides an IP datagram into four-bit chunks and maps each chunk to a letter using the table in the RFC. It adds a single “b” character as a frame-start signal.
The letters are transmitted in ordinary Morse code by switching a steady tone on and off. The tone frequency acts as the sender's Acoustical Signature.
The sender changes each small piece of data into a letter, then sends the letters as Morse code. The tone's pitch identifies the chosen acoustical network.
§3Frequencies and Reception
The RFC lists seven proposed Acoustical Signature frequencies, named “a” through “g”, from 440 Hz to 784 Hz. It assumes “a”, at 440 Hz, for normal operation and suggests different frequencies for separate Local Acoustical Networks.
Reception reverses the encoding process. The security section advises users to take precautions before trying the protocol in a crowded area.
The proposal assigns different pitches to different local networks. A receiver reverses the steps to recover the data.