サイト内関連リンク：
RFC 791 IP (日本語訳)
原文：ftp://ftp.rfc-editor.org/in-notes/rfc4824.txt
原文との対訳として読みたい方へ：このページをローカルに保存して、スタイルシートの original クラスの display 属性を none から block に変更してみてください。
ソーシャルブックマーク：
サイト内関連リンク：
RFC 791 IP (日本語訳)
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 (C) The IETF Trust (2007).
This document specifies a method for encapsulating and transmitting IPv4/IPv6 packets over the Semaphore Flag Signal System (SFSS). この文書は、手旗信号システム(SFSS)によって IPv4/IPv6 パケットをカプセル化および送信するための手段を規定する。
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). この文書は、手旗信号システム(SFSS)によって IPv4/IPv6 パケットをカプセル化および送信するための手段、IP-SFS を規定する。SFSS は 2 本の手持ちの旗を振ることに基づく、国際的に認知されているアルファベット通信システムである [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 のデータグラムは、インターネットプロトコル階層内での SFSS の位置を説明している。
+-----+ +-----+ +-----+
| TCP | | UDP | ... | | Host Layer
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | Internet Layer
+-------------------------------+
|
+-------------------------------+
| SFSS | Link Layer
+-------------------------------+
Figure 1: Protocol Relationships
+-----+ +-----+ +-----+
| TCP | | UDP | ... | | ホスト層
+-----+ +-----+ +-----+
| | |
+-------------------------------+
| Internet Protocol & ICMP | インターネット層
+-------------------------------+
|
+-------------------------------+
| SFSS | リンク層
+-------------------------------+
図 1：プロトコルの関係
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 を適合させることで、データ値 0-15 を表すために 16 種類のアルファベット信号(フラグパターン)(セクション 3.2.1)を、制御機能を表すために 9 種類の信号(セクション 3.2.2)を、それぞれ符号化する。16 種類のデータ信号のために、IP-SFS 通信はオクテットごとに二つの 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 とによって区切られる。それは SFS ごとにひとつの一連の 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.
Figure 2: IP-SFS Frame Format
0 1 2 3
+--------+--------+--------+--------+--------+
| FST |Protocol|CksumTyp|Frame No|Frame No|
+--------+--------+--------+--------+--------+
| |
// DATA Payload //
| |
+--------+--------+--------+--------+---------+
| CRC | CRC | CRC | CRC | FEN |
+--------+--------+--------+--------+---------+
各フィールドがひとつの SFS または 4 ビットを表すことに注意
図 2 ：IP-SFS フレームフォーマット
FST: Frame Start control SFS
Protocol: 4 bits -- Internetwork-layer protocol code
0 None.
1 For IPv4.
2 For IPv6.
3 For IPv4 frame gzip-compressed.
4 For IPv6 frame gzip-compressed.
5...15 Reserved for future use.
CksumTyp: 4 bits (one data SFS) -- Checksum Type
0 none.
1 CCITT CRC 16 (polynomial: x^16 + x^12 + x^5+1).
2...15 Reserved for future use.
Frame No: 8 bits (2 data SFSs):
Frame number for fragmented IP datagram.
DATA: 0 to 510 data SFSs (Section 3.2.1) representing 0 to 255
octets of payload.
CRC: 16 bits as four data SFSs.
CRC checksum. Preset to 0xFFFF. One's complement of
checksum is transmitted.
FEN: Frame ENd control SFS.
FST: フレームスタート コントロール SFS
Protocol: 4 ビット -- ネットワーク間レイヤプロトコルコード
0 なし
1 IPv4
2 IPv6
3 gzip 圧縮された IPv4 フレーム
4 gzip 圧縮された IPv6 フレーム
5...15 将来のために予約済み
CksumTyp: 4 ビット (1 データ SFS) -- チェックサム種別
0 なし
1 CCITT CRC 16 (多項式： x^16 + x^12 + x^5+1).
2...15 将来のために予約済み
Frame No: 8 ビット (2 データ SFS):
分断された IP データグラムのためのフレーム番号
DATA: ペイロードの 0 から 255 のオクテットを表す 0 から 510 の
データ SFS (セクション 3.2.1)
CRC: 4 データ SFS の 16 ビット
CRC チェックサム。規定値は 0xFFFF。チェックサムの 1 の補数
が送信される。
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 の bps 単位の回線速度は、フレーム化のオーバヘッドを抜きにして (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 は 16 種類のデータ信号をオリジナルの SFSS エンコードの A から P の文字で定義し、9 種類の制御信号を SFSS の Q から X の文字で表す。
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
|| || ||\ /|
/ \ / \ / \ / \
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.
SFS ０ ＿０ ＼０ ｜０
／｜｜ ｜｜ ｜｜ ｜｜
／＼ ／＼ ／＼ ／＼
A B C D
IP-SFS 0x00 0x01 0x02 0x03
-----------------------------------------
SFS ０／ ０＿ ０ ＿０
｜｜ ｜｜ ｜｜＼ ／｜
／＼ ／＼ ／＼ ／＼
E F G H
IP-SFS 0x04 0x05 0x06 0x07
-----------------------------------------
SFS ＼０ ｜０＿ ０｜ ０／
／｜ ｜ ／｜ ／｜
／＼ ／＼ ／＼ ／＼
I J K L
IP-SFS 0x08 0x09 0x0A 0x0B
-----------------------------------------
SFS ０＿ ０ ＼０ ＿０｜
／｜ ／｜＼ ─｜ ｜
／＼ ／＼ ／＼ ／＼
M N O P
IP-SFS 0x0C 0x0D 0x0E 0x0F
図 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 条件を伝えるために使用される。それぞれのイラストは受信側から見た SFS を表している。
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.
SFS ＿０／ ＿０＿ ＿０ ＼０｜
｜ ｜ ｜＼ ｜
／＼ ／＼ ／＼ ／＼
Q R S T
IP-SFS FST FEN SUN FUN
-----------------------------------------
SFS ＼０／ ＼０＿ ０／ ０／
｜ ｜ ｜─ ｜＼
／＼ ／＼ ／＼ ／＼
U V W X
IP-SFS ACK KAL NAK RTR
-----------------------------------------
SFS ０＿ ０＿
／｜ ｜＼
／＼ ／＼
Y Z
IP-SFS RTT 未使用
-----------------------------------------
SFS ＿＼０／＿
／｜＼
／＼
エラー
IP-SFS 未使用
図 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.
FUN: Frame UNdo. As long as Frame ENd is not sent, the transmitter
or the receiver may send a FUN to restart the transmission of
the current frame. This signal will be unacknowledged and may
be ignored by the receiver.
ACK: Frame ACK. Acknowledges reception of one frame.
KAL: KeepALive. Keep a connection alive. Is to be transmitted in
State Idle at a frequency of at least KAL_FREQ (see
Section 4.2). This signal will be unacknowledged.
NAK: Frame No AcK. The frame received is incorrect.
RTR: Ready To Receive. Receiver acknowledges it is ready to receive.
RTT: Ready To Transmit. Sender requests permission to initiate
transmission.
FST: フレームスタート(Frame STart)。新しいフレームの開始を伝える。
FEN: フレームエンド(Frame ENd)。フレームの終了を伝える。
SUN: 信号取り消し(Signal UNdo)。現在のフレーム内のひとつ以上の SFS の
送信をキャンセルする。受信側はこの信号に応答しない。
FUN: フレーム取り消し(Frame UNdo)。FEN が送信されていない限り、送信側も
受信側も、現在のフレームの送信を最初からやり直すために FUN を送信し
てよい。受信側はこの信号に応答せず、無視する可能性がある。
ACK: フレーム肯定応答(Frame ACK)。1 フレームの受信を承認する。
KAL: キープアライブ(KeepALive)。回線の活性状態を維持する。
アイドル状態において少なくとも KAL_FREQ (セクション 4.3 参照)
の頻度で送信される。この信号に応答はない。
NAK: フレーム否定応答(Frame No AcK)。受信したフレームは不正である。
RTR: 受信準備完了(Ready To Receive)。受信側は受信の準備ができている。
RTT: 送信準備完了(Ready To Transmit)。送信側は送信開始の許可を求めている。
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). インターフェイスは待機(Idle)・送信中(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. インターフェイスはタイムアウト(TIMEOUT)間隔を自由に交渉できる。TIMEOUT に可能な値は、タバコを一服するか水を一杯飲むのにかかる時間である。交渉に失敗した場合の TIMEOUT のデフォルトは 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 FReQuency:KAL_FRQ)にも適用できる。KAL_FRQ の間隔(1/KAL_FRQ)は少なくとも 5*TIMEOUT でなければならない。
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 を送信した場合、インターフェイスはもうひとつの RTT に続けて、そのセッションで送信される IP-SFS フレーム数を二つの SFS として送信する。リンク相手が 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. 騒音や長距離に邪魔されない限り、大声で叫ぶことでアイドル状態のリンク相手に回線の統制を求めることができる。また携帯電話の使用はオプションだが、物を投げたり銃を使用したりするとインターフェイスにダメージを与えたり破壊したりする可能性があるため推奨されない。逆効果だろう。
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 を取り消すことができる。誤って送信された一連のデータ SFS を、無効な SFS ごとに SUN を送信することで取り消してもよい。事実上のバックスペースである。
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 を選ぶかはインターフェイス次第だが、単独の無効な 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-FSF フレーム全体の再送信を要求するために、いつでも 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. 二つの SFS の受信間隔が TIMEOUT を超えた場合、受信側インターフェイスは現在の IP-SFS フレームからすべてのデータを破棄しなければならず、さらに FUN を送信してもよい。次の TIMEOUT 間隔以内にリンク相手が送信を続けなかった場合、インターフェイスは受信キューをクリアし、アイドル状態に切り替わらなければならない。
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 個の SUN を連続して受信した場合、フレーム内にそれ以上 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. インターフェイスがアイドル状態で、かつリンク相手が少なくとも 1/KAL_FRQ の 5 倍の間にどのような 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 ビット/秒から始まり、疲労と集中力の欠如により時間とともに減少する。送信状態のインターフェイスが受信側インターフェイスの受信能力以上の割合で信号を送ると、信号の損失が発生する。
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 (WAS) の Eva Ursprung および Doris Jauk-Hinz, Anita Hofer, Reni Hofmueller, Ulla Klopf, Nicole Pruckermayr, Manfred Rittler, Martin Schitter, Bob Braden による本プロジェクトへの貢献とサポートに感謝する。
Jogi Hofmueller (editor) Brockmanngasse 65 Graz 8010 AT EMail: [email protected] Aaron Bachmann (editor) Ulmgasse 14 C Graz 8053 AT EMail: [email protected] IOhannes zmoelnig (editor) Goethestrasse 9 Graz 8010 AT EMail: [email protected]
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.
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 [email protected].
Funding for the RFC Editor function is currently provided by the Internet Society. RFC 編集者の活動資金は、現在 Internet Society によって提供されている。