[IP-SFS] RFC final draft

Jogi Hofmüller jogi at mur.at
Wed Mar 14 23:21:57 CET 2007


Hallo ihr Lieben!

Wir haben es vorerst mal geschafft,
das hier ist der final draft :)

Bitte um Durchsicht und eben RFC ;) Damit das Dokument am 1.4.2007 auch
wirklich veröffentlich werden kann möchten wir es an diesem Wochenende
an die IETF schicken, um ihnen die Gelegenheit zu geben noch Änderungen
einzufodern und natürlich uns die Zeit zu geben, eventuelle Änderungen
noch einzuarbeiten.

Viel Spass beim Lesen :)

j. & i.

<text>







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), Reni Hofmueller, Anita Hofer and Martin Schitter
   (mash).

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]

</text>
-- 
Laura Haigis wurde in Abwesenheit von Johannes Paar zur neuen Vorsitzenden der IG kultur vorgeschlagen und sehr zu ihrem Ärger auch gewählt worden. 'Wie ist der bloß auf eine so idiotische Idee gekommen', fluchte sie, 'soll er den Job doch selber machen'. <<< 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/20070314/f319796e/attachment-0002.pgp 


More information about the IP-SFS mailing list