[IP-SFS] IP over Semphore Flag Signaling System submission
Jogi Hofmüller
jogi at mur.at
Tue Mar 20 09:18:12 CET 2007
Dear Editor!
Two years after submitting this document for the first time we are very
confident to have solved all the issues in question. We hope our text
fullfills all your requirements so it can be published this April 1st as
RFC.
If you should find any inconsistency please let us know so we can fix it
on time.
I would like to add that we have a reference implementation at
sourceforge
http://sourceforge.net/projects/ip-sfs
which was successfully tested by transmitting a series of UDP datagrams
across the river Mur on June 17th 2006.
<RFC>
Network Working Group A.Bachmann/J.Hofmueller/I.Zmoelnig
Request for Comments: DRAFT mur.at/was
Category: Experimental 1 April 2007
A Standard for the transmission of IP datagrams over Semaphore Flag
Signalling System
"By submitting this Internet-Draft, I certify that any applicable patent
or other IPR claims of which I am aware have been disclosed, or will be
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668."
Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than a "work in progress.
Abstract
This document specifies a method for encapsulating and transmitting
IPv4/IPv6 packets over Semaphore Flag Signals (SFS). The Semaphore
Flag Signaling System (SFSS) is an alphabet signalling system based
on the waving of a pair of hand-held flags in a particular pattern
(Jim Croft). IP-SFS is capable of transmitting four (4) bits per
flag (bpf). The number of transmitted flags per minute (fpm) depends
on the experience of participating humans. Resulting link speed is
(fpm/60)*4.
IP-SFS is designed as point-to-point protocol on the local network
layer.
Bachmann/Hofmueller/Zmoelnig Experimental [Page 1]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
Definitions
Link
A link consists of two (2) interfaces that share a common subnet.
Link-partner
The oposite interface is called link-partner.
Session
The transmission of an entire ip-frame is called session.
SFS
One flag is called Semphore Flag Signal (SFS).
Protocol discussion
IP-SFS is a block oriented protocol.
IP-SFS supports packet fragmentation and re-assembly. When an ip
frame is fragmented into N blocks the 1st block will be sent with
block number N-1, the 2nd with block number N-2, ... the last with
block number 0.
The diagram in figure 1 illustrates the place of the IP-SFS in the
protocol hierarchy:
+-----+ +-----+ +-----+
| TCP | | RTP | ... | | Host Level
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Gateway Level
+-------------------------------+
|
+-------------------------------+
| IP-SFS | Network Level
+-------------------------------+
Protocol relationships as found in RFC 793.
Figure 1.
Bachmann/Hofmueller/Zmoelnig Experimental [Page 2]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
IP-SFS block description
Data coming from a higher level protocol is encapsulated in IP-SFS
blocks. Figure 2 illustrates one IP-SFS block.
0 1 2 3 4
+--------+--------+--------+--------+--------+
| BST |Protocol|Checksum|Block Hi|Block Lo|
+--------+--------+--------+--------+--------+
| DATA |
+--------+--------+--------+--------+--------+
| CRC | CRC | CRC | CRC | BEN |
+--------+--------+--------+--------+--------+
Example IP-SFS Block
Figure 2.
Note that each field represents one SFS.
BST: 4 bits
SFS BlockSTart
Protocol: 4 bits
0 none
1 for ipv4
2 for ipv6
3 for whole ipv4 frame gzip compressed
4 for whole ipv6 frame gzip compressed
5...0xf reserved for future use
Checksum: 4 bits
0 none
1 CCITT CRC 16 (polynom: x^16+x^12+x^5+1).
2...0xf reserved for future use.
Block Hi: 4 bits
Bachmann/Hofmueller/Zmoelnig Experimental [Page 3]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
Block Number divided by 16.
Block Lo: 4 bits
Block Number % 16; % donates modulo division.
DATA
0 to 255 octets of data.
CRC: 16 bits
CRC checksum. Preset to 0xFFFF. Ones complement of checksum is
transmitted.
BEN: 4 bits
SFS BlockENd
Signal coding
The blocks are transmitted over an IP-SFS link by translating each
nibble into one SFS according to figures 3 and 4. IP-SFS knows 16
data signals represented by the SFSs A to P and 9 control signals
represented by the SFSs Q to Y. Thus one SFS is used to transmit 4
bits of payload data.
Figures 3 and 4 illustrate the signals used. For a detailed
description of the underlying transport mechanism please consult
naval guides or related web pages.
The illustrations in figure 3 and 4 show each flag signal as seen
from the receiving side.
Bachmann/Hofmueller/Zmoelnig Experimental [Page 4]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
IP-SFS data signals
Figure 3 illustrates the 16 IP-SFS signals used to transmit data
blocks over the link.
SFS 0 __0 \0 |0
signal /|| || || ||
/ \ / \ / \ / \
A B C D
IP-SFS 0x00 0x01 0x02 0x03
SFS 0/ 0__ 0 __0
signal || || ||\ /|
/ \ / \ / \ / \
E F G H
IP-SFS 0x04 0x05 0x06 0x07
SFS \0 |0__ 0| 0/
signal /| | /| /|
/ \ / \ / \ / \
I J K L
IP-SFS 0x08 0x09 0x0A 0x0B
SFS 0__ 0 _\0 __0|
signal /| /|\ | |
/ \ / \ / \ / \
M N O P
IP-SFS 0x0C 0x0D 0x0E 0x0F
IP-SFS data signals
Figure 3.
Bachmann/Hofmueller/Zmoelnig Experimental [Page 5]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
IP-SFS control signals
Nine control signals are used to signal special IP-SFS conditions.
Their meaning is listed in figure 4.
SFS __0/ __0__ __0 \0|
signal | | |\ |
/ \ / \ / \ / \
Q R S T
IP-SFS BST BEN FUD BUD
SFS \0/ \0__ 0/_ 0/
signal | | | |\
/ \ / \ / \ / \
U V W X
IP-SFS BAK unused NAK RTR
SFS 0__ 0__
signal /| |\
/ \ / \
Y Z
IP-SFS unused KAL
SFS _\0/_
signal /|\
/ \
Error
IP-SFS RTT
IP-SFS control signals
Figure 4.
BST: Block STart. Signal to indicate the start of a new block.
BEN: Block ENd. Signal to tell the end of one block.
FUD: Flag UnDo. The transmitting interface may cancel individual
SFS (one a time) using the SFS FUD within the active block. This
signal will be unacknowledged.
BUD: Block UnDo. As long as Block End is not sent the transmitter
or the receiver may request restarting the transmission of the
active block. This signal will be unacknowledged and reacting upon
Bachmann/Hofmueller/Zmoelnig Experimental [Page 6]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
it is optional.
BAK: Block AcK. Signal to acknowledge reception of one block.
NAK: No AcK. Signal to tell that the block received is not good.
RTT: Ready To Transmit. Signal to request initiation of
transmission.
RTR: Ready To Receive. Ack given to RTT when ready.
KAL: KeepALive. Signal to keep a connection alive. Is to be
transmitted in State Idle at a frequency of at least KAL-FREQ.
This signal will be unacknowledged.
IP-frame encapsulation
IP-frames are queued for transmission to the link-partner in the
transmission queue in the order of their arrival.
Protocol limitations
Due to the physical characteristics of the transfer channel bit
error rates are expected to be in the range of 1e-3 (boy scout) to
1e-4 (professional sailor).
There are no means to handle block reordering or dual (multiple)
block reception. Thus the protocol is not suitable in environments
where interfaces are moving fast and/or when the path of light is
long.
Implementation limits
MTU for ip-frame: 4096 octets
MTU for block reception: 600 flag signals
maximal payload octets per block (mpo): 255 (0...255)
maximal flag-signals per block (mfb) 510 (2*255) ; must be an even
number
maximum blocks per session (mbs): 255 (0...254)
Bachmann/Hofmueller/Zmoelnig Experimental [Page 7]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
Interface Discussion
An interface is constructed through the participation of one or more
humans. The knowledge of the SFSS is a recommendation, its absence
can be compensated by a well designed GUI.
States
Interfaces know three States: Idle, Transmitting (TX), and
Receiving (RX).
Establishing a connection
IP-SFS is strictly point-to-point. Unless interface-members are
acquainted with each other a brief introduction of both sides is
suggested prior to setting up a link to reduce the likelihood of
interface-spoofing attacks.
Interfaces MUST agree on two different IP addresses on the same
subnet.
Interfaces are free to negotiate any period of time as TIMEOUT.
Examples can be the time it takes to smoke a cigarette, the time
it takes to drink a bottle of beer or other beverage divided by
the number of interface members. If negotiation takes to long we
suggest 60 seconds as TIMEOUT.
The same procedure MAY be applied for the KeepALive FReQuency
(KAL_FRQ). The period of KAL_FRQ (1/KAL_FRQ) SHOULD be at least
five times TIMEOUT.
State Idle
Interfaces in State Idle MUST be ready to receive data from a
higher level protocol and/or the link-partner. KAL is to be
transmitted at a frequency of at least KAL_FRQ.
There are no further definitions for State Idle but we recommend
to stay away from alcoholic beverages or other types of drugs
since this could lead to an increased number of undoes/resets and
thus a huge decrease in bandwidth and increase of line latency.
If the number of ip-frames in the transmission queue is >0 the
interface MAY try to initiate a session.
If the link partner transmits RTT and the interface accepts the
session initiation it transmits RTR to acknowledge this.
Bachmann/Hofmueller/Zmoelnig Experimental [Page 8]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
Session initiation
An interface receiving data from a higher protocol level will
start signaling RTT.
If the link partner does not respond with RTR within the TIMEOUT
or the link partner responds with RTT the interface switches to
State Idle for a random period of time between 2 seconds and
TIMEOUT.
If the link partner transmits RTR the interface transmits the
number of IP-SFS blocks to be transmitted in this session as one
octet followed by another RTT. If the link partner does not
transmit the same number of IP-SFS blocks followed by RTR within
3*TIMEOUT the interface switches to State Idle.
If the link partner transmits the same number of IP-SFS blocks
followed by RTR the interface switches to State Transmitting.
Unless obstructed through environmental noise or great distance,
hollering can be used to request line discipline from the link
partner in idle State. The use of cellphones is also an option
whereas throwing objects or using guns is not recommended since it
could result in interface damage or destruction which would be
counterproductive since IP-SFS tries to improve communication
among humans.
State Transmitting
Transmission of one IP-SFS block starts with BST. After BST and
before BEN have been transmitted the interface MAY acknowledge a
received BUD and restart the transmission of the active block or
discard the signal and continue transmission of the active IP-SFS
block.
If an error occurs the interface MAY transmit BUD and restart
transmission of the active IP-SFS block.
After BEN has been transmitted the interface waits for the link
partner to transmit BAK or NAK.
If BAK has been received the interface removes the active block
and starts transmitting the next IP-SFS block. If no blocks are
left the interface switches to State Idle. If no more blocks are
left to transmit the ip-frame is removed from the transmission
queue and the interface switches to State Idle.
If NAK has been received the transmission failed and the interface
Bachmann/Hofmueller/Zmoelnig Experimental [Page 9]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
MUST start transmitting the active block again.
If the link partner does not transmit BAK or NAK within the
TIMEOUT period the transmission failed and the interface MUST
start retransmitting the active IP-SFS block.
If transmission of the same IP-SFS block fails for five times the
interface leaves the ip-frame in the transmission queue and
switches to State Idle.
State Receiving
In State Receiving the interface stores each SFS receveived from
the link partner in the receiving queue in the order of
appearance.
After BST and before BEN have been received the interface MAY
transmit BUD at any time to request a retransmission of the entire
IP-SFS block.
If the time between two received SFS exceeds TIMEOUT the interface
MUST discard all data from the active IP-SFS block and MAY
additionally transmit BUD. If the link partner does not continue
transmitting within a second TIMEOUT period, the interface MUST
clear the receiving queue and switch to State Idle.
If the interface receives BUD from the link partner it is free to
discard the so far received block. We suggest honoring BUD since
discarding the signal will decrease bandwidth.
After BEN has been received the interface evaluates the checksum.
If checksum is good the interface transmits BAK. If the Block
Number of the active block is 0 the interface passes the entire
data from the receiving queue to the higher level protocol, clears
the receiving queue and switches to State Idle.
If the checksum is not good the interface transmits NAK.
Terminating a connection
If the interface is in State Idle and the link partner did not
transmit any kind of SFS for at least five times 1/KAL_FRQ the
connection is terminated and the interfaces are free to disband.
Further remarks
Interfaces are connected to computer hardware by means of a
Bachmann/Hofmueller/Zmoelnig Experimental [Page 10]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
suitable input device (RX) and a suitable output device (TX).
Possible devices include keyboard, mouse, monitor. Other means of
connection are subject to availability and budget.
Although it is theoretically possible to combine TX and RX part of
an interface in one human being we suggest dividing the operations
among at least two people per interface. For longer transmissions
(multimedia streaming, video conferencing etc.) consider rotating
and provide substitutes.
Bandwidth tends to vary. Traditionally TX starts at about 2-4
Bits/s and will decrease over time due to exhaustion and lack of
concentration. An interface in TX State signalling at a rate
higher than the RX interface is able to receive will lead to
signal loss.
Security Considerations
By its nature of line-of-sight signalling, IP-SFS is considered
insecure. The transmission of sensitive data over IP-SFS is strongly
discouraged unless security is provided by higher level protocols.
Interfaces tend to keep data blocks in their memory. There is no way
to determine the lifetime of data blocks in memory. As a side effect,
data might show up in unwanted locations at undesired times.
We are currently not aware of a technique to reliably delete data
blocks from interfaces' memory without permanent interface
destruction.
Bachmann/Hofmueller/Zmoelnig Experimental [Page 11]
RFC DRAFT IP over Semaphore Flag Signals 1 April 2007
Acknowledgments
We'd like to thank Eva Ursprung and Doris Jauk-Hinz from Womyn's Art
Support (WAS), Anita Hofer, Reni Hofmueller, Ulla Klopf, Nicole
Pruckermayr, Manfred Rittler and Martin Schitter.
Author's Address:
Jogi Hofmueller Aaron Bachmann IOhannes zmoelnig
Leitnergasse 7 Feuerbachgasse 26 Goethestrasse 9
8010 Graz/Austria 8020 Graz/Austria 8010 Graz/Austria
Email: ip-sfs at mur.at Email: ip-sfs at mur.at Email: ip-sfs at mur.at
The Authors can be reached via the ip-sfs at mur.at mailing list which
is open for subscription to anyone. Posts from not-subscribed
addresses are subject to inspection and will be accepted if
acceptable.
Full Copyright Statement
"Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Bachmann/Hofmueller/Zmoelnig Experimental [Page 12]
</RFC>
Sincerely,
j.hofmueller
--
Anina Halb denkt, sie sei die beste Freund von Karl Grünling. 'Das würde voraussetzen, dass sie denken kann'. seufzt die davon zunehmend ennuyierte. <<< http://plagi.at/geruecht/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.mur.at/pipermail/ip-sfs/attachments/20070320/058db999/attachment-0002.pgp
More information about the IP-SFS
mailing list