doc: Add RFC documents

1 files changed, 731 insertions, 0 deletions

diff --git a/doc/rfc/rfc4824.txt b/doc/rfc/rfc4824.txt
new file mode 100644
index 0000000..09b17ab
--- /dev/null
+++ b/doc/rfc/rfc4824.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Network Working Group                                 J. Hofmueller, Ed.
+Request for Comments: 4824                              A. Bachmann, Ed.
+Category: Informational                                IO. zmoelnig, Ed.
+                                                            1 April 2007
+
+
+                   The Transmission of IP Datagrams
+            over the Semaphore Flag Signaling System (SFSS)
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document specifies a method for encapsulating and transmitting
+   IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).
+
+Table of Contents
+
+1. Introduction ....................................................2
+2. Definitions .....................................................2
+3. Protocol Discussion .............................................3
+   3.1. IP-SFS Frame Description ...................................3
+   3.2. SFS Coding .................................................4
+   3.3. IP-SFS Data Signals ........................................5
+   3.4. IP-SFS Control Signals .....................................6
+   3.5. Protocol Limitations .......................................7
+   3.6. Implementation Limitations .................................7
+4. Interface Discussion ............................................7
+   4.1. Data Link Control ..........................................8
+   4.2. Establishing a Connection ..................................8
+   4.3. State Idle .................................................8
+   4.4. Session Initiation .........................................8
+   4.5. State Transmitting .........................................9
+   4.6. State Receiving ...........................................10
+   4.7. Terminating a Connection ..................................11
+   4.8. Further Remarks ...........................................11
+5. Security Considerations ........................................11
+6. Acknowledgements ...............................................11
+7. References .....................................................12
+
+
+
+
+Hofmueller, et al.           Informational                      [Page 1]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+1.  Introduction
+
+   This document specifies IP-SFS, a method for the encapsulation and
+   transmission of IPv4/IPv6 packets over the Semaphore Flag Signaling
+   System (SFSS).  The SFSS is an internationally recognized alphabetic
+   communication system based upon the waving of a pair of hand-held
+   flags [JCroft, Wikipedia].  Under the SFSS, each alphabetic character
+   or control signal is indicated by a particular flag pattern, called a
+   Semaphore Flag Signal (SFS).
+
+   IP-SFS provides reliable transmission of IP datagrams over a half-
+   duplex channel between two interfaces.  At the physical layer, SFSS
+   uses optical transmission, normally through the atmosphere using
+   solar illumination and line-of-sight photonics.  A control protocol
+   (Section 4) allows each interface to contend for transmission on the
+   common channel.
+
+   This specification defines only unicast transmission.  Broadcast is
+   theoretically possible, but there are some physical restrictions on
+   channel direction dispersion.  This is a topic for future study.
+
+   The diagram in Figure 1 illustrates the place of the SFSS in the
+   Internet protocol hierarchy.
+
+             +-----+     +-----+       +-----+
+             | TCP |     | UDP |  ...  |     |  Host Layer
+             +-----+     +-----+       +-----+
+                |           |             |
+             +-------------------------------+
+             |    Internet Protocol & ICMP   |  Internet Layer
+             +-------------------------------+
+                            |
+             +-------------------------------+
+             |             SFSS              |  Link Layer
+             +-------------------------------+
+
+                     Figure 1: Protocol Relationships
+
+2.  Definitions
+
+   Link:    A link consists of two (2) interfaces that share a common
+            subnet.
+
+   Link Partner:
+            The opposite interface.
+
+   Session: The transmission of an entire IP datagram.
+
+
+
+
+Hofmueller, et al.           Informational                      [Page 2]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+   SFS:     One Semaphore Flag Signal, i.e., one flag pattern (Section
+            3.2).
+
+   SFSS:    The Semaphore Flag Signaling System.
+
+   IP-SFS:  IP over Semaphore Flag Signaling System.
+
+3.  Protocol Discussion
+
+   IP-SFS adapts the standard SFSS to encode an alphabet of 16 signals
+   (flag patterns) to represent data values 0-15 (Section 3.2.1) and 9
+   signals to represent control functions (Section 3.2.2).  With 16 data
+   signals, IP-SFS transmission is based upon 4-bit nibbles, two per
+   octet.  Each of the signal patterns defined in Section 3.2 is called
+   an SFS.
+
+3.1.  IP-SFS Frame Description
+
+   IP datagrams are formatted into IP-SFS frames by adding IP-SFS
+   headers and trailers.  Figure 2 shows the format of one IP-SFS frame.
+   The frame is delimited by a control SFS called FST (Frame Start) and
+   a control SFS called FEN (Frame End).  It is composed of a series of
+   4-bit nibbles, one per SFS.
+
+   An IP datagram will be fragmented into multiple successive IP-SFS
+   frames if necessary.  When an IP datagram is fragmented into N
+   frames, the first frame will be sent with frame number N-1, the
+   second with frame number N-2, ..., and the last with frame number 0.
+
+
+              0        1        2        3
+          +--------+--------+--------+--------+--------+
+          |   FST  |Protocol|CksumTyp|Frame No|Frame No|
+          +--------+--------+--------+--------+--------+
+                   |                                   |
+                   //       DATA  Payload              //
+                   |                                   |
+                   +--------+--------+--------+--------+---------+
+                   |  CRC   |  CRC   |  CRC   |  CRC   |   FEN   |
+                   +--------+--------+--------+--------+---------+
+
+            Note that each field represents one SFS or 4 bits.
+
+                       Figure 2: IP-SFS Frame Format
+
+   FST:       Frame Start control SFS
+
+
+
+
+
+Hofmueller, et al.           Informational                      [Page 3]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+   Protocol:  4 bits -- Internetwork-layer protocol code
+
+       0      None.
+
+       1      For IPv4.
+
+       2      For IPv6.
+
+       3      For IPv4 frame gzip-compressed.
+
+       4      For IPv6 frame gzip-compressed.
+
+       5...15 Reserved for future use.
+
+   CksumTyp:  4 bits (one data SFS) -- Checksum Type
+
+       0      none.
+
+       1      CCITT CRC 16 (polynomial: x^16 + x^12 + x^5+1).
+
+       2...15 Reserved for future use.
+
+   Frame No:  8 bits (2 data SFSs):
+              Frame number for fragmented IP datagram.
+
+   DATA:      0 to 510 data SFSs (Section 3.2.1) representing 0 to 255
+              octets of payload.
+
+   CRC:       16 bits as four data SFSs.
+              CRC checksum.  Preset to 0xFFFF.  One's complement of
+              checksum is transmitted.
+
+   FEN:       Frame ENd control SFS.
+
+   The number of transmitted SFSs per minute (Spm) depends on the
+   experience of participating interfaces.  Resulting link speed in bits
+   per second for IP-SFS is (Spm/60)*4, not counting framing overhead.
+
+3.2.  SFS Coding
+
+   Data signals and control signals are based upon standard SFS
+   encoding, as described by [JCroft], [Wikipedia], and other sources on
+   the Internet.  The 16 data signals are interpreted as 4-bit nibbles,
+   while the 9 control signals are used for data link control.
+
+   IP-SFS defines the 16 data signals by the original SFSS encodings for
+   letters A to P and the 9 control signals represented by SFSS
+   encodings Q to X.
+
+
+
+Hofmueller, et al.           Informational                      [Page 4]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+3.3.  IP-SFS Data Signals
+
+   Figure 3 illustrates the 16 SFSs used to transmit data frames over
+   the link.  The illustrations show each SFS as seen from the receiving
+   side.
+
+                   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
+
+                      Figure 3: IP-SFS Data Signals.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hofmueller, et al.           Informational                      [Page 5]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+3.4.  IP-SFS Control Signals
+
+   Nine control signals are used to signal special IP-SFS conditions.
+   Their meanings are listed in Figure 4.  The illustrations show each
+   SFS as seen from the receiving side.
+
+                   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    RTT    unused
+
+                   -----------------------------------------
+
+                   SFS      _\0/_
+                             /|\
+                             / \
+                            Error
+                   IP-SFS   unused
+
+                     Figure 4: IP-SFS Control Signals.
+
+   FST: Frame STart.  Signals the start of a new frame.
+
+   FEN: Frame ENd.  Signals the end of one frame.
+
+   SUN: Signal UNdo.  Cancels the transmission of one or more individual
+        SFSs within the current frame.  This signal will be
+        unacknowledged by the receiver.
+
+
+
+
+
+
+Hofmueller, et al.           Informational                      [Page 6]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+   FUN: Frame UNdo.  As long as Frame ENd is not sent, the transmitter
+        or the receiver may send a FUN to restart the transmission of
+        the current frame.  This signal will be unacknowledged and may
+        be ignored by the receiver.
+
+   ACK: Frame ACK.  Acknowledges reception of one frame.
+
+   KAL: KeepALive.  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.  The frame received is incorrect.
+
+   RTR: Ready To Receive.  Receiver acknowledges it is ready to receive.
+
+   RTT: Ready To Transmit.  Sender requests permission to initiate
+        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), and also depend a number of physical
+   factors.  Poor visibility due to weather conditions or lack of
+   illumination (e.g., night time) can drastically increase the error
+   rate.
+
+   IP-SFS provides 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
+
+   Maximum payload per frame: 510 SFS (0...510) nibbles (0 to 255
+   octets)
+
+   Maximum 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.  A knowledge of the SFSS is recommended, but its absence can
+   be compensated by a well-designed GUI.
+
+
+
+
+
+Hofmueller, et al.           Informational                      [Page 7]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+4.1.  Data Link Control
+
+   This section describes the control protocol used to allocate the
+   half-duplex data link to either interface.
+
+   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
+   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
+   5*TIMEOUT.
+
+4.3.   State Idle
+
+   Interfaces in State Idle must be ready to send an IP datagram
+   provided by a local higher-level protocol or to receive a datagram
+   from the link-partner.  Interfaces in State Idle must send keep-alive
+   signals KAL at a frequency of at least KAL_FRQ.
+
+   There are no further definitions for State Idle, but we recommend
+   staying away from alcoholic beverages or other types of drugs that
+   could lead to an increased number of FUN and/or SUN signals, a
+   decrease in bandwidth, or an increase of line latency.
+
+   If the number of IP datagrams in the transmission queue is >0, the
+   interface may try to initiate a session by sending an RTT to the link
+   partner.  If the link partner ready to receive, it returns an RTR
+   signal.
+
+4.4.  Session Initiation
+
+   An interface receiving a datagram from an Internet layer protocol
+   level may start signaling RTT.
+
+
+
+Hofmueller, et al.           Informational                      [Page 8]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+   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, before
+   resending the RTT.
+
+   If the link partner transmits RTR, the interface transmits the number
+   of IP-SFS frames to be transmitted in this session as two SFSs
+   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.
+
+   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.  This would be
+   counterproductive.
+
+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 by transmitting a wrong data SFS, the interface
+   may invalidate the last data SFS by transmitting SUN followed by the
+   correct signal.  A series of incorrectly transmitted data SFSs may be
+   invalidated by sending a SUN for each invalid SFS, effectively back-
+   spacing the sequence.
+
+   Control SFSs cannot be invalidated.
+
+   If an error occurs, the interface may also transmit FUN and restart
+   transmission of the active IP-SFS frame.
+
+   Whether the interfaces choose SUN or FUN for error correction is up
+   to the interface, but it is suggested to use SUN for a single invalid
+   SFS, and FUN whenever the interface failed to transmit several SFSs
+   in a row.
+
+   After FEN has been transmitted, the transmitting interface waits for
+   the link partner to transmit ACK or NAK.
+
+
+
+
+Hofmueller, et al.           Informational                      [Page 9]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+   If ACK has been received, the transmitting 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 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 5 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 received 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.
+
+   If the time between two received SFSs exceeds TIMEOUT, the receiving
+   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 SUN from the link partner, it must discard
+   the last received data SFS (if any).  If N SUNs are received in a
+   row, then the last N data SFS must be discarded, unless there are no
+   more data SFS in the frame.  If there are no more data SFS in the
+   frame to be discarded, the SUN signal must be ignored by the
+   interface.
+
+   If the receiving interface receives FUN from the link partner, it is
+   free to discard the frame received thus far.  We suggest honoring FUN
+   since discarding the signal will decrease bandwidth.
+
+   After FEN has been received, the receiving 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 incorrect, the interface transmits NAK.
+
+
+
+Hofmueller, et al.           Informational                     [Page 10]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+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, and monitor.  Other means of
+   connection are subject to availability and budget.
+
+   Although it is theoretically possible to combine the TX and RX parts
+   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 providing 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.
+   When an interface in TX State signals at a rate higher than the RX
+   interface is able to receive, signal loss occurs.
+
+5.  Security Considerations
+
+   By its nature of line-of-sight signaling, 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 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, Martin Schitter, and Bob Braden for all their
+   contributions and support of this project.
+
+
+
+
+
+
+
+
+Hofmueller, et al.           Informational                     [Page 11]
+
+RFC 4824                      IP over SFSS                    April 2007
+
+
+7.  References
+
+   [JCroft]     Croft, J., "Semaphore Flag Signalling System",
+                <http://www.anbg.gov.au/flags/semaphore.html>.
+
+   [Wikipedia]  Wikipedia, "Modern semaphore", <http://
+                en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.
+
+Authors' Addresses
+
+   Jogi Hofmueller (editor)
+   Brockmanngasse 65
+   Graz  8010
+   AT
+
+   EMail: ip-sfs@mur.at
+
+
+   Aaron Bachmann (editor)
+   Ulmgasse 14 C
+   Graz  8053
+   AT
+
+   EMail: ip-sfs@mur.at
+
+
+   IOhannes zmoelnig (editor)
+   Goethestrasse 9
+   Graz  8010
+   AT
+
+   EMail: ip-sfs@mur.at
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hofmueller, et al.           Informational                     [Page 12]
+
+RFC 4824                      IP over SFSS                    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@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Hofmueller, et al.           Informational                     [Page 13]
+