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).
著作権（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
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、ウィキペディア]の一対の波打ちに基づいて国際的に認められたアルファベット通信システムです。 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の図は、インターネットプロトコル階層におけるSFSSの場所を示します。
+-----+ +-----+ +-----+
| 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つの（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：つ手旗信号、すなわち、1つのフラグパターン（セクション3.2）。
SFSS: The Semaphore Flag Signaling System.
SFSS：手旗信号システム。
IP-SFS: IP over Semaphore Flag Signaling System.
IP-SFS：手旗信号システム上のIP。
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は、データを表すために16個の信号（フラグパターン）のアルファベットを符号化するために、標準的なSFSSを適応制御機能（3.2.2）を表すために0-15（3.2.1）と9つの信号値。 16のデータ信号が、IP-SFSの送信は4ビットニブル、オクテット当たり2つに基づいています。セクション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は、1つの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 |
+--------+--------+--------+--------+---------+
Note that each field represents one SFS or 4 bits.
各フィールドは1つのSFS又は4ビットを表すことに留意されたいです。
Figure 2: IP-SFS Frame Format
図2：IP-SFSフレーム形式
FST: Frame Start control SFS
FST：フレームスタート制御SFS
Protocol: 4 bits -- Internetwork-layer protocol code
プロトコル：4ビット - インターネットワーク層プロトコル・コード
0 None.
0なし。
1 For IPv4.
IPv4の1。
2 For IPv6.
IPv6の2。
3 For IPv4 frame gzip-compressed.
IPv4のフレームGZIP圧縮3。
4 For IPv6 frame gzip-compressed.
IPv6のフレームGZIP圧縮4。
CksumTyp: 4 bits (one data SFS) -- Checksum Type
CksumTyp：4ビット（1つのデータ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）。
Frame No: 8 bits (2 data SFSs): Frame number for fragmented IP datagram.
8ビット（2つのデータSFSS）：断片化されたIPデータグラムのためのフレーム番号なしフレームありません。
DATA: 0 to 510 data SFSs (Section 3.2.1) representing 0 to 255 octets of payload.
DATA：ペイロードの0〜255オクテットを表す0〜510のデータSFSS（セクション3.2.1）。
CRC: 16 bits as four data SFSs. CRC checksum. Preset to 0xFFFF. One's complement of checksum is transmitted.
CRC：4つのデータSFSSとして16ビット。 CRCチェックサム。 0xFFFFのようにプリセット。チェックサムの1の補数が送信されます。
FEN: Frame ENd control SFS.
FEN：フレーム終了制御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.
分あたりの送信SFSS（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.
[JCroft]、[ウィキペディア]、およびインターネット上の他のソースによって記載されるように、データ信号及び制御信号は、標準的なSFS符号化に基づいています。 9つの制御信号はデータリンク制御のために使用されている間16個のデータ信号は、4ビットのニブルとして解釈されます。
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はPに文字やXにSFSSエンコーディングQで表される9つの制御信号の元SFSS符号化によって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のSFSSがリンクを介してデータフレームを送信するために使用示します。受信側から見た図は、各SFSを示します。
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の条件を通知するために使用されます。その意味は、受信側から見た図は、各SFSを示し、図4に記載されています。
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未使用
-----------------------------------------
SFS _\0/_ /|\ / \ Error IP-SFS unused
SFS _ \ 0 / _ / | \ / \エラーIP-SFS未使用
Figure 4: IP-SFS Control Signals.
図4：IP-SFSコントロール信号。
FST: Frame STart. Signals the start of a new frame.
FST：フレーム開始。新しいフレームの開始を通知します。
FEN: Frame ENd. Signals the end of one frame.
FEN：フレーム終了。 1つのフレームの終わりを示します。
SUN: Signal UNdo. Cancels the transmission of one or more individual SFSs within the current frame. This signal will be unacknowledged by the receiver.
SUN：信号UNDO。現在のフレーム内の1つ以上の個々のSFSSの送信をキャンセルします。この信号は、受信機によって未確認となります。
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：UNDOフレーム。限りフレーム終了が送信されないように、送信機または受信機は、現在のフレームの送信を再開するためにFUNを送信することができます。この信号は未確認となり、受信機によって無視されることがあります。
ACK: Frame ACK. Acknowledges reception of one frame.
ACK：ACKフレーム。 1つのフレームの受信を肯定応答します。
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：キープアライブ。アライブ接続をしてください。 （セクション4.2を参照）は、少なくともKAL_FREQの周波数におけるアイドル状態で送信されます。この信号は未確認となります。
NAK: Frame No AcK. The frame received is incorrect.
NAK：いいえ、ACKフレーム。受信したフレームが正しくありません。
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-4（プロセーラー）に1E-3（ボーイスカウト）の範囲であることが予想され、また、物理的要因の数に依存しています。天候条件や照明の欠如（例えば、夜間）への視界不良は大幅に誤り率を向上させることができます。
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.
インタフェースは、一人の以上の人間の参加により構成されています。 SFSSの知識が推奨されるが、その不在が適切に設計された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).
インタフェースは、次の3つの状態を知っている：アイドル、送信（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.
インタフェースは、同じサブネット上の2つの異なる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.
インタフェースは、TIMEOUTとして、任意の期間を交渉するのは自由です。 TIMEOUTのための可能な値は、それがタバコまたはそれは水のガラスを飲むのにかかる時間が喫煙するのにかかる時間です。交渉は60秒に、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 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.
そこアイドル状態のための更なる定義はありませんが、我々は、アルコール飲料やFUNおよび/またはSUN信号の数が増加し、帯域幅の減少、またはラインの待ち時間の増加につながる可能性がある薬の他のタイプから離れて滞在をお勧めします。
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.
リンクパートナーがTIMEOUT内RTRに応答しない場合、またはリンクパートナーは、RTTで応答した場合、インターフェイスのスイッチは、RTTを再送する前に、2秒とTIMEOUTの間の時間のランダムな期間、アイドル状態に。
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の数が2つのSFSSが別のRTTが続くように、このセッションで送信されるフレームを送信します。リンクパートナーが3 * TIMEOUTの内RTRに続いてIP-SFSフレームの同じ番号を送信しない場合は、インタフェースがアイドル状態に切り替わります。
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.
環境ノイズまたは大きな距離を妨げない限り、アイドル状態のリンクパートナーからのラインの規律を要求するために使用することができますhollering。携帯電話の使用は、インタフェースの損傷や破壊につながる可能性があるため、オブジェクトを投げたり銃を使用してのに対し、推奨されていない、また、オプションです。これは逆効果になります。
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.
1 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を無効にしてもよいです。誤って送信されたデータSFSS一連の効果的配列をバック間隔、各無効SFSためSUNを送信することによって無効にすることができます。
Control SFSs cannot be invalidated.
コントロールSFSSは無効にすることはできません。
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を選択するかどうかインターフェイスが行のいくつかのSFSS送信に失敗したときはいつでも、エラー訂正のための楽しいインターフェイスまでであり、単一の無効SFSためSUNを使用することが提案されており、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.
リンクパートナーがTIMEOUT以内に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が受信される前に、インターフェイスは、全IP-SFSフレームの再送を要求するためにいつでもFUNを送信してもよいです。
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.
両者の時間がSFSSタイムアウトを超える受信した場合、受信インタフェースは、アクティブなIP-SFSフレームからすべてのデータを破棄しなければならず、さらにFUNを送信することができます。リンクパートナーが第2のタイムアウト期間内に送信を継続しない場合、インターフェイスは受信キューをクリアし、アイドル状態に切り替える必要があります。
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.
インタフェースはリンクパートナーからの日を受信した場合、それは最後に受信したデータSFSを（もしあれば）破棄しなければなりません。 N太陽行で受信している場合は、フレーム内のない複数のデータSFSがない限り、最後のN個のデータSFSは、廃棄しなければなりません。これ以上のデータSFSを破棄するフレームに存在しない場合、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.
受信インタフェースがリンクパートナーからFUNを受信した場合、これまでに受信したフレームを破棄して自由です。私たちは、帯域幅が減少する信号を破棄するので、FUNを称えることをお勧めします。
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.
インタフェースは州内のアイドルであり、リンクパートナーが少なくとも5回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.
それは1人でインターフェースのTXとRXの部品を組み合わせることが理論的には可能ですが、我々は、インターフェイスごとに少なくとも2人の間で業務を分割することをお勧めします。長い伝送（マルチメディアストリーミング、ビデオ会議など）の場合は、回転や代替品の提供を検討。
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ビット/秒から始まり、疲労や集中力の欠如に起因する時間の経過とともに減少します。 RXインターフェースよりも速い速度でTX状態信号にインタフェースが受信可能である場合、信号損失が発生します。
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）、アニタ・ホーファー、レニHofmueller、ウラKlopf、ニコールPruckermayr、マンフレッドRittler、マーティンSchitter、ボブブレーデンからエヴァUrsprungとドリスJauk-Hinzに感謝します。
[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
JogiHofmüller（エディタ）Brockmanngasse 65グラーツ8010 AT
EMail: ip-sfs@mur.at
メールアドレス：ip-sfs@mur.at
Aaron Bachmann (editor) Ulmgasse 14 C Graz 8053 AT
アーロン・バッハマン（エディタ）Ulmgasse 14 Cグラーツ8053 AT
EMail: ip-sfs@mur.at
メールアドレス：ip-sfs@mur.at
IOhannes zmoelnig (editor) Goethestrasse 9 Graz 8010 AT
IOhannes zmoelnig（エディタ）ゲーテ9グラーツ8010 AT
EMail: ip-sfs@mur.at
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。