[要約] RFC 3081は、BEEP CoreプロトコルをTCPにマッピングするためのガイドラインです。このRFCの目的は、BEEP CoreをTCP上で効果的に実装するための手順と要件を提供することです。
Network Working Group M. Rose
Request for Comments: 3081 Invisible Worlds, Inc.
Category: Standards Track March 2001
Mapping the BEEP Core onto TCP
ビープコアをTCPにマッピングします
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This memo describes how a BEEP (Blocks Extensible Exchange Protocol) session is mapped onto a single TCP (Transmission Control Protocol) connection.
このメモは、ビープ音（ブロック拡張可能な交換プロトコル）セッションが単一のTCP（伝送制御プロトコル）接続にどのようにマッピングされるかについて説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Session Management . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2 Sending Messages . . . . . . . . . . . . . . . . . . . . . . 3
3.1.3 Processing SEQ Frames . . . . . . . . . . . . . . . . . . . 4
3.1.4 Use of Flow Control . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
This memo describes how a BEEP [1] session is mapped onto a single TCP [2] connection. Refer to Section 2.5 of [1] for an explanation of the mapping requirements.
このメモでは、ビープ音[1]セッションが単一のTCP [2]接続にどのようにマッピングされるかについて説明します。マッピング要件の説明については、[1]のセクション2.5を参照してください。
The mapping of BEEP session management onto the TCP service is straight-forward.
TCPサービスへのビープセッション管理のマッピングは簡単です。
A BEEP session is established when a TCP connection is established between two BEEP peers:
ビープセッションは、2つのビープピア間にTCP接続が確立されたときに確立されます。
o the BEEP peer that issues a passive TCP OPEN call is termed the listener; and,
o 受動的なTCPオープンコールを発行するビープピアは、リスナーと呼ばれます。そして、
o the BEEP peer that issues an active TCP OPEN call is termed the initiator.
o アクティブなTCPオープンコールを発行するビープピアは、イニシエーターと呼ばれます。
A simultaneous TCP OPEN would result in both BEEP peers believing they are the initiator and neither peer will be able to start any channels. Because of this, services based on BEEP must be designed so that simultaneous TCP OPENs cannot occur.
同時にTCPを開いていると、両方のビープピアがイニシエーターであると信じており、どちらのピアもチャンネルを開始することはできません。このため、BEEPに基づくサービスは、同時のTCPオープンが発生できないように設計する必要があります。
If both peers agree to release a BEEP session (c.f., [1]'s Section 2.4), the peer sending the "ok" reply, immediately issues the TCP CLOSE call. Upon receiving the reply, the other peer immediately issues the TCP CLOSE call.
両方のピアがビープ音セッション（C.F.、[1]のセクション2.4）をリリースすることに同意した場合、ピアは「OK」返信を送信すると、すぐにTCPクローズコールを発行します。返信を受け取ると、他のピアはすぐにTCPクローズコールを発行します。
A BEEP session is terminated when either peer issues the TCP ABORT call, and the TCP connection is subsequently aborted.
Beepセッションは、ピアがTCP中止呼び出しを発行し、TCP接続がその後中止されると終了します。
The mapping of BEEP exchanges onto the TCP service is less straight-forward.
TCPサービスへのビープ交換のマッピングは、それほど簡単ではありません。
Messages are reliably sent and received using TCP's SEND and RECEIVE calls. (This also provides ordered delivery of messages on the same channel.)
メッセージは、TCPの送信および受信コールを使用して確実に送信および受信されます。（これは、同じチャネルでのメッセージの順序付けられた配信も提供します。）
Although TCP imposes flow control on a per-connection basis, if multiple channels are simultaneously in use on a BEEP session, BEEP must provide a mechanism to avoid starvation and deadlock. To achieve this, BEEP re-introduces a mechanism used by the TCP: window-based flow control -- each channel has a sliding window that indicates the number of payload octets that a peer may transmit before receiving further permission.
TCPは接続ごとにフロー制御を課しますが、複数のチャネルがビープセッションで同時に使用されている場合、ビープ音は飢vやデッドロックを避けるためのメカニズムを提供する必要があります。これを実現するために、ビープ音はTCP：ウィンドウベースのフロー制御で使用されるメカニズムを再導入します - 各チャネルには、さらに許可を受ける前にピアが送信する可能性のあるペイロードオクテットの数を示すスライディングウィンドウがあります。
Recall from Section 2.2.1.2 of [1] that every payload octet sent in each direction on a channel has an associated sequence number. Numbering of payload octets within a data frame is such that the first payload octet is the lowest numbered, and the following payload octets are numbered consecutively.
[1]のセクション2.2.1.2から、チャネル上で各方向に送信されるすべてのペイロードオクテットに関連するシーケンス番号があることを思い出してください。データフレーム内のペイロードオクテットの番号付けは、最初のペイロードオクテットが最も少ない番号であり、次のペイロードオクテットに連続して番号が付けられているようなものです。
The actual sequence number space is finite, though very large, ranging from 0..4294967295 (2**32 - 1). Since the space is finite, all arithmetic dealing with sequence numbers is performed modulo 2**32. This unsigned arithmetic preserves the relationship of sequence numbers as they cycle from 2**32 - 1 to 0 again. Consult Sections 2 through 5 of [3] for a discussion of the arithmetic properties of sequence numbers.
実際のシーケンス番号スペースは有限ですが、非常に大きく、0..4294967295（2 ** 32-1）の範囲です。スペースは有限であるため、シーケンス番号を扱うすべての算術的な算術は、モジュロ2 ** 32を実行します。この署名されていない算術は、2 ** 32-1から0に再びサイクリングする際のシーケンス番号の関係を保持します。シーケンス番号の算術特性の議論については、[3]のセクション2〜5を参照してください。
When a channel is created, the sequence number associated with the first payload octet of the first data frame is 0, and the initial window size for that channel is 4096 octets. After channel creation, a BEEP peer may update the window size by sending a SEQ frame (Section 3.1.3).
チャネルが作成されると、最初のデータフレームの最初のペイロードオクテットに関連付けられたシーケンス番号は0、そのチャネルの初期ウィンドウサイズは4096オクテットです。チャネル作成後、ビープピアは、配列フレームを送信してウィンドウサイズを更新できます（セクション3.1.3）。
If a BEEP peer is asked to create a channel and it is unable to allocate at least 4096 octets for that channel, it must decline creation of the channel, as specified in Section 2.3.1.2 of [1]. Similarly, during establishment of the BEEP session, if the BEEP peer acting in the listening role is unable to allocate at least 4096 octets for channel 0, then it must return a negative reply, as specified in Section 2.4 of [1], instead of a greeting.
ビープピアがチャネルを作成するように求められ、そのチャネルに少なくとも4096オクテットを割り当てることができない場合、[1]のセクション2.3.1.2で指定されているように、チャネルの作成を拒否する必要があります。同様に、ビープセッションの確立中に、リスニングロールで行動するビープピアがチャネル0に少なくとも4096オクテットを割り当てることができない場合、[1]のセクション2.4で指定されているように、否定的な応答を返す必要があります。挨拶。
Before a message is sent, the sending BEEP peer must ensure that the size of the payload is within the window advertised by the receiving BEEP peer. If not, it has three choices:
メッセージが送信される前に、送信ビープピアは、ペイロードのサイズが受信ビープピアによって宣伝されているウィンドウ内にあることを確認する必要があります。そうでない場合、3つの選択肢があります。
o if the window would allow for at least one payload octet to be sent, the BEEP peer may segment the message and start by sending a smaller data frame (up to the size of the remaining window);
o ウィンドウが少なくとも1つのペイロードオクテットを送信できる場合、ビープピアはメッセージをセグメント化し、より小さなデータフレーム（残りのウィンドウのサイズまで）を送信することから始めることができます。
o the BEEP peer may delay sending the message until the window becomes larger; or,
o ビープピアは、ウィンドウが大きくなるまでメッセージの送信を遅らせる可能性があります。または、
o the BEEP peer may signal to its application that it is unable to send the message, allowing the application to try again at a later time (or perhaps signaling its application when a larger window is available).
o ビープピアは、メッセージを送信できないことをアプリケーションに合図する場合があり、後でアプリケーションを再試行できるようにします（または、おそらく大きなウィンドウが利用可能なときにアプリケーションを通知する可能性があります）。
The choice is implementation-dependent, although it is recommended that the application using BEEP be given a mechanism for influencing the decision.
選択は実装依存ですが、ビープ音を使用したアプリケーションに決定に影響を与えるメカニズムを与えることをお勧めします。
As an application accepts responsibility for incoming data frames, its BEEP peer should send SEQ frames to advertise a new window.
アプリケーションは着信データフレームの責任を受け入れるため、そのビープピアは新しいウィンドウを宣伝するために配列フレームを送信する必要があります。
The ABNF [4] for a SEQ frame is:
seqフレームのabnf [4]は次のとおりです。
seq = "SEQ" SP channel SP ackno SP window CR LF
seq = "seq" spチャネルsp ackno sp window cr lf
ackno = seqno
window = size
; channel, seqno, and size are defined in Section 2.2.1 of [1].
;チャネル、Seqno、およびサイズは、[1]のセクション2.2.1で定義されています。
The SEQ frame has three parameters:
SEQフレームには3つのパラメーターがあります。
o a channel number;
o チャネル番号。
o an acknowledgement number, that indicates the value of the next sequence number that the sender is expecting to receive on this channel; and,
o 確認者は、送信者がこのチャネルで受け取ると予想している次のシーケンス番号の値を示します。そして、
o a window size, that indicates the number of payload octets beginning with the one indicated by the acknowledgement number that the sender is expecting to receive on this channel.
o ウィンドウサイズは、送信者がこのチャネルで受け取ることを期待している確認番号で示されたものから始まるペイロードオクテットの数を示します。
A single space character (decimal code 32, " ") separates each component. The SEQ frame is terminated with a CRLF pair.
単一のスペース文字（10進コード32 ""）が各コンポーネントを分離します。SEQフレームはCRLFペアで終了します。
When a SEQ frame is received, if any of the channel number, acknowledgement number, or window size cannot be determined or is invalid, then the BEEP session is terminated without generating a response, and it is recommended that a diagnostic entry be logged.
SEQフレームが受信された場合、チャネル番号、確認番号、またはウィンドウサイズを決定できない場合、または無効な場合、ビープセッションは応答を生成せずに終了し、診断エントリを記録することをお勧めします。
The key to successful use of flow control within BEEP is to balance performance and fairness: o large messages should be segmented into frames no larger than two-thirds of TCP's negotiated maximum segment size;
ビープ音でフロー制御を成功させるための鍵は、パフォーマンスと公平性のバランスをとることです。o大きなメッセージは、TCPの最大セグメントサイズの3分の2以下のフレームにセグメント化する必要があります。
o frames for different channels with traffic ready to send should be sent in a round-robin fashion;
o 送信できるトラフィックを備えたさまざまなチャネルのフレームは、ラウンドロビンファッションで送信する必要があります。
o each time a frame is received, a SEQ frame should be sent whenever the window size that will be sent is at least one half of the buffer space available to this channel; and,
o フレームが受信されるたびに、送信されるウィンドウサイズがこのチャネルで使用可能なバッファースペースの少なくとも半分があるときはいつでも、SEQフレームを送信する必要があります。そして、
o if the transport service presents multiple frames to a BEEP peer simultaneously, then a single consolidating SEQ frame may be sent.
o 輸送サービスが複数のフレームをビープ音のピアに同時に提示する場合、単一の統合された配列フレームを送信できます。
In order to avoid pathological interactions with the transport service, it is important that a BEEP peer advertise windows based on available buffer space, to allow data to be read from the transport service as soon as available. Further, SEQ frames for a channel must have higher priority than messages for that channel.
輸送サービスとの病理学的相互作用を回避するために、ビープ音が利用可能なバッファースペースに基づいてウィンドウを宣伝し、利用可能な限りすぐに輸送サービスからデータを読み取ることが重要です。さらに、チャネルのSEQフレームは、そのチャネルのメッセージよりも優先度が高い必要があります。
Implementations may wish to provide queue management facilities to the application using BEEP, e.g., channel priorities, (relative) buffer allocations, and so on. In particular, implementations should not allow a given channel to monopolize the underlying transport window (e.g., slow readers should get small windows).
実装は、ビープ音、チャネル優先順位、（相対的な）バッファの割り当てなどを使用して、キュー管理施設をアプリケーションに提供することをお勧めします。特に、実装は、特定のチャネルが基礎となる輸送ウィンドウを独占することを許可してはなりません（たとえば、遅い読者は小さなウィンドウを取得する必要があります）。
In addition, where possible, implementations should support transport layer APIs that convey congestion information. These APIs allow an implementation to determine its share of the available bandwidth, and also be notified of changes in the estimated path bandwidth. Note that when a BEEP session has multiple channels that are simultaneously exchanging large messages, implementations without access to this information may have uncertain fairness and progress properties during times of network congestion.
さらに、可能であれば、実装は輻輳情報を伝える輸送層APIをサポートする必要があります。これらのAPIにより、実装が利用可能な帯域幅のシェアを決定し、推定パス帯域幅の変更についても通知できます。ビープセッションには、大きなメッセージを交換する複数のチャネルがある場合、この情報にアクセスすることなく実装がネットワークの輻輳時に不確実な公平性と進捗特性がある可能性があることに注意してください。
Finally, implementors should follow the guidelines given in the relevant portions of RFC1122 [5] that deal with flow control (and bear in mind that issues such as retransmission, while they interact with flow control in TCP, are not applicable to this memo). For example, Section 4.2.2.16 of RFC1122 [5] indicates that a "receiver SHOULD NOT shrink the window, i.e., move the right window edge to the left" and then discusses the impact of this rule on unacknowledged data. In the context of mapping BEEP onto a single TCP connection, only the portions concerning flow control should be implemented.
最後に、実装者は、フロー制御を扱うRFC1122 [5]の関連部分に与えられたガイドラインに従う必要があります（およびTCPのフロー制御と相互作用しながら、再送信などの問題はこのメモには適用されないことに留意してください）。たとえば、RFC1122 [5]のセクション4.2.2.16は、「受信者はウィンドウを縮小してはならない、つまり右のウィンドウの端を左に移動する」ことを示し、次に、未把握データに対するこのルールの影響について説明します。ビープ音を単一のTCP接続にマッピングするコンテキストでは、フロー制御に関する部分のみを実装する必要があります。
Consult Section [1]'s Section 9 for a discussion of security issues.
セキュリティ問題の議論については、セクション[1]のセクション9を参照してください。
References
参考文献
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[1] Rose、M。、「ブロック拡張可能な交換プロトコルコア」、RFC 3080、2001年3月。
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[2] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, August 1996.
[3] Elz、R。およびR. Bush、「シリアル番号算術」、RFC 1982、1996年8月。
[4] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[5] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[5] Braden、R。、「インターネットホストの要件 - 通信レイヤー」、STD 3、RFC 1122、1989年10月。
Author's Address
著者の連絡先
Marshall T. Rose Invisible Worlds, Inc. 1179 North McDowell Boulevard Petaluma, CA 94954-6559 US
マーシャルT.ローズInvisible Worlds、Inc。1179 North McDowell Boulevard Petaluma、CA 94954-6559 US
Phone: +1 707 789 3700
EMail: mrose@invisible.net
URI: http://invisible.net/
The author gratefully acknowledges the contributions of: Dave Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge, Vernon Schryver, and, Joe Touch. In particular, Dave Crocker provided helpful suggestions on the nature of flow control in the mapping.
著者は、Dave Crocker、Steve Harris、Eliot Lear、Keith McCloghrie、Craig Partridge、Vernon Schryver、およびJoe Touchの貢献に感謝して認めています。特に、デイブ・クロッカーは、マッピングにおけるフロー制御の性質について有益な提案を提供しました。
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。