Network Working Group J. Hofmueller, Ed.
Request for Comments: 4824 A. Bachmann, Ed.
Category: Informational IO. zmoelnig, Ed.
1 April 2007
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)
通过信号量标志信令系统（SFSS）传输IP数据报
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).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).
本文件规定了通过信号量标志信号系统（SFSS）封装和传输IPv4/IPv6数据包的方法。
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
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
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，这是一种通过信号量标志信令系统（SFSS）封装和传输IPv4/IPv6数据包的方法。SFSS是一种国际公认的字母通信系统，它基于一对手持旗帜的挥动[JCroft，Wikipedia]。在SFSS下，每个字母字符或控制信号由一个特定的标志模式表示，称为信号量标志信号（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.
IP-SFS通过两个接口之间的半双工信道提供IP数据报的可靠传输。在物理层，SFSS使用光传输，通常使用太阳照明和视线光子学穿过大气层。控制协议（第4节）允许每个接口在公共信道上竞争传输。
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.
图1中的图表说明了SFS在Internet协议层次结构中的位置。
+-----+ +-----+ +-----+
| TCP | | UDP | ... | | Host Layer
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Internet Layer
+-------------------------------+
|
+-------------------------------+
| SFSS | Link Layer
+-------------------------------+
+-----+ +-----+ +-----+
| TCP | | UDP | ... | | Host Layer
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Internet Layer
+-------------------------------+
|
+-------------------------------+
| SFSS | Link Layer
+-------------------------------+
Figure 1: Protocol Relationships
图1：协议关系
Link: A link consists of two (2) interfaces that share a common subnet.
链路：链路由两（2）个共享公共子网的接口组成。
Link Partner: The opposite interface.
链接伙伴：相反的接口。
Session: The transmission of an entire IP datagram.
会话：整个IP数据报的传输。
SFS: One Semaphore Flag Signal, i.e., one flag pattern (Section 3.2).
SFS：一个信号量标志信号，即一个标志模式（第3.2节）。
SFSS: The Semaphore Flag Signaling System.
SFSS：信号量标志信号系统。
IP-SFS: IP over Semaphore Flag Signaling System.
IP-SFS:IP over信号量标志信令系统。
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.
IP-SFS采用标准SFS对16个信号（标志模式）的字母表进行编码，以表示数据值0-15（第3.2.1节），9个信号表示控制功能（第3.2.2节）。IP-SFS传输有16个数据信号，基于4位半字节，每八位字节两个。第3.2节中定义的每个信号模式称为SFS。
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.
IP数据报通过添加IP-SFS报头和尾部格式化为IP-SFS帧。图2显示了一个IP-SFS帧的格式。帧由名为FST（帧开始）的控制SFS和名为FEN（帧结束）的控制SFS分隔。它由一系列4位半字节组成，每个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.
如有必要，IP数据报将分为多个连续的IP-SFS帧。当IP数据报分为N个帧时，第一个帧将以帧号N-1发送，第二个帧将以帧号N-2发送，…，最后一个帧将以帧号0发送。
0 1 2 3
+--------+--------+--------+--------+--------+
| FST |Protocol|CksumTyp|Frame No|Frame No|
+--------+--------+--------+--------+--------+
| |
// DATA Payload //
| |
+--------+--------+--------+--------+---------+
| CRC | CRC | CRC | CRC | FEN |
+--------+--------+--------+--------+---------+
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.
请注意，每个字段表示一个SFS或4位。
Figure 2: IP-SFS Frame Format
图2:IP-SFS帧格式
FST: Frame Start control SFS
帧启动控制SFS
Protocol: 4 bits -- Internetwork-layer protocol code
协议：4位——网络层协议代码
0 None.
0无。
1 For IPv4.
1表示IPv4。
2 For IPv6.
2用于IPv6。
3 For IPv4 frame gzip-compressed.
3用于IPv4帧gzip压缩。
4 For IPv6 frame gzip-compressed.
4用于IPv6帧gzip压缩。
5...15 Reserved for future use.
5…15保留供将来使用。
CksumTyp: 4 bits (one data SFS) -- Checksum Type
CksumTyp:4位（一个数据SFS）——校验和类型
0 none.
0无。
1 CCITT CRC 16 (polynomial: x^16 + x^12 + x^5+1).
1 CCITT CRC 16（多项式：x^16+x^12+x^5+1）。
2...15 Reserved for future use.
2…15保留供将来使用。
Frame No: 8 bits (2 data SFSs): Frame number for fragmented IP datagram.
帧号：8位（2个数据SFS）：分段IP数据报的帧号。
DATA: 0 to 510 data SFSs (Section 3.2.1) representing 0 to 255 octets of payload.
数据：0至510个数据SFS（第3.2.1节），代表0至255个八位字节的有效载荷。
CRC: 16 bits as four data SFSs. CRC checksum. Preset to 0xFFFF. One's complement of checksum is transmitted.
CRC：16位作为四个数据SFS。CRC校验和。预设为0xFFFF。传输一个人的校验和补码。
FEN: Frame ENd control SFS.
帧结束控制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.
每分钟传输的SFS数量（Spm）取决于参与接口的经验。IP-SFS的最终链路速度（以比特/秒为单位）为（Spm/60）*4，不计算帧开销。
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.
数据信号和控制信号基于标准SFS编码，如[JCroft]、[Wikipedia]和互联网上的其他来源所述。16个数据信号被解释为4位半字节，而9个控制信号用于数据链路控制。
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.
IP-SFS通过字母A到P的原始SFSS编码和SFSS编码Q到X表示的9个控制信号定义了16个数据信号。
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.
图3说明了用于通过链路传输数据帧的16个SFS。插图显示了从接收侧看到的每个SFS。
SFS 0 __0 \0 |0
/|| || || ||
/ \ / \ / \ / \
A B C D
IP-SFS 0x00 0x01 0x02 0x03
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
|| || ||\ /|
/ \ / \ / \ / \
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/
/| | /| /|
/ \ / \ / \ / \
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
SFS 0__ 0 _\0 __0|
/| /|\ | |
/ \ / \ / \ / \
M N O P
IP-SFS 0x0C 0x0D 0x0E 0x0F
Figure 3: IP-SFS Data Signals.
图3:IP-SFS数据信号。
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.
九个控制信号用于发出特殊IP-SFS条件的信号。它们的含义如图4所示。插图显示了从接收侧看到的每个SFS。
SFS __0/ __0__ __0 \0|
| | |\ |
/ \ / \ / \ / \
Q R S T
IP-SFS FST FEN SUN FUN
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__ 0/_ 0/
| | | |\
/ \ / \ / \ / \
U V W X
IP-SFS ACK KAL NAK RTR
-----------------------------------------
-----------------------------------------
SFS 0__ 0__
/| |\
/ \ / \
Y Z
IP-SFS RTT unused
SFS 0__ 0__
/| |\
/ \ / \
Y Z
IP-SFS RTT unused
-----------------------------------------
-----------------------------------------
SFS _\0/_
/|\
/ \
Error
IP-SFS unused
SFS _\0/_
/|\
/ \
Error
IP-SFS unused
Figure 4: IP-SFS Control Signals.
图4:IP-SFS控制信号。
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.
太阳：信号解除。取消当前帧内一个或多个单独SFS的传输。接收器将不确认该信号。
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.
有趣：帧撤消。只要不发送帧结束，发射机或接收机就可以发送一个FUN来重新开始当前帧的传输。此信号将不被确认，并且可能被接收器忽略。
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.
卡尔：保持活力。保持连接活动。以至少KAL_FREQ的频率在空闲状态下传输（见第4.2节）。此信号将不被确认。
NAK: Frame No AcK. The frame received is incorrect.
NAK：帧没有应答。接收到的帧不正确。
RTR: Ready To Receive. Receiver acknowledges it is ready to receive.
RTR：准备接收。接收方确认其已准备好接收。
RTT: Ready To Transmit. Sender requests permission to initiate transmission.
RTT：准备传输。发件人请求启动传输的权限。
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.
由于传输信道的物理特性，误码率预计在1e-3（童子军）到1e-4（专业水手）之间，并且还取决于许多物理因素。由于天气条件或缺乏照明（如夜间）造成的能见度低会大大增加错误率。
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.
IP-SFS无法处理帧重新排序或双（多）帧接收。因此，该协议不适用于接口移动快和/或光路长的环境。
Maximum payload per frame: 510 SFS (0...510) nibbles (0 to 255 octets)
每帧最大有效负载：510个SFS（0…510）字节（0到255个八位字节）
Maximum SFS per frame: 518
每帧最大SFS:518
Maximum frames per session: 255 (0...254)
每个会话的最大帧数：255（0…254）
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.
一个界面是通过一个或多个人的参与来构建的。建议了解SFS，但它的缺失可以通过设计良好的GUI来弥补。
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).
接口知道三种状态：空闲、发送（TX）和接收（RX）。
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.
IP-SFS是严格的点对点。除非接口成员彼此熟悉，否则建议在建立链接之前对双方进行简要介绍，以降低接口欺骗攻击的可能性。
Interfaces must agree on two different IP addresses on the same subnet.
接口必须在同一子网上的两个不同IP地址上保持一致。
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.
接口可以自由协商任何时间段作为超时。超时的可能值是吸烟或喝水所需的时间。如果协商失败，超时默认为60秒。
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.
相同的程序可适用于保持频率（KAL_FRQ）。KAL_FRQ（1/KAL_FRQ）的周期应至少为5*超时。
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.
处于空闲状态的接口必须准备好发送本地高级协议提供的IP数据报或从链路伙伴接收数据报。处于空闲状态的接口必须以至少KAL_FRQ的频率发送保持活动的信号KAL。
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.
如果传输队列中的IP数据报数>0，接口可能会尝试通过向链路伙伴发送RTT来启动会话。如果链路伙伴准备接收，它将返回RTR信号。
An interface receiving a datagram from an Internet layer protocol level may start signaling RTT.
从因特网层协议级别接收数据报的接口可以开始信令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, before resending the RTT.
如果链路伙伴在超时内没有使用RTR响应，或者链路伙伴使用RTT响应，则在重新发送RTT之前，接口会在2秒到超时之间的随机时间段内切换为空闲状态。
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.
如果链路伙伴传输RTR，则接口将此会话中要传输的IP-SFS帧的数量传输为两个SFS，后跟另一个RTT。如果链路伙伴在3*超时内未发送相同数量的IP-SFS帧，然后发送RTR，则接口将切换到空闲状态。
If the link partner transmits the same number of IP-SFS frames followed by RTR, the interface switches to State Transmitting.
如果链路伙伴在RTR之后传输相同数量的IP-SFS帧，则接口切换到状态传输。
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.
除非受到环境噪音或远距离的阻碍，否则可以使用呼叫向处于空闲状态的链路伙伴请求线路纪律。使用手机也是一种选择，但不建议投掷物品或使用枪支，因为这可能导致界面损坏或破坏。这将适得其反。
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.
一个IP-SFS帧的传输从FST开始。在发送FST之后和FEN之前，接口可以确认接收到的FUN并重新启动活动帧的传输，或者丢弃信号并继续传输活动IP-SFS帧。
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.
如果由于传输错误的数据SFS而发生错误，则接口可能会通过传输SUN和正确的信号使最后的数据SFS无效。通过为每个无效SF发送SUN，可以使一系列错误传输的数据SFS无效，有效地将序列向后间隔。
Control SFSs cannot be invalidated.
无法使控件SFS无效。
If an error occurs, the interface may also transmit FUN and restart transmission of the active IP-SFS frame.
如果发生错误，接口还可能传输FUN并重新启动活动IP-SFS帧的传输。
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.
接口是否选择SUN或FUN进行纠错取决于接口，但建议将SUN用于单个无效SFS，并在接口未能连续传输多个SFS时使用FUN。
After FEN has been transmitted, the transmitting interface waits for the link partner to transmit ACK or NAK.
在FEN被发送之后，发送接口等待链路伙伴发送ACK或NAK。
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.
如果接收到ACK，发送接口将删除活动帧并开始发送下一个IP-SFS帧。如果没有剩余帧，接口将切换到空闲状态。
If NAK has been received, the transmission failed, and the interface must start transmitting the active frame again.
如果已接收到NAK，则传输失败，接口必须再次开始传输活动帧。
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.
如果链路伙伴在超时时间内未传输ACK或NAK，则传输失败，接口必须开始重新传输活动IP-SFS帧。
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.
如果同一IP-SFS帧的传输失败5次，接口将IP数据报留在传输队列中，并切换到空闲状态。
In State Receiving, the interface stores each SFS received from the link partner in the receiving queue in the order of appearance.
在接收状态下，接口将从链路伙伴接收的每个SFS按出现顺序存储在接收队列中。
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.
在接收到FST之后和FEN之前，接口可随时发送FUN以请求重新传输整个IP-SFS帧。
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.
如果两个接收到的SFS之间的时间超过超时，则接收接口必须丢弃来自活动IP-SFS帧的所有数据，并可额外发送FUN。如果链路伙伴在第二个超时时间内没有继续传输，接口必须清除接收队列并切换到空闲状态。
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.
如果接口从链路伙伴接收到SUN，则必须丢弃最后接收到的数据SFS（如果有）。如果一行接收到N个太阳，则必须丢弃最后N个数据SF，除非帧中没有更多的数据SF。如果帧中没有更多要丢弃的数据SF，接口必须忽略SUN信号。
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.
收到FEN后，接收接口评估校验和。如果校验和良好，接口将发送ACK。如果活动帧的帧号为0，则接口将整个数据从接收队列传递到更高级别的协议，清除接收队列，并切换到空闲状态。
If the checksum is incorrect, the interface transmits NAK.
如果校验和不正确，接口将传输NAK。
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.
如果接口处于空闲状态，且链路伙伴至少五次1/KAL_FRQ未传输任何类型的SFS，则连接终止，接口可自由解散。
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.
接口通过适当的输入设备（RX）和输出设备（TX）连接到计算机硬件。可能的设备包括键盘、鼠标和显示器。其他连接方式取决于可用性和预算。
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.
虽然从理论上讲，在一个人身上结合一个接口的TX和RX部分是可能的，但我们建议每个接口至少在两个人之间划分操作。对于较长的传输（多媒体流、视频会议等），考虑旋转和提供替代物。
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.
带宽趋于变化。通常，TX以2-4位/秒的速度开始，随着时间的推移，由于耗尽和浓度不足，TX会降低。当处于TX状态的接口能够以高于RX接口的速率接收信号时，会发生信号丢失。
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.
由于其视线信号的性质，IP-SFS被认为是不安全的。强烈反对通过IP-SFS传输敏感数据，除非通过更高级别的协议提供安全性。
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.
我们目前还不知道有哪种技术可以在不永久破坏接口的情况下可靠地从接口内存中删除数据。
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.
我们感谢Womyn的艺术支持部门（WAS）的Eva Ursprung和Doris Jauk Hinz、Anita Hofer、Reni Hofmueller、Ulla Klopf、Nicole Pruckermair、Manfred Rittler、Martin Schitter和Bob Braden对本项目的所有贡献和支持。
[JCroft] Croft, J., "Semaphore Flag Signalling System", <http://www.anbg.gov.au/flags/semaphore.html>.
[JCroft]克罗夫特，J.，“信号灯信号系统”<http://www.anbg.gov.au/flags/semaphore.html>.
[Wikipedia] Wikipedia, "Modern semaphore", <http:// en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.
[维基百科]维基百科，“现代信号量”，<http://en.Wikipedia.org/wiki/semaphore#Modern_semaphore>。
Authors' Addresses
作者地址
Jogi Hofmueller (editor) Brockmanngasse 65 Graz 8010 AT
Jogi Hofmueller（编辑）Brockmanngasse 65 Graz 8010 AT
EMail: ip-sfs@mur.at
EMail: ip-sfs@mur.at
Aaron Bachmann (editor) Ulmgasse 14 C Graz 8053 AT
Aaron Bachmann（编辑）Ulmgasse 14 C Graz 8053 AT
EMail: ip-sfs@mur.at
EMail: ip-sfs@mur.at
IOhannes zmoelnig (editor) Goethestrasse 9 Graz 8010 AT
IOhannes zmoelnig（编辑）Goethestrasse 9 Graz 8010
EMail: ip-sfs@mur.at
EMail: ip-sfs@mur.at
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。