[要約] 要約： RFC 4824は、Semaphore Flag Signaling System（SFSS）を介してIPデータグラムを転送するためのプロトコルを提案しています。目的： このRFCの目的は、SFSSを使用してIPデータグラムを転送するための標準化された方法を提供することです。これにより、特定の状況や環境での通信が可能になります。
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)
Semaphore Flag Signaling System（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）The IETF Trust（2007）。
Abstract
概要
This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS).
このドキュメントは、Semaphore Flag Signal System（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
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).
このドキュメントは、Semaphore Flag Signaling System（SFSS）におけるIPv4/IPv6パケットのカプセル化と送信の方法であるIP-SFSを指定します。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は、2つのインターフェイス間の半分二重チャネルを介して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つのインターフェイスで構成されています。
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つのセマフォフラグ信号、つまり1つのフラグパターン（セクション3.2）。
SFSS: The Semaphore Flag Signaling System.
SFSS：セマフォフラグシグナリングシステム。
IP-SFS: IP over Semaphore Flag Signaling System.
IP-SFS：Semaphore Flag Signaling System上の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は、標準のSFSSを適応させて、16の信号（フラグパターン）のアルファベットをエンコードして、データ値0-15（セクション3.2.1）と9つの信号を表して制御関数（セクション3.2.2）を表します。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によって区切られています。これは、SFSごとに1つの4ビットニブルで構成されています。
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で送信され、2番目はフレーム番号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
Protocol: 4 bits -- Internetwork-layer protocol code
0 None.
0なし。
1 For IPv4.
IPv4の場合。
2 For IPv6.
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ビット（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）。
2...15 Reserved for future use.
2 ... 15将来の使用のために予約されています。
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.
データ：0〜510のデータSFSS（セクション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：4つのデータSFSSとして16ビット。CRCチェックサム。0xffffまでプリセット。チェックサムの補完が送信されます。
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.
1分あたりの送信SFSの数（SPM）は、参加インターフェイスの経験に依存します。結果として生じるIP-SFSの1秒あたりのビットのリンク速度は（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]、[Wikipedia]、およびインターネット上のその他のソースで説明されているように、標準のSFSエンコードに基づいています。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エンコーディングによって16のデータ信号を定義し、SFSSエンコーディングQからXで表される9つの制御信号を定義します。
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を示しています。イラストは、受信側から見た各SFを示しています。
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.
図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.
9つのコントロール信号を使用して、特別なIP-SFS条件を通知します。それらの意味を図4に示します。図は、受信側から見た各SFを示しています。
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.
図4：IP-SFS制御信号。
FST: Frame STart. Signals the start of a new frame.
FST：フレーム開始。新しいフレームの開始を通知します。
FEN: Frame ENd. Signals the end of one frame.
フェン：フレームエンド。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.
太陽：信号元に戻ります。現在のフレーム内の1つ以上の個々の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.
楽しい：フレーム元に戻します。フレームエンドが送信されない限り、送信機または受信機は、現在のフレームの送信を再起動するために楽しいものを送ることができます。この信号は承認されておらず、受信機によって無視される場合があります。
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：Keepalive。接続を生き続けてください。少なくともKAL_FREQの頻度で状態アイドルで送信されます（セクション4.2を参照）。この信号は承認されていません。
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-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.
インターフェイスは、1人以上の人間の参加を通じて構築されます。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).
インターフェイスは、アイドル、送信（TX）、および受信（RX）の3つの状態を知っています。
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.
インターフェイスは、タイムアウトとしての期間を自由に交渉できます。タイムアウトの可能性のある値は、タバコを吸うのにかかる時間、またはコップ一杯の水を飲むのにかかる時間です。交渉が失敗した場合、タイムアウトはデフォルトで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.
KeepAlive周波数（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.
State Idleのインターフェイスは、ローカル高レベルのプロトコルによって提供されるIPデータグラムを送信するか、リンクパートナーからデータグラムを受信する準備ができている必要があります。状態のアイドル内のインターフェイスは、少なくともKAL_FRQの頻度でKILL-ALIVE SIGNALS 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フレームの数を2つのSFSSとして送信し、その後に別のRTTを送信します。リンクパートナーが同じ数のIP-SFSフレームを3*タイムアウト内でRTRを送信しない場合、インターフェイスは状態アイドルに切り替わります。
If the link partner transmits the same number of IP-SFS frames followed by RTR, the interface switches to State Transmitting.
リンクパートナーが同じ数のIP-SFSフレームを送信すると、RTRが続くと、インターフェイスは状態送信に切り替わります。
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.
1つのIP-SFSフレームの送信は、FSTで始まります。FSTの後、FENが送信される前に、インターフェイスは受信した楽しみを認め、アクティブフレームの送信を再起動するか、信号を破棄し、アクティブな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を送信することでエラーが発生した場合、インターフェイスは、正しい信号を送信することにより、最後のデータSFSを無効にする可能性があります。一連の誤って送信されたデータSFSSは、無効なSFSごとに太陽を送信し、シーケンスを効果的にバックスペースすることにより無効になる場合があります。
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.
エラーが発生した場合、インターフェイスはファンを送信し、アクティブな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 for Error Correctionを選択するかどうかはインターフェイスに依存しますが、単一の無効なSFSにSunを使用することをお勧めします。
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が受信される前に、インターフェイスはいつでも楽しみを送信して、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.
受信した2つのSFSSの間の時間がタイムアウトを超える場合、受信インターフェイスはアクティブなIP-SFSフレームからすべてのデータを破棄し、さらに楽しいものを送信する必要があります。リンクパートナーが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.
インターフェイスがリンクパートナーからSunを受信した場合、最後に受信したデータSFS（ある場合）を破棄する必要があります。n Sunsを連続して受け取った場合、フレームにデータSFがこれ以上ない場合を除き、最後のNデータSFを破棄する必要があります。廃棄するフレームにデータ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.
受信インターフェイスがリンクパートナーから楽しみを受け取った場合、これまでに受信したフレームを自由に破棄できます。信号を破棄すると帯域幅が減少するため、楽しみを称えることをお勧めします。
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ビット/sで始まり、疲労と濃度の不足により時間とともに減少します。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's Art Support（WAD）、Anita Hofer、Reni Hofmueller、Ulla Klopf、Nicole Pruckermayr、Manfred Rittler、Martin Schitter、およびBob BradenのEva HulsprungとDoris Jauk-Hinzに感謝します。
[JCroft] Croft, J., "Semaphore Flag Signalling System", <http://www.anbg.gov.au/flags/semaphore.html>.
[Jcroft] Croft、J。、「Semaphore Flag Signaling System」、<http://www.anbg.gov.au/flags/semaphore.html>。
[Wikipedia] Wikipedia, "Modern semaphore", <http:// en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.
[wikipedia] wikipedia、 "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
Aaron Bachmann (editor) Ulmgasse 14 C Graz 8053 AT
Aaron Bachmann（編集者）Ulmgasse 14 C Graz 8053 at
EMail: ip-sfs@mur.at
IOhannes zmoelnig (editor) Goethestrasse 9 Graz 8010 AT
Iohannes Zmoelnig（編集者）Goethestrasse 9 Graz 8010 at
EMail: ip-sfs@mur.at
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（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.
この文書は、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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。