<html><head><title>wdiff rfc4824.original rfc4824.txt</title></head><body>
<pre>
Network Working Group J. Hofmueller, Ed.
<strike><font color='red'>Internet-Draft</font></strike>
<strong><font color='green'>Request for Comments: 4824</font></strong> A. Bachmann, Ed.
<strike><font color='red'>Intended status:</font></strike>
<strong><font color='green'>Category:</font></strong> Informational I. Zmoelnig, Ed.
<strike><font color='red'>Expires: October 3, 2007</font></strike>
<strong><font color='green'>1</font></strong> April 2007
The Transmission of IP <strike><font color='red'>datagrams</font></strike> <strong><font color='green'>Datagrams</font></strong>
over <strong><font color='green'>the</font></strong> Semaphore Flag <strike><font color='red'>Signalling</font></strike> <strong><font color='green'>Signaling</font></strong> System
<strike><font color='red'>IP-SFS</font></strike> <strong><font color='green'>(SFSS)</font></strong>
Status of <strike><font color='red'>this</font></strike> <strong><font color='green'>This</font></strong> Memo
<strike><font color='red'>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</font></strike>
<strong><font color='green'>This memo provides information for</font></strong> the Internet <strike><font color='red'>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.</font></strike> <strong><font color='green'>community.</font></strong> It <strike><font color='red'>is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list</font></strike> <strong><font color='green'>does
not specify an Internet standard</font></strong> of <strike><font color='red'>current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list</font></strike> <strong><font color='green'>any kind. Distribution</font></strong> of <strike><font color='red'>Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 3, 2007.</font></strike> <strong><font color='green'>this
memo is unlimited.</font></strong>
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 <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . . . . . 3</font></strike> <strong><font color='green'>....................................................2</font></strong>
2. Definitions <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . . . . . 3</font></strike> <strong><font color='green'>.....................................................2</font></strong>
3. Protocol Discussion <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . 4</font></strike> <strong><font color='green'>.............................................3</font></strong>
3.1. IP-SFS Frame <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . . . 4</font></strike> <strong><font color='green'>Description ...................................3</font></strong>
3.2. <strike><font color='red'>SFS</font></strike> <strong><font color='green'>Signal</font></strong> Coding <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1.</font></strike> <strong><font color='green'>..............................................4
3.3.</font></strong> IP-SFS Data Signals <strike><font color='red'>. . . . . . . . . . . . . . . . . 6
3.2.2.</font></strike> <strong><font color='green'>........................................5
3.4.</font></strong> IP-SFS Control Signals <strike><font color='red'>. . . . . . . . . . . . . . . . 6
3.3.</font></strike> <strong><font color='green'>.....................................6
3.5.</font></strong> Protocol Limitations <strike><font color='red'>. . . . . . . . . . . . . . . . . . . 8
3.4.</font></strike> <strong><font color='green'>.......................................7
3.6.</font></strong> Implementation Limitations <strike><font color='red'>. . . . . . . . . . . . . . . . 8</font></strike> <strong><font color='green'>.................................7</font></strong>
4. Interface Discussion <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . 8</font></strike> <strong><font color='green'>............................................7</font></strong>
4.1. <strike><font color='red'>Channel Control . . . . . . . . . . . . . . . . . . . . . 8</font></strike> <strong><font color='green'>States .....................................................8</font></strong>
4.2. Establishing a Connection <strike><font color='red'>. . . . . . . . . . . . . . . . 8</font></strike> <strong><font color='green'>..................................8</font></strong>
4.3. State Idle <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . . . . 9</font></strike> <strong><font color='green'>.................................................8</font></strong>
4.4. Session Initiation <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . 9</font></strike> <strong><font color='green'>.........................................8</font></strong>
4.5. State Transmitting <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . 10</font></strike> <strong><font color='green'>.........................................9</font></strong>
4.6. State Receiving <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . 11</font></strike> <strong><font color='green'>...........................................10</font></strong>
4.7. Terminating a Connection <strike><font color='red'>. . . . . . . . . . . . . . . . . 11</font></strike> <strong><font color='green'>..................................11</font></strong>
4.8. Further Remarks <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . 11</font></strike> <strong><font color='green'>...........................................11</font></strong>
5. Security Considerations <strike><font color='red'>. . . . . . . . . . . . . . . . . . . 12</font></strike> <strong><font color='green'>........................................11</font></strong>
6. Acknowledgements <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . . . 12</font></strike> <strong><font color='green'>...............................................11</font></strong>
7. References <strike><font color='red'>. . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 14</font></strike> <strong><font color='green'>.....................................................12</font></strong>
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 <strike><font color='red'>[JCroft], [Wikipedia].</font></strike> <strong><font color='green'>[JCroft, Wikipedia].</font></strong> 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 <strike><font color='red'>using</font></strike> line-of-sight photonics. A control protocol <strike><font color='red'>Section 4</font></strike>
<strong><font color='green'>(Section 4)</font></strong> 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 <strike><font color='red'>IP-SFS</font></strike> <strong><font color='green'>SFSS</font></strong> in the
<strong><font color='green'>Internet</font></strong> protocol hierarchy.
+-----+ +-----+ +-----+
| TCP | | UDP | ... | | Host Layer
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Internet Layer
+-------------------------------+
|
+-------------------------------+
| SFSS | Link Layer
+-------------------------------+
<strike><font color='red'>Protocol relationships.</font></strike>
Figure <strike><font color='red'>1</font></strike> <strong><font color='green'>1: Protocol Relationships</font></strong>
2. Definitions
Link: A link consists of two (2) interfaces that share a common
subnet.
<strike><font color='red'>Link-partner:</font></strike>
<strong><font color='green'>Link Partner:</font></strong>
The <strike><font color='red'>oposite</font></strike> <strong><font color='green'>opposite</font></strong> interface.
Session: The transmission of an entire IP datagram.
SFS: One Semaphore Flag Signal, i.e., one flag pattern (Section
3.2).
SFSS: The Semaphore Flag Signaling System.
IP-SFS: <strike><font color='red'>Ip</font></strike> <strong><font color='green'>IP</font></strong> over Semaphore Flag Signaling System.
3. Protocol Discussion
IP-SFS adapts the standard SFSS to encode an alphabet of 16 signals
(flag patterns) <strike><font color='red'>that</font></strike> <strong><font color='green'>to</font></strong> represent data values 0-15 <strike><font color='red'>Section 3.2.1</font></strike> <strong><font color='green'>(Section 3.2.1)</font></strong> and 9
<strike><font color='red'>control</font></strike>
signals <strike><font color='red'>Section 3.2.2.</font></strike> <strong><font color='green'>to represent control functions (Section 3.2.2).</font></strong> 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
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 //
| |
<strike><font color='red'>+--------+--------+--------+--------+--------+</font></strike>
<strong><font color='green'>+--------+--------+--------+--------+---------+</font></strong>
| CRC | CRC | CRC | CRC | FEN |
<strike><font color='red'>+--------+--------+--------+--------+--------+
IP-SFS Frame Format.</font></strike>
<strong><font color='green'>+--------+--------+--------+--------+---------+</font></strong>
Note that each field represents one <strike><font color='red'>SFS.</font></strike> <strong><font color='green'>SFS or 4 bits.</font></strong>
Figure <strike><font color='red'>2</font></strike> <strong><font color='green'>2: IP-SFS Frame Format</font></strong>
FST: Frame Start control <strike><font color='red'>SFS.</font></strike> <strong><font color='green'>SFS</font></strong>
Protocol: 4 bits -- Internetwork-layer protocol code
0 <strike><font color='red'>none.</font></strike> <strong><font color='green'>None.</font></strong>
1 <strike><font color='red'>for</font></strike> <strong><font color='green'>For</font></strong> IPv4.
2 <strike><font color='red'>for</font></strike> <strong><font color='green'>For</font></strong> IPv6.
3 <strike><font color='red'>for whole</font></strike> <strong><font color='green'>For</font></strong> IPv4 frame <strike><font color='red'>gzip compressed.</font></strike> <strong><font color='green'>gzip-compressed.</font></strong>
4 <strike><font color='red'>for whole</font></strike> <strong><font color='green'>For</font></strong> IPv6 frame <strike><font color='red'>gzip compressed.</font></strike> <strong><font color='green'>gzip-compressed.</font></strong>
5...15 <strike><font color='red'>reserved</font></strike> <strong><font color='green'>Reserved</font></strong> for future use.
CksumTyp: 4 bits (one data SFS) -- Checksum <strike><font color='red'>Typ.</font></strike> <strong><font color='green'>Type</font></strong>
0 none.
1 CCITT CRC 16 (polynomial: <strike><font color='red'>x^16+x^12+x^5+1).</font></strike> <strong><font color='green'>x^16 + x^12 + x^5+1).</font></strong>
2...15 <strike><font color='red'>reserved</font></strike> <strong><font color='green'>Reserved</font></strong> for future use.
Frame No: 8 bits (2 data SFSs):
Frame number for fragmented IP datagram.
DATA: 0 to 510 data SFSs (Section <strike><font color='red'>3.2)</font></strike> <strong><font color='green'>3.2.1)</font></strong> representing 0 to 255
octets of payload.
CRC: 16 bits as four data SFSs.
CRC checksum. Preset to 0xFFFF.
<strike><font color='red'>Ones</font></strike> <strong><font color='green'>One's</font></strong> 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 <strike><font color='red'>channel control.
The IP-SFS frames are transmitted over an SFS link by translating
each 4-bit nibble into one</font></strike> data <strike><font color='red'>SFS according to Figure 3.</font></strike> <strong><font color='green'>link control.</font></strong>
IP-SFS defines <strong><font color='green'>the</font></strong> 16 data signals <strike><font color='red'>represented</font></strike> by the original SFSS encodings for
letters A to P and <strong><font color='green'>the</font></strong> 9 control signals represented by <strike><font color='red'>SFS</font></strike> <strong><font color='green'>SFSS
encodings</font></strong> Q to X.
3.2.1. IP-SFS Data Signals
Figure 3 illustrates the 16 <strike><font color='red'>used</font></strike> SFSs <strong><font color='green'>used</font></strong> 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
<strong><font color='green'>-----------------------------------------</font></strong>
SFS 0/ 0__ 0 __0
|| || ||\ /|
/ \ / \ / \ / \
E F G H
IP-SFS 0x04 0x05 0x06 0x07
<strong><font color='green'>-----------------------------------------</font></strong>
SFS \0 |0__ 0| 0/
/| | /| /|
/ \ / \ / \ / \
I J K L
IP-SFS 0x08 0x09 0x0A 0x0B
<strong><font color='green'>-----------------------------------------</font></strong>
SFS 0__ 0 _\0 __0|
/| /|\ | |
/ \ / \ / \ / \
M N O P
IP-SFS 0x0C 0x0D 0x0E 0x0F
<strike><font color='red'>IP-SFS data signals.</font></strike>
Figure <strike><font color='red'>3</font></strike> <strong><font color='green'>3: IP-SFS Data Signals.</font></strong>
3.2.2. IP-SFS Control Signals
Nine control signals are used to signal special IP-SFS conditions.
Their <strike><font color='red'>meaning is</font></strike> <strong><font color='green'>meanings are</font></strong> 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
<strong><font color='green'>-----------------------------------------</font></strong>
SFS \0/ \0__ 0/_ 0/
| | | |\
/ \ / \ / \ / \
U V W X
IP-SFS ACK KAL NAK RTR
<strong><font color='green'>-----------------------------------------</font></strong>
SFS 0__ 0__
/| |\
/ \ / \
Y Z
IP-SFS <strong><font color='green'>RTT</font></strong> unused <strike><font color='red'>unused</font></strike>
<strong><font color='green'>-----------------------------------------</font></strong>
SFS _\0/_
/|\
/ \
Error
IP-SFS <strike><font color='red'>RTT</font></strike> <strong><font color='green'>unused
Figure 4:</font></strong> IP-SFS Control Signals.
<strike><font color='red'>Figure 4</font></strike>
FST: Frame STart. Signals the start of a new frame.
FEN: Frame ENd. Signals the end of one frame.
SUN: Signal UNdo. <strike><font color='red'>Cancel</font></strike> <strong><font color='green'>Cancels</font></strong> the transmission of one or more individual
SFSs within the current frame. This signal will be
unacknowledged by the receiver.
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. <strike><font color='red'>Acknowledge</font></strike> <strong><font color='green'>Acknowledges</font></strong> reception of one frame.
KAL: <strike><font color='red'>Keep ALive.</font></strike> <strong><font color='green'>KeepALive.</font></strong> 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. <strike><font color='red'>Signals that the</font></strike> <strong><font color='green'>The</font></strong> frame received is incorrect.
RTR: Ready To Receive. Receiver acknowledges it is ready to receive.
RTT: Ready To Transmit. <strike><font color='red'>Signal</font></strike> <strong><font color='green'>Sender requests permission</font></strong> to <strike><font color='red'>request initiation of</font></strike> <strong><font color='green'>initiate</font></strong>
transmission.
3.3. 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.
<strong><font color='green'>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.</font></strong>
3.4. Implementation Limitations
Maximum payload per frame: 510 SFS (0...510) nibbles (0 to 255
<strike><font color='red'>octets).</font></strike>
<strong><font color='green'>octets)</font></strong>
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. <strike><font color='red'>The</font></strike> <strong><font color='green'>A</font></strong> knowledge of the SFSS is <strike><font color='red'>a</font></strike> recommended, but its absence can
be compensated by a well-designed GUI.
4.1. <strike><font color='red'>Channel</font></strike> <strong><font color='green'>Data Link</font></strong> Control
This section describes the control protocol used to allocate the
half-duplex <strike><font color='red'>channel</font></strike> <strong><font color='green'>data link</font></strong> 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 <strike><font color='red'>interface-members</font></strike> <strong><font color='green'>interface members</font></strong> are
acquainted with each <strike><font color='red'>other</font></strike> <strong><font color='green'>other,</font></strong> 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 <strike><font color='red'>receive data from</font></strike> <strong><font color='green'>send an IP datagram
provided by</font></strong> a <strike><font color='red'>higher
level</font></strike> <strong><font color='green'>local higher-level</font></strong> protocol <strike><font color='red'>and/or</font></strike> <strong><font color='green'>or to receive a datagram
from</font></strong> the link-partner. <strong><font color='green'>Interfaces in State Idle must send keep-alive
signals</font></strong> KAL <strike><font color='red'>is to be transmitted</font></strike> at a frequency of at least KAL_FRQ.
There are no further definitions for State <strike><font color='red'>Idle</font></strike> <strong><font color='green'>Idle,</font></strong> but we recommend <strike><font color='red'>to
stay</font></strike>
<strong><font color='green'>staying</font></strong> away from alcoholic beverages or other types of drugs <strike><font color='red'>since this</font></strike> <strong><font color='green'>that</font></strong>
could lead to an increased number of FUN and/or SUN <strike><font color='red'>signas,</font></strike> <strong><font color='green'>signals,</font></strong> a
decrease in bandwidth, or an increase of line latency.
If the number of IP datagrams in the transmission queue is <strike><font color='red'>>0</font></strike> <strong><font color='green'>>0,</font></strong> 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 <strike><font color='red'>Layer</font></strike> <strong><font color='green'>layer</font></strong> protocol
level may start signaling RTT.
If the link partner does not respond with RTR within <strike><font color='red'>TIMEOUT</font></strike> <strong><font color='green'>TIMEOUT,</font></strong> or the
link partner responds with RTT, the interface switches to State Idle
for a random period of time between 2 seconds and <strike><font color='red'>TIMEOUT.</font></strike> <strong><font color='green'>TIMEOUT, before
resending the RTT.</font></strong>
If the link partner transmits RTR, the interface transmits the number
of IP-SFS frames to be transmitted in this session as two <strike><font color='red'>SFS</font></strike> <strong><font color='green'>SFSs</font></strong>
followed by another RTT. If the link partner does not transmit the
same number of IP-SFS frames followed by RTR within <strike><font color='red'>3*TIMEOUT</font></strike> <strong><font color='green'>3*TIMEOUT,</font></strong> 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 <strike><font color='red'>option</font></strike> <strong><font color='green'>option,</font></strong>
whereas throwing objects or using guns is not recommended, since it
could result in interface damage or destruction. This would be
<strike><font color='red'>counterproductive, since IP-SFS tries to improve communication among
humans.</font></strike>
<strong><font color='green'>counterproductive.</font></strong>
4.5. State Transmitting
Transmission of one IP-SFS frame starts with FST. After FST and
before FEN have been transmitted, the interface <strike><font color='red'>MAY</font></strike> <strong><font color='green'>may</font></strong> 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 <strike><font color='red'>Data</font></strike> <strong><font color='green'>data</font></strong> SFS, the interface
<strike><font color='red'>MAY</font></strike>
<strong><font color='green'>may</font></strong> invalidate the last <strike><font color='red'>Data</font></strike> <strong><font color='green'>data</font></strong> SFS by transmitting SUN followed by the
correct signal. A series of incorrectly transmitted <strike><font color='red'>Data SFS MAY</font></strike> <strong><font color='green'>data SFSs may</font></strong> be
invalidated by sending <strong><font color='green'>a</font></strong> SUN for each invalid <strike><font color='red'>SFS.</font></strike> <strong><font color='green'>SFS, effectively back-
spacing the sequence.</font></strong>
Control <strike><font color='red'>SFS</font></strike> <strong><font color='green'>SFSs</font></strong> cannot be invalidated.
If an error occurs, the interface <strike><font color='red'>MAY</font></strike> <strong><font color='green'>may</font></strong> also transmit FUN and restart
transmission of the active IP-SFS frame.
Whether the interfaces choses SUN or FUN for error correction is up
to the interface, but it is suggested to use SUN for <strong><font color='green'>a</font></strong> single invalid
SFS, and FUN whenever the interface failed to transmit several <strike><font color='red'>SFS</font></strike> <strong><font color='green'>SFSs</font></strong>
in a row.
After FEN has been transmitted, the <strong><font color='green'>transmitting</font></strong> interface waits for
the link partner to transmit ACK or NAK.
If ACK has been <strike><font color='red'>received</font></strike> <strong><font color='green'>received,</font></strong> the <strong><font color='green'>transmitting</font></strong> 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 <strike><font color='red'>no more frames are left to
transmit, the IP datagram is removed from the transmission queue and
the interface switches to State Idle.
If</font></strike> NAK has been received, the transmission <strike><font color='red'>failed</font></strike> <strong><font color='green'>failed,</font></strong> 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 <strike><font color='red'>MUST</font></strike> <strong><font color='green'>must</font></strong> start retransmitting the
active IP-SFS frame.
If transmission of the same IP-SFS frame fails <strike><font color='red'>for</font></strike> 5 <strike><font color='red'>times</font></strike> <strong><font color='green'>times,</font></strong> 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 <strike><font color='red'>receveived</font></strike> <strong><font color='green'>received</font></strong> from the
link partner in the receiving queue in the order of appearance.
After FST and before FEN have been <strike><font color='red'>received</font></strike> <strong><font color='green'>received,</font></strong> the interface <strike><font color='red'>MAY</font></strike> <strong><font color='green'>may</font></strong>
transmit FUN at any time to request a retransmission of the entire
IP-SFS frame.
If the time between two received <strike><font color='red'>SFS</font></strike> <strong><font color='green'>SFSs</font></strong> exceeds TIMEOUT, the <strong><font color='green'>receiving</font></strong>
interface
<strike><font color='red'>MUST</font></strike> <strong><font color='green'>must</font></strong> discard all data from the active IP-SFS frame and <strike><font color='red'>MAY</font></strike> <strong><font color='green'>may</font></strong>
additionally transmit FUN. If the link partner does not continue
transmitting within a second TIMEOUT period, the interface <strike><font color='red'>MUST</font></strike> <strong><font color='green'>must</font></strong> clear
the receiving queue and switch to State Idle.
If the interface receives SUN from the link partner, it <strike><font color='red'>MUST</font></strike> <strong><font color='green'>must</font></strong> discard
the last received data SFS (if any). If N SUNs are received in a
row, then the last N data SFS <strike><font color='red'>MUST</font></strike> <strong><font color='green'>must</font></strong> be <strike><font color='red'>discarded</font></strike> <strong><font color='green'>discarded,</font></strong> 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 <strike><font color='red'>MUST</font></strike> <strong><font color='green'>must</font></strong> be ignored by the
interface.
If the <strong><font color='green'>receiving</font></strong> 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 <strong><font color='green'>receiving</font></strong> 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 <strike><font color='red'>incorrect</font></strike> <strong><font color='green'>incorrect,</font></strong> 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 <strike><font color='red'>1/KAL_FRQ</font></strike> <strong><font color='green'>1/KAL_FRQ,</font></strong> 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 <strong><font color='green'>the</font></strong> TX and RX <strike><font color='red'>part</font></strike> <strong><font color='green'>parts</font></strong>
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 <strike><font color='red'>conferencing etc.)</font></strike> <strong><font color='green'>conferencing, etc.),</font></strong>
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 <strike><font color='red'>signalling,</font></strike> <strong><font color='green'>signaling,</font></strong> 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 <strike><font color='red'>Rittler</font></strike> <strong><font color='green'>Rittler,</font></strong> and Martin <strike><font color='red'>Schitter</font></strike> <strong><font color='green'>Schitter, and Bob Braden</font></strong> for all their
contributions and support <strike><font color='red'>to</font></strike> <strong><font color='green'>of</font></strong> this project.
7. References
[JCroft] Croft, J., "Semaphore Flag Signalling System", <strike><font color='red'>accessed
2007-03-26,</font></strike>
<http://www.anbg.gov.au/flags/semaphore.html>.
[Wikipedia] Wikipedia, <strike><font color='red'>n/a.,</font></strike> "Modern semaphore", <strike><font color='red'>accessed 2007-03-26,
<http://en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.</font></strike> <strong><font color='green'><http://
en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.</font></strong>
Authors' Addresses
Jogi Hofmueller (editor)
Brockmanngasse 65
Graz 8010
AT
<strike><font color='red'>Email:</font></strike>
<strong><font color='green'>EMail:</font></strong> ip-sfs@mur.at
Aaron Bachmann (editor)
Ulmgasse 14 C
Graz 8053
AT
<strike><font color='red'>Email:</font></strike>
<strong><font color='green'>EMail:</font></strong> ip-sfs@mur.at
<strike><font color='red'>IOhannes zmoelnig</font></strike>
<strong><font color='green'>Iohannes Zmoelnig</font></strong> (editor)
Goethestrasse 9
Graz 8010
AT
<strike><font color='red'>Email:</font></strike>
<strong><font color='green'>EMail:</font></strong> ip-sfs@mur.at
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.
<strike><font color='red'>Acknowledgment</font></strike>
<strong><font color='green'>Acknowledgement</font></strong>
Funding for the RFC Editor function is <strong><font color='green'>currently</font></strong> provided by the <strike><font color='red'>IETF
Administrative Support Activity (IASA).</font></strike>
<strong><font color='green'>Internet Society.</font></strong>
</pre>
</body></html>