RFC4824 日本語訳
4824 The Transmission of IP Datagrams over the Semaphore FlagSignaling System (SFSS). J. Hofmueller, Ed., A. Bachmann, Ed., IO.zmoelnig, Ed.. April 1 2007. (Format: TXT=25521 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Hofmueller, Ed.
Request for Comments: 4824 A. Bachmann, Ed.
Category: Informational IO. zmoelnig, Ed.
1 April 2007
ワーキンググループJ.Hofmueller、エドをネットワークでつないでください。コメントのために以下を要求してください。 4824 エドA.バッハマン、カテゴリ: 情報のIO. zmoelnig、エド、2007年4月1日
The Transmission of IP Datagrams
over the Semaphore Flag Signaling System (SFSS)
腕木信号機手旗信号システムの上のIPデータグラムの送信(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).
IETFが信じる著作権(C)(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. 序論…2 2. 定義…2 3. 議論について議定書の中で述べてください…3 3.1. IP-SFSは記述を縁どっています…3 3.2. SFSコード化…4 3.3. IP-SFSデータは合図します…5 3.4. IP-SFSは信号を制御します…6 3.5. 制限について議定書の中で述べてください…7 3.6. 実現制限…7 4. 議論を連結してください…7 4.1. データリンク制御…8 4.2. 取引関係を築きます…8 4.3. 怠けるように述べてください…8 4.4. セッション開始…8 4.5. 伝えることを述べてください…9 4.6. 受信を述べてください…10 4.7. 接続を終えます…11 4.8. さらなる所見…11 5. セキュリティ問題…11 6. 承認…11 7. 参照…12
Hofmueller, et al. Informational [Page 1] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[1ページ]のRFC4824IP
1. Introduction
1. 序論
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)の上でIP-SFS、IPv4/IPv6パケットのカプセル化とトランスミッションのための方法を指定します。 SFSSは1組の携帯用の旗[JCroft、ウィキぺディア]の振りであることに基づく国際的に認識されたアルファベット通信系です。 Semaphore Flag Signal(SFS)は、SFSSの下では、それぞれの英字か制御信号が特定の旗のパターンによって示されると呼びました。
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
+-------------------------------+
+-----+ +-----+ +-----+ | TCP| | UDP| ... | | ホスト層+-----+ +-----+ +-----+ | | | +-------------------------------+ | インターネットプロトコルとICMP| インターネット層+-------------------------------+ | +-------------------------------+ | SFSS| リンクレイヤ+-------------------------------+
Figure 1: Protocol Relationships
図1: プロトコル関係
2. Definitions
2. 定義
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データグラムのトランスミッション。
Hofmueller, et al. Informational [Page 2] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[2ページ]のRFC4824IP
SFS: One Semaphore Flag Signal, i.e., one flag pattern (Section
3.2).
SFS: すなわち、1Semaphore Flag Signal、1つの旗のパターン(セクション3.2)。
SFSS: The Semaphore Flag Signaling System.
SFSS: 腕木信号機手旗信号システム。
IP-SFS: IP over Semaphore Flag Signaling System.
IP-SFS: 腕木信号機手旗信号システムの上のIP。
3. Protocol Discussion
3. プロトコル議論
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は、コントロール機能(セクション3.2.2)を表すためにデータ値0-15(セクション3.2.1)と9つの信号を表すために16の信号(旗のパターン)のアルファベットをコード化するために標準のSFSSを適合させます。 16のデータ信号で、IP-SFSトランスミッションは4ビットの少量、1八重奏あたり2に基づいています。 セクション3.2で定義されたそれぞれのシグナル・パターンはSFSと呼ばれます。
3.1. IP-SFS Frame Description
3.1. 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は1個のIP-SFSフレームの書式を示しています。 フレームはFSTと呼ばれるコントロールSFS(フレームStart)とFENと呼ばれるコントロールSFS(フレームEnd)によって区切られます。 それは一連の4ビットの少量、1SFSあたり1つで構成されます。
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がある2番目…, そして、フレーム番号0がある最終。
0 1 2 3
+--------+--------+--------+--------+--------+
| FST |Protocol|CksumTyp|Frame No|Frame No|
+--------+--------+--------+--------+--------+
| |
// DATA Payload //
| |
+--------+--------+--------+--------+---------+
| CRC | CRC | CRC | CRC | FEN |
+--------+--------+--------+--------+---------+
0 1 2 3 +--------+--------+--------+--------+--------+ | FST|プロトコル|CksumTyp|フレームノー|フレームノー| +--------+--------+--------+--------+--------+ | | //データ有効搭載量//| | +--------+--------+--------+--------+---------+ | CRC| CRC| CRC| CRC| 沼沢地| +--------+--------+--------+--------+---------+
Note that each field represents one SFS or 4 bits.
各分野が1SFSか4ビットを表すことに注意してください。
Figure 2: IP-SFS Frame Format
図2: IP-SFSフレーム形式
FST: Frame Start control SFS
FST: フレームStartコントロールSFS
Hofmueller, et al. Informational [Page 3] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[3ページ]のRFC4824IP
Protocol: 4 bits -- Internetwork-layer protocol code
プロトコル: 4ビット--インターネットワーク層のプロトコルコード
0 None.
0 なし。
1 For IPv4.
1 IPv4のために。
2 For IPv6.
2 IPv6のために。
3 For IPv4 frame gzip-compressed.
3 gzipによってIPv4フレームに圧縮されています。
4 For IPv6 frame gzip-compressed.
4 gzipによってIPv6フレームに圧縮されています。
5...15 Reserved for future use.
5...15 今後の使用のために、予約されます。
CksumTyp: 4 bits (one data SFS) -- Checksum Type
CksumTyp: 4ビット(1データSFS)--チェックサムType
0 none.
0 なし。
1 CCITT CRC 16 (polynomial: x^16 + x^12 + x^5+1).
1 CCITT CRC16(多項式: 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〜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.
沼沢地: フレームENdは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.
(Spm)が参加する経験による1分あたりの伝えられたSFSsの数は連結します。 IP-SFSのためのbpsにおける結果として起こるリンク速度はオーバーヘッドを縁どりながら数えるのではなく、(Spm/60)*4です。
3.2. SFS Coding
3.2. 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コード化であることに基づいています、[JCroft]、[ウィキぺディア]、およびインターネットの他のソースによって説明されるように。 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はSFSS encodingsのQからXによって表された手紙のAからPと9つの制御信号のためにオリジナルのSFSS encodingsで16のデータ信号を定義します。
Hofmueller, et al. Informational [Page 4] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[4ページ]のRFC4824IP
3.3. IP-SFS Data Signals
3.3. 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はデータフレームをリンクの上に伝えるのに使用される16SFSsを例証します。 イラストは、受信から見られる各SFSは面があるのを示します。
SFS 0 __0 %%BODY%% |0
/|| || || ||
/ \ / \ / \ / \
A B C D
IP-SFS 0x00 0x01 0x02 0x03
SFS0__0円0|0 /|| || || || /\/\/\/\はB C D IP-SFS0x00 0x01 0x02 0×03です。
-----------------------------------------
-----------------------------------------
SFS 0/ 0__ 0 __0
|| || ||\ /|
/ \ / \ / \ / \
E F G H
IP-SFS 0x04 0x05 0x06 0x07
SFS0/ 0__0__0|| || ||\ /| F G H IP-SFS0x04 0x05 0x06 0×07/\/\/\/\E
-----------------------------------------
-----------------------------------------
SFS %%BODY%% |0__ 0| 0/
/| | /| /|
/ \ / \ / \ / \
I J K L
IP-SFS 0x08 0x09 0x0A 0x0B
SFS0円|0__ 0| 0/ /| | /| /| /\/\/\/\I J K L IP-SFS0x08 0×09 0x0A 0x0B
-----------------------------------------
-----------------------------------------
SFS 0__ 0 _%%BODY%% __0|
/| /|\ | |
/ \ / \ / \ / \
M N O P
IP-SFS 0x0C 0x0D 0x0E 0x0F
SFS0__0_%%BODY%%__0| /| /|\ | | ○ /\/\/\/\M N P IP-SFS 0x0C 0x0D 0x0E 0x0F
Figure 3: IP-SFS Data Signals.
図3: IP-SFSデータは合図します。
Hofmueller, et al. Informational [Page 5] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[5ページ]のRFC4824IP
3.4. IP-SFS Control Signals
3.4. 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 %%BODY%%|
| | |\ |
/ \ / \ / \ / \
Q R S T
IP-SFS FST FEN SUN FUN
SFS__0/__0__ __0円0| | | |\ | /\/\/\/\Q R S T IP-SFS FST沼沢地太陽楽しみ
-----------------------------------------
-----------------------------------------
SFS %%BODY%%/ %%BODY%%__ 0/_ 0/
| | | |\
/ \ / \ / \ / \
U V W X
IP-SFS ACK KAL NAK RTR
SFS0__0/_0 0/円円/| | | |\/\/\/\/\U V W X IP-SFS ACK KAL NAK RTR
-----------------------------------------
-----------------------------------------
SFS 0__ 0__
/| |\
/ \ / \
Y Z
IP-SFS RTT unused
SFS0__0__/| |\/\/\Y Z IP-SFS RTT未使用です。
-----------------------------------------
-----------------------------------------
SFS _%%BODY%%/_
/|\
/ \
Error
IP-SFS unused
SFS_%%BODY%%/_/|\/\誤り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.
沼沢地: 終わりを縁どってください。 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個々のSFSsのトランスミッションを中止します。 この信号は受信機で認められないでしょう。
Hofmueller, et al. Informational [Page 6] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[6ページ]のRFC4824IP
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.
楽しみ: アンドゥを縁どってください。 Frame ENdが送られない限り、送信機か受信機が、現在のフレームのトランスミッションを再開するために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: KeepALive。 接続を生かしてください。 州Idleで少なくとも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: 伝わる準備ができています。 送付者はトランスミッションを開始する許可を要求します。
3.5. Protocol Limitations
3.5. プロトコル制限
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はフレーム再命令か二元的な(複数の)フレームレセプションを扱う手段を全く提供しません。 光の経路が速さ長いときに、したがって、プロトコルはインタフェースが動いているところで環境で適当ではありません。
3.6. Implementation Limitations
3.6. 実現制限
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)
1セッションあたりの最大のフレーム: 255 (0...254)
4. Interface Discussion
4. インタフェース議論
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は不在を埋め合わせることができます。
Hofmueller, et al. Informational [Page 7] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[7ページ]のRFC4824IP
4.1. Data Link Control
4.1. データリンク制御
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).
インタフェースは3Statesを知っています: (テキサス)を送信して、(RX)を受けて、怠けてください。
4.2. Establishing a Connection
4.2. 取引関係を築きます。
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に、可能な値は、わざわざそれがタバコを吸うわざわざですそれが1杯の水を飲む。 交渉が失敗するなら、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
4.3. 怠けるように述べてください。
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.
州Idleのインタフェースは、ローカルの上位レベル・プロトコルによって提供されたIPデータグラムを送る準備ができているか、またはリンクパートナーからデータグラムを受け取る準備ができているに違いありません。 Idleが送らなければならない州におけるインタフェースは少なくとも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.
州Idleのための定義がこれ以上ありませんが、私たちは、増加する数の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信号を返します。
4.4. Session Initiation
4.4. セッション開始
An interface receiving a datagram from an Internet layer protocol level may start signaling RTT.
インターネット層プロトコルレベルからデータグラムを受けるインタフェースは、RTTに合図し始めるかもしれません。
Hofmueller, et al. Informational [Page 8] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[8ページ]のRFC4824IP
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と共にTIMEOUTの中で応じないか、またはリンクパートナーがRTTと共に応じるなら、インタフェースは無作為の期間の間、2秒とTIMEOUTの間で州Idleに切り替わります、RTTを再送する前に。
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を伝えるなら、インタフェースは、2SFSsが別のRTTで続いたのでこのセッションのときに伝えられるためにIP-SFSフレームの数を伝えます。 リンクパートナーが3*TIMEOUTの中でRTRによって続かれた同じ数のIP-SFSフレームを伝えないなら、インタフェースは州Idleに切り替わります。
If the link partner transmits the same number of IP-SFS frames followed by RTR, the interface switches to State Transmitting.
リンクパートナーがRTRによって続かれた同じ数のIP-SFSフレームを伝えるなら、インタフェースは州Transmittingに切り替わります。
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.
環境騒音か長い距離を通して妨げられない場合、リンクパートナーから州Idleで線規律を要求するのに大声を使用できます。 また、携帯電話の使用はオプションですが、スローイング・オブジェクトか銃を使用するのが推薦されません、インタフェース損害か破壊をもたらすかもしれないので。 これは反生産的でしょう。
4.5. State Transmitting
4.5. 州の伝えること
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.
それは独身の無効のSFSにSUNを使用するために勧められます、そして、インタフェースがエラー修正のためのSUNかFUNを選ぶかどうかが、インタフェース次第ですが、インタフェースが伝えなかったときはいつも、FUNは並んでいる数個のSFSsを伝えます。
After FEN has been transmitted, the transmitting interface waits for the link partner to transmit ACK or NAK.
FENが伝えられた後に、伝えるインタフェースは、リンクパートナーがACKかNAKを伝えるのを待っています。
Hofmueller, et al. Informational [Page 9] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[9ページ]のRFC4824IP
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フレームを伝え始めます。 どんなフレームもそうでないなら、左では、インタフェースは州Idleに切り替わります。
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データグラムをIdleに残します。
4.6. State Receiving
4.6. 州の受信
In State Receiving, the interface stores each SFS received from the link partner in the receiving queue in the order of appearance.
州Receivingでは、インタフェースはリンクパートナーから外観の注文における受信待ち行列で受け取られた各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.
2容認されたSFSsの間の時間がTIMEOUTを超えているなら、受信インタフェースは、アクティブなIP-SFSフレームからのすべてのデータを捨てなければならなくて、さらに、FUNを伝えるかもしれません。 リンクパートナーが、2番目のTIMEOUTの期間以内に伝わり続けていないなら、インタフェースは受信待ち行列とスイッチを州Idleにきれいにしなければなりません。
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を並んで受け取るなら、最後のNデータSFSを捨てなければなりません、それ以上のデータ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を伝えます。 アクティブなフレームのFrame Numberが0歳であるなら、インタフェースは、州Idleに受信待ち行列から、より高い平らなプロトコルまで全体のデータを通過して、受信待ち行列をクリアして、切り替わります。
If the checksum is incorrect, the interface transmits NAK.
チェックサムが不正確であるなら、インタフェースはNAKを伝えます。
Hofmueller, et al. Informational [Page 10] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[10ページ]のRFC4824IP
4.7. Terminating a Connection
4.7. 接続を終えます。
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.
インタフェースが州Idleにあって、リンクパートナーが少なくとも5回の1/KAL_FRQのためにどんな種類のSFSも伝えなかったなら、接続は終えられます、そして、インタフェースは自由に解散できます。
4.8. Further Remarks
4.8. さらなる所見
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)と適当な出力装置(テキサス)によってコンピュータ・ハードウェアに接続されます。 可能な装置はキーボード、マウス、およびモニターを含んでいます。 接続の他の手段は有用性と予算を受けることがあります。
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人の人間でインタフェースのテキサスと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.
帯域幅は、異なる傾向があります。 テキサスは、通常、およそ2-4ビット/sで始まって、時間がたつにつれて、疲労困憊と集中力欠如のため減少するでしょう。 テキサス州におけるインタフェースがRXインタフェースより高いレートで受信できる状態で合図するとき、信号損失は起こります。
5. Security Considerations
5. セキュリティ問題
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
6. 承認
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のArt Support(あった)、アニタ・ホーファー、レニHofmueller、ウラKlopf、ニコルPruckermayr、マンフレッドRittler、マーチンSchitter、およびボブ・ブレーデンからエバ・ウルシュプルングとドリス・Jauk-ヒンズに感謝します。
Hofmueller, et al. Informational [Page 11] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[11ページ]のRFC4824IP
7. References
7. 参照
[JCroft] Croft, J., "Semaphore Flag Signalling System",
<http://www.anbg.gov.au/flags/semaphore.html>.
[JCroft] 耕地、J.、「腕木信号機旗の合図システム」、<http://www.anbg.gov.au/旗/semaphore.html>。
[Wikipedia] Wikipedia, "Modern semaphore", <http://
en.wikipedia.org/wiki/Semaphore#Modern_semaphore>.
[ウィキぺディア]ウィキぺディア、「近代的な腕木信号機」、<http://en.wikipedia.org/wiki/腕木信号機#Modern_は>を信号で知らせます。
Authors' Addresses
作者のアドレス
Jogi Hofmueller (editor) Brockmanngasse 65 Graz 8010 AT
Jogi Hofmueller(エディタ)Brockmanngasse65グラーツ8010
EMail: ip-sfs@mur.at
メール: ip-sfs@mur.at
Aaron Bachmann (editor) Ulmgasse 14 C Graz 8053 AT
アーロンバッハマン(エディタ)Ulmgasse14Cグラーツ8053
EMail: ip-sfs@mur.at
メール: ip-sfs@mur.at
IOhannes zmoelnig (editor) Goethestrasse 9 Graz 8010 AT
IOhannes zmoelnig(エディタ)Goethestrasse9グラーツ8010AT
EMail: ip-sfs@mur.at
メール: ip-sfs@mur.at
Hofmueller, et al. Informational [Page 12] RFC 4824 IP over SFSS April 2007
Hofmueller、他 SFSS2007年4月の上の情報[12ページ]のRFC4824IP
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Hofmueller, et al. Informational [Page 13]
Hofmueller、他 情報[13ページ]
一覧
スポンサーリンク
