[IP-SFS] Changes to IP over Semaphore Signals for April 1
Jogi Hofmüller
jogi at mur.at
Mon Mar 26 17:54:35 CEST 2007
Dear Bob!
It took a little longer than originally expected, but we worked as
quickly as possible. So here ist the next version including all
changes you required. I also attach an xml version that can be used with
the xml2rpc tool.
We hope that the document fullfills the necessary requirements for
publication now.
regards,
j.hofmueller
<txt>
Network Working Group J. Hofmueller, Ed.
Internet-Draft A. Bachmann, Ed.
Intended status: Experimental I. Zmoelnig, Ed.
Expires: October 3, 2007 April 2007
A standard for the transmission of IP datagrams over Semaphore Flag
Signalling System
ip-sfs-rfc
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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 as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document specifies a method for encapsulating and transmitting
IPv4/IPv6 packets over Semaphore Flag Signals (SFS).
1. Introduction
The Semaphore Flag Signaling System (SFSS) is an alphabet signalling
Hofmueller, et al. Expires October 3, 2007 [Page 1]
Internet-Draft IP over Semaphore Flag Signals April 2007
system based on the waving of a pair of hand-held flags in a
particular pattern [JimCroft].
IP datagrams are formated into IP-SFS frames by adding an IP-SFS
header and trailer. The resulting IP-SFS frame is transmitted using
the SFS described in Figure 3. IP datagrams will be fragmented into
multiple IP-SFS frames if necessary.
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 in bits per
second is (fpm/60)*4.
2. Definitions
Link:
A link consists of two (2) interfaces that share a common
subnet.
Link-partner:
The oposite interface.
Session:
The transmission of an entire IP datagram.
SFS:
One Semaphore Flag Signal or flag.
SFSS:
The Semaphore Flag Signaling System.
IP-SFS:
Ip over Semaphore Flag Signaling System.
3. Protocol Discussion
IP-SFS supports packet fragmentation and re-assembly. When an IP
datagram is fragmented into N frames the 1st frame will be sent with
frame number N-1, the 2nd with frame number N-2, ... the last with
frame number 0.
The diagram in Figure 1 illustrates the place of the IP-SFS in the
protocol hierarchy.
Hofmueller, et al. Expires October 3, 2007 [Page 2]
Internet-Draft IP over Semaphore Flag Signals April 2007
+-----+ +-----+ +-----+
| TCP | | UDP | ... | | Host Layer
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Internet Layer
+-------------------------------+
|
+-------------------------------+
| SFS | Link Layer
+-------------------------------+
Protocol relationships.
Figure 1
3.1. IP-SFS Frame Description
Data coming from a higher level protocol is encapsulated in IP-SFS
frames. Figure 2 illustrates one IP-SFS frame.
0 1 2 3
+--------+--------+--------+--------+
|Protocol|Checksum|Frame Hi|Frame Lo|
+--------+--------+--------+--------+
| |
+ DATA +
| |
+--------+--------+--------+--------+
| CRC | CRC | CRC | CRC |
+--------+--------+--------+--------+
Example IP-SFS Frame. Note that each field represents one SFS.
Figure 2
Protocol: 4 bits
0 none.
1 for IPv4.
2 for IPv6.
3 for whole IPv4 frame gzip compressed.
Hofmueller, et al. Expires October 3, 2007 [Page 3]
Internet-Draft IP over Semaphore Flag Signals April 2007
4 for whole IPv6 frame gzip compressed.
5...15 reserved for future use.
Checksum: 4 bits
0 none.
1 CCITT CRC 16 (polynom: x^16+x^12+x^5+1).
2...15 reserved for future use.
Frame Hi: 4 bits
Frame Number divided by 16.
Frame Lo: 4 bits
Frame Number % 16; % donates modulo division.
DATA:
0 to 510 data signals as described in Figure 3
CRC: 16 bits
CRC checksum. Preset to 0xFFFF. Ones complement of checksum is
transmitted.
3.2. Signal Coding
The IP-SFS frames are transmitted over an SFS link by translating
each 4-bit nibble into one SFS according to Figure 3. IP-SFS knows
16 data signals represented by SFS A to P and 9 control signals
represented by SFS Q to X.
Data Signals and Control Signals are standard SFS as described by
[JimCroft], [Wikipedia] and other sources on the internet. Instead
of using their alphabetical value, Data Signals are interpreted as
4-bit nibbles and Control Signals are used for interface
communication.
3.3. IP-SFS Data Signals
Figure 3 illustrates the 16 SFS used to transmit data frames over the
link. The illustrations show each SFS as seen from the receiving
side.
Hofmueller, et al. Expires October 3, 2007 [Page 4]
Internet-Draft IP over Semaphore Flag Signals April 2007
SFS 0 __0 \0 |0
/|| || || ||
/ \ / \ / \ / \
A B C D
IP-SFS 0x00 0x01 0x02 0x03
SFS 0/ 0__ 0 __0
|| || ||\ /|
/ \ / \ / \ / \
E F G H
IP-SFS 0x04 0x05 0x06 0x07
SFS \0 |0__ 0| 0/
/| | /| /|
/ \ / \ / \ / \
I J K L
IP-SFS 0x08 0x09 0x0A 0x0B
SFS 0__ 0 _\0 __0|
/| /|\ | |
/ \ / \ / \ / \
M N O P
IP-SFS 0x0C 0x0D 0x0E 0x0F
IP-SFS data signals.
Figure 3
3.4. IP-SFS Control Signals
Nine control signals are used to signal special IP-SFS conditions.
Their meaning is listed in Figure 4. The illustrations show each SFS
as seen from the receiving side.
Hofmueller, et al. Expires October 3, 2007 [Page 5]
Internet-Draft IP over Semaphore Flag Signals April 2007
SFS __0/ __0__ __0 \0|
| | |\ |
/ \ / \ / \ / \
Q R S T
IP-SFS FST FEN SUN FUN
SFS \0/ \0__ 0/_ 0/
| | | |\
/ \ / \ / \ / \
U V W X
IP-SFS ACK KAL NAK RTR
SFS 0__ 0__
/| |\
/ \ / \
Y Z
IP-SFS unused unused
SFS _\0/_
/|\
/ \
Error
IP-SFS RTT
IP-SFS Control Signals.
Figure 4
FST: Frame STart. Signal to indicate the start of a new frame.
FEN: Frame ENd. Signal to tell the end of one frame.
SUN: Signal UNdo. Signal to be used to cancel the transmission of
one or more individual SFS within the active frame. This signal
will be unacknowledged.
FUN: Frame UNdo. As long as Frame ENd is not sent the transmitter or
the receiver MAY request restarting the transmission of the
active frame. This signal will be unacknowledged and reacting
upon it is optional.
ACK: Frame ACK. Signal to acknowledge reception of one frame.
Hofmueller, et al. Expires October 3, 2007 [Page 6]
Internet-Draft IP over Semaphore Flag Signals April 2007
KAL: KeepALive. Signal to keep a connection alive. Is to be
transmitted in State Idle at a frequency of at least KAL_FREQ
(see Section 4.2. This signal will be unacknowledged.
NAK: Frame No AcK. Signal to tell that the frame received is not
good.
RTR: Ready To Receive. Ack given to RTT when ready.
RTT: Ready To Transmit. Signal to request initiation of
transmission.
3.5. 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 frame reordering or dual (multiple)
frame reception. Thus the protocol is not suitable in environments
where interfaces are moving fast and/or when the path of light is
long.
3.6. Implementation Limitations
maximal payload per frame: 510 SFS (0...510)
maximal SFS per frame: 518
maximum frames per session: 255 (0...254)
4. 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.
4.1. States
Interfaces know three States: Idle, Transmitting (TX), and Receiving
(RX).
4.2. 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
Hofmueller, et al. Expires October 3, 2007 [Page 7]
Internet-Draft IP over Semaphore Flag Signals April 2007
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.
Possible values for TIMEOUT are the time it takes to smoke a
cigarette or the time it takes to drink a glass of water. If
negotiation fails, TIMEOUT defaults to 60 seconds.
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.
4.3. 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 FUN and/or SUN and result in a
decrease in bandwidth and increase of line latency.
If the number of IP datagrams 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.
4.4. Session Initiation
An interface receiving data from a higher protocol level MAY start
signaling RTT.
If the link partner does not respond with RTR within 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 frames to be transmitted in this session as two SFS
followed by another RTT. If the link partner does not transmit the
same number of IP-SFS frames followed by RTR within 3*TIMEOUT the
interface switches to State Idle.
If the link partner transmits the same number of IP-SFS frames
followed by RTR the interface switches to State Transmitting.
Hofmueller, et al. Expires October 3, 2007 [Page 8]
Internet-Draft IP over Semaphore Flag Signals April 2007
Unless obstructed through environmental noise or great distance,
hollering can be used to request line discipline from the link
partner in State Idle. 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.
4.5. State Transmitting
Transmission of one IP-SFS frame starts with FST. After FST and
before FEN have been transmitted the interface MAY acknowledge a
received FUN and restart the transmission of the active frame or
discard the signal and continue transmission of the active IP-SFS
frame.
If an error occurs the interface MAY transmit FUN and restart
transmission of the active IP-SFS frame.
After FEN has been transmitted the interface waits for the link
partner to transmit ACK or NAK.
If ACK has been received the interface removes the active frame and
starts transmitting the next IP-SFS frame. If no frames are left the
interface switches to State Idle. If no more frames are left to
transmit the IP datagram is removed from the transmission queue and
the interface switches to State Idle.
If NAK has been received the transmission failed and the interface
MUST start transmitting the active frame again.
If the link partner does not transmit ACK or NAK within TIMEOUT the
transmission failed and the interface MUST start retransmitting the
active IP-SFS frame.
If transmission of the same IP-SFS frame fails for five times the
interface leaves the IP datagram in the transmission queue and
switches to State Idle.
4.6. 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 FST and before FEN have been received the interface MAY
transmit FUN at any time to request a retransmission of the entire
IP-SFS frame.
Hofmueller, et al. Expires October 3, 2007 [Page 9]
Internet-Draft IP over Semaphore Flag Signals April 2007
If the time between two received SFS exceeds TIMEOUT the interface
MUST discard all data from the active IP-SFS frame and MAY
additionally transmit FUN. 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 FUN from the link partner it is free to
discard the so far received frame. We suggest honoring FUN since
discarding the signal will decrease bandwidth.
After FEN has been received the interface evaluates the checksum. If
the checksum is good the interface transmits ACK. If the Frame
Number of the active frame 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.
4.7. 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.
4.8. Further Remarks
Interfaces are connected to computer hardware by means of a 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. Typically 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.
5. 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.
Hofmueller, et al. Expires October 3, 2007 [Page 10]
Internet-Draft IP over Semaphore Flag Signals April 2007
Interfaces tend to keep data in their memory. There is no way to
determine the lifetime of data 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
from interfaces' memory without permanent interface destruction.
6. Acknowledgements
We 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 for all their contributions and
support to this project.
7. References
[JimCroft]
Croft, J., "Semaphore Flag Signalling System", accessed
2007-03-26, <http://www.anbg.gov.au/flags/semaphore.html>.
[Wikipedia]
Wikipedia, n/a., "Modern semaphore", accessed 2007-03-26,
<http://en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.
Authors' Addresses
Jogi Hofmueller (editor)
Brockmanngasse 65
Graz 8010
AT
Email: ip-sfs at mur.at
Aaron Bachmann (editor)
Ulmgasse 14 C
Graz 8053
AT
Email: ip-sfs at mur.at
Hofmueller, et al. Expires October 3, 2007 [Page 11]
Internet-Draft IP over Semaphore Flag Signals April 2007
IOhannes zmoelnig (editor)
Goethestrasse 9
Graz 8010
AT
Email: ip-sfs at mur.at
Hofmueller, et al. Expires October 3, 2007 [Page 12]
Internet-Draft IP over Semaphore Flag Signals April 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr at ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Hofmueller, et al. Expires October 3, 2007 [Page 13]
</txt>
--
Wolfram Scheucher träumt jede zweite Nacht von Harald Brettermeier - schlecht, versteht sich. <<< http://plagi.at/geruecht/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ip-sfs-rfc.xml
Type: application/xml
Size: 25325 bytes
Desc: not available
Url : http://lists.mur.at/pipermail/ip-sfs/attachments/20070326/0c1baa1c/attachment.xml
-------------- 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/20070326/0c1baa1c/attachment-0002.pgp
More information about the IP-SFS
mailing list