はじめに
- この文書は RFC4824 を勉強と好奇心のため適当に訳したものです。
- 翻訳の正確さは全く保証しません。
- 誤字誤訳等の指摘はいつでも大歓迎です。
The Transmission of IP Datagrams over the Semaphore Flag Signaling System (SFSS)
手旗信号システム(SFSS)によるIPデータグラムの伝送
- Network Working Group
- Request for Comments: 4824
- Category: Informational
- J. Hofmueller, Ed.
- A. Bachmann, Ed.
- I. Zmoelnig, Ed.
- 1 April 2007
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).
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(導入)
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 は1組の手旗を振る事により伝達される,英文による国際的な通信手段である [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.
インターネットプロトコル階層における SFSS の位置を図1に示す.
+-----+ +-----+ +-----+ | TCP | | UDP | ... | | Host Layer +-----+ +-----+ +-----+ | | | +-------------------------------+ | Internet Protocol & ICMP | Internet Layer +-------------------------------+ | +-------------------------------+ | SFSS | Link Layer +-------------------------------+ Figure 1: Protocol Relationships
図1:プロトコル関連図
2. Definitions(定義)
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つの旗のパターン(3.2章参照)
SFSS: The Semaphore Flag Signaling System.
SFSS:手旗信号システム
IP-SFS: IP over Semaphore Flag Signaling System.
IP-SFS:手旗信号システムで IP 伝送をすること.
3. Protocol Discussion(プロトコルについて)
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つのペアでオクテットを表す.
各々の信号パターンは SFS と呼ばれ,3.2章で定義する.
3.1. IP-SFS Frame(IP-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で送信され,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
注:各フィールドは,1つの SFS あるいは4ビットを表す.
図2:IP-SFS フレームフォーマット
FST: Frame Start control SFS
FST: フレームの開始を示す制御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.
Protocol: 4ビット -- インターネットレイヤープロトコルコード
- 0 無し
- 1 IPv4
- 2 IPv6.
- 3 gzip圧縮されたIPv4
- 4 gzip圧縮されたIPv6
- 5...15 将来使用のための予備
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.
CksumTyp: 4ビット -- チェックサムタイプ
- 0 なし
- 1 CCITT CRC 16 (多項式: x^16 + x^12 + x^5+1).
- 2...15 将来使用のための予備
Frame No: 8 bits (2 data SFSs):
Frame number for fragmented IP datagram.
Frame No: 8ビット(2つの SFS):分割されたIPデータグラムのフレーム番号
DATA: 0 to 510 data SFSs (Section 3.2.1) representing 0 to 255
octets of payload.
DATA: 0～510 個のデータSFS(3.2.1章参照)であり0～255オクテットのIPデータグラム本体.
CRC: 16 bits as four data SFSs.
CRC checksum. Preset to 0xFFFF. One's complement of checksum is transmitted.
CRC: 16ビット(4つのSFS).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 のデータ速度(ビット/秒)は,フレーム化のオーバーヘッドを考慮せず(Spm/60)*4 となる.
3.2. SFS Coding(SFSコード化)
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 エンコードを使用する.
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の文字に制御信号は,元の SFSS でQからXの文字に当たる.
3.2.1. IP-SFS Data Signals(IP-SFSデータ信号)
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.
図3:IP-SFS データ信号
3.2.2. IP-SFS Control Signals(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に挙げる.
示された図は受信者側から見た 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.
図4:IP-SFS 制御信号
FST: Frame STart. Signals the start of a new frame.
FST: Frame STart. 新しいフレームの開始.
FEN: Frame ENd. Signals the end of one frame.
FEN: Frame ENd. 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: Signal UNdo. 現在のフレーム内で一つ以上の個々の 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: Frame UNdo. FEN が送られない限り,送信者または受信者は現在のフレーム伝送を最初から送りなおすために FUN を送ることができる.受信者はこの信号を無視する.
ACK: Frame ACK. Acknowledges reception of one frame.
ACK: Frame 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: 接続を保持する.少なくとも KAL_FREQ (4.2章参照)の頻度で,待機状態を送る必要がある.この信号は無視される.
NAK: Frame No AcK. The frame received is incorrect.
NAK: Frame No AcK. 受信フレームは誤っている.
RTR: Ready To Receive. Receiver acknowledges it is ready to receive.
RTR: Ready To Receive. 受信者は受信準備が出来ている.
RTT: Ready To Transmit. Sender requests permission to initiate transmission.
RTT: Ready To Transmit. 送信者は伝送開始の許可を求める.
3.3. Protocol Limitations(プロトコルの制限)
Due to the physical characteristics of the transfer channel, bit error rates are expected to be in the range of 1e-3 (boy scout) to 1e-4 (professional sailor), and also depend a number of physical factors. Poor visibility due to weather conditions or lack of illumination (e.g., night time) can drastically increase the error rate.
転送チャンネルの物理的な特徴によりビット誤り率の範囲は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 は,フレームの再整理や重複受信を取り扱う方法を規定しない.
したがって,インターフェースが高速移動している場合,および/あるいは光の通り道が長い(訳注:両者の距離が離れている)などの環境ではこのプロトコルの適用は向いていない.
3.4. Implementation Limitations(実装上の制限)
Maximum payload per frame: 510 SFS (0...510) nibbles (0 to 255 octets)
1フレーム当たりの最大ペイロード:510 SFS (0～510) ニブル (0～255オクテット)
Maximum SFS per frame: 518
1フレーム当たりの最大 SFS :518
Maximum frames per session: 255 (0...254)
セッション当たりの最大フレーム数: 255 (0～254)
4. Interface Discussion(インタフェースについて)
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 によって補うことが可能である.
4.1. Data Link Control(データリンク制御)
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).
4.2. Establishing a Connection(接続の確立)
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 は,厳密に1対1の通信である.
インタフェースの構成員が互いを知らない限りインタフェースのなりすまし攻撃の可能性を減らすために通信前に簡単に両者の紹介をすることを提案する.
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 の有効な値は,一服するのに,あるいは水を一杯飲むのに必要な時間である.
交渉が失敗した場合には,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でなければならない.
4.3. State Idle(待機状態)
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 データグラムがある場合にはインタフェースはリンクパートナーに RTT を送ることによってセッションを始めようとするだろう.
リンクパートナーの受信準備ができている場合には,RTR 信号を返す.
4.4. Session Initiation(セッションの開始)
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 フレーム数を2つの 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.
環境雑音または大きな距離によって妨げられない限り,待機状態のリンクパートナーに対して叫ぶことで回線の秩序を守ることを要請することができます.
携帯電話の使用は自由に選択することができるがインタフェースに損害を与え,または破壊することがあるため,物を投げたり銃を使うことは推薦できない.
これは逆効果である.
4.5. State Transmitting(送信状態)
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.
もし間違ったデータを伝送してしまった場合,インタフェースは 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 のどちらを選ぶかはインタフェースが自由に選択することができるが,1つの 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 データグラムをキューに残したまま待機状態に切り替わる.
4.6. State Receiving(受信状態)
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.
2つの SFS の間の時間が TIMEOUT を上回るならば受信側インタフェースは実行中の IP-SFS フレームのすべてのデータを削除しなければならず,更に FUN を送ることができる.
リンクパートナーが第2の 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 を続けて受信した場合には,フレームにある最後の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 を送る.
4.7. Terminating a Connection
If the interface is in State Idle and the link partner did not
transmit any kind of SFS for at least five times 1/KAL_FRQ, the
connection is terminated and the interfaces are free to disband.
インタフェースが待機状態であり,リンクパートナーが少なくとも5回,1/KAL_FRQ の間にいかなる SFS も送らないならば,コネクションは切断され,インターフェースは解散することになる.
4.8. Further Remarks(その他)
Interfaces are connected to computer hardware by means of a suitable input device (RX) and a suitable output device (TX). Possible devices include keyboard, mouse, and monitor. Other means of connection are subject to availability and budget.
インタフェースは,適当な入力装置(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 のインタフェースを1人の人間で実現することも理論的に可能だがインタフェース毎に少なくとも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くらいで始まり,集中力の減退と欠如のために,時間とともに減少する.
送信中状態のインタフェースが RX インターフェースが受けることができるより高い率で信号を送るとき,信号の損失が起こる.
5. Security Considerations(セキュリティに関する考察)
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.
インタフェースを恒久的破壊するという方法以外に,現在,確実にインタフェースの記憶を削除する方法は知られていない.
6. Acknowledgements
We thank Eva Ursprung and Doris Jauk-Hinz from Womyn's Art Support
(WAS), Anita Hofer, Reni Hofmueller, Ulla Klopf, Nicole Pruckermayr,
Manfred Rittler, Martin Schitter, and Bob Braden for all their
contributions and support of this project.
7. References
[JCroft] Croft, J., "Semaphore Flag Signalling System",
http://www.anbg.gov.au/flags/semaphore.html.[Wikipedia] Wikipedia, "Modern semaphore", <http://
en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.
Authors' Addresses
Jogi Hofmueller (editor)
Brockmanngasse 65
Graz 8010
ATEMail: ip-sfs@mur.at
Aaron Bachmann (editor)
Ulmgasse 14 C
Graz 8053
ATEMail: ip-sfs@mur.at
Iohannes Zmoelnig (editor)
Goethestrasse 9
Graz 8010
ATEMail: ip-sfs@mur.at
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.