RFC3259 日本語訳
3259 A Message Bus for Local Coordination. J. Ott, C. Perkins, D.Kutscher. April 2002. (Format: TXT=84125 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Ott
Request for Comments: 3259 TZI, Universitaet Bremen
Category: Informational C. Perkins
USC Information Sciences Institute
D. Kutscher
TZI, Universitaet Bremen
April 2002
コメントを求めるワーキンググループJ.オットの要求をネットワークでつないでください: 3259年のTZI、Universitaetブレーメンカテゴリ: 情報のC.パーキンスUSC情報科学研究所D.クッチャーTZI、Universitaetブレーメン2002年4月
A Message Bus for Local Coordination
地元調整のためのメッセージバス
Status of this Memo
この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 Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
The local Message Bus (Mbus) is a light-weight message-oriented coordination protocol for group communication between application components. The Mbus provides automatic location of communication peers, subject based addressing, reliable message transfer and different types of communication schemes. The protocol is layered on top of IP multicast and is specified for IPv4 and IPv6. The IP multicast scope is limited to link-local multicast. This document specifies the Mbus protocol, i.e., message syntax, addressing and transport mechanisms.
地方のMessage Bus(Mbus)はアプリケーション構成要素のグループコミュニケーションのための軽量のメッセージ指向のコーディネートプロトコルです。 Mbusはコミュニケーション同輩、対象のベースのアドレシング、信頼できるメッセージ転送、および異なったタイプのコミュニケーション計画の自動位置を提供します。 プロトコルは、IPマルチキャストの上で層にされて、IPv4とIPv6に指定されます。 IPマルチキャスト範囲はリンク地方のマルチキャストに制限されます。 このドキュメントがMbusプロトコルを指定して、すなわち、メッセージは、構文と、アドレシングと移送機構です。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Mbus Overview . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Purpose of this Document . . . . . . . . . . . . . . . . . . 5 1.3 Areas of Application . . . . . . . . . . . . . . . . . . . . 5 1.4 Terminology for requirement specifications . . . . . . . . . 6 2. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 6 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 10 5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 11 5.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 12
1. 要件仕様. . . . . . . . . 6 2のためのApplication. . . . . . . . . . . . . . . . . . . . 5 1.4TerminologyのこのDocument. . . . . . . . . . . . . . . . . . 5 1.3Areasの序論. . . . . . . . . . . . . . . . . . . . . . . . 3 1.1Mbus Overview. . . . . . . . . . . . . . . . . . . . . . . 3 1.2Purpose。 一般的な正式なシンタックス・ルール. . . . . . . . . . . . . . . . . 6 3。 メッセージ・フォーマット. . . . . . . . . . . . . . . . . . . . . . . 7 4。 .94.1個の義務的なアドレス要素. . . . . . . . . . . . . . . . . 10 5を記述します。 メッセージ構文. . . . . . . . . . . . . . . . . . . . . . . 11 5.1メッセージコード化. . . . . . . . . . . . . . . . . . . . . . 11 5.2メッセージヘッダー.115.3コマンド構文. . . . . . . . . . . . . . . . . . . . . . . 12
Ott, et. al. Informational [Page 1] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[1ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 14
6.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 15
6.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 15
6.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 16
6.1.4 Mbus UDP Port Number . . . . . . . . . . . . . . . . . . . . 16
6.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 16
7. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Awareness of other Entities . . . . . . . . . . . . . . . . 20
8.1 Hello Message Transmission Interval . . . . . . . . . . . . 21
8.1.1 Calculating the Interval for Hello Messages . . . . . . . . 22
8.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 23
8.1.3 Adjusting the Hello Message Interval when the Number of
Entities increases . . . . . . . . . . . . . . . . . . . . . 23
8.1.4 Adjusting the Hello Message Interval when the Number of
Entities decreases . . . . . . . . . . . . . . . . . . . . . 23
8.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 23
8.2 Calculating the Timeout for Mbus Entities . . . . . . . . . 24
9. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 25
9.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 26
9.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 27
11. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 28
11.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 28
11.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.3 Message Authentication . . . . . . . . . . . . . . . . . . . 29
11.4 Procedures for Senders and Receivers . . . . . . . . . . . . 30
12. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 31
12.1 File based parameter storage . . . . . . . . . . . . . . . . 33
12.2 Registry based parameter storage . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . 34
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
A. About References . . . . . . . . . . . . . . . . . . . . . . 37
B. Limitations and Future Work . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39
6. IPv6のためのIPv4. . . . . . . . . . . . . . . 15 6.1.2のMbusマルチキャストグループのための輸送. . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1Local Multicast/放送. . . . . . . . . . . . . . . . . 14 6.1.1のMbusマルチキャストグループ、.156.1、.3Use、Broadcast. . . . . . . . . . . . . . . . . . . . . . 16 6.1.4Mbus UDP Port Number. . . . . . . . . . . . . . . . . . . . 16 6.2Directed Unicast. . . . . . . . . . . . . . . . . . . . . . 16 7 信頼性. . . . . . . . . . . . . . . . . . . . . . . . 18 8。 Hello Messagesのための他のEntities. . . . . . . . . . . . . . . . 20 8.1Hello Message Transmission Interval. . . . . . . . . . . . 21 8.1.1Calculating Intervalの認識、.228.1、.2初期設定、Values. . . . . . . . . . . . . . . . . . 23 8.1.3Adjustingでは、EntitiesのNumberであるときに、Hello Message Intervalは増加します; . . . . . . . . . . . . . . . . . . . . 23 8.1.4 EntitiesのNumberが減少するとHello Message Intervalを調整する、.238.1、.5Expiration、Mbus Entities. . . . . . . . . 24 9のためのこんにちは、タイマ. . . . . . . . . . . . . . . . . 23 8.2Calculating Timeout メッセージ. . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1mbus.hello.249.2mbus.bye.259.3mbus.ping.259.4mbus.quit.269.5mbus.waiting.269.6mbus.go. . . . . . . . . . . . . . . . . . . . . . . . . . 27 10。 定数. . . . . . . . . . . . . . . . . . . . . . . . . 27 11。 Mbusセキュリティ. . . . . . . . . . . . . . . . . . . . . . . 28 11.1セキュリティは送付者と受信機. . . . . . . . . . . . 30 12のために.28 11.2暗号化. . . . . . . . . . . . . . . . . . . . . . . . . 28 11.3通報認証. . . . . . . . . . . . . . . . . . . 29 11.4手順をモデル化します。 Mbus Configuration. . . . . . . . . . . . . . . . . . . . . 31 12.1のFileのベースのパラメタ格納. . . . . . . . . . . . . . . . 33 12.2Registryはパラメタ格納. . . . . . . . . . . . . . 34 13を基礎づけました。 セキュリティ問題. . . . . . . . . . . . . . . . . . 34 14。 IANA問題. . . . . . . . . . . . . . . . . . . . 35 15。 参照. . . . . . . . . . . . . . . . . . . . . . 37のB.の制限と今後の仕事. . . . . . . . . . . . . . . . 37作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 38の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 39に関する参照. . . . . . . . . . . . . . . . . . . . . . . . . 35A.
Ott, et. al. Informational [Page 2] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[2ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
1. Introduction
1. 序論
The implementation of multiparty multimedia conferencing systems is one example where a simple coordination infrastructure can be useful: In a variety of conferencing scenarios, a local communication channel can provide conference-related information exchange between co- located but otherwise independent application entities, for example those taking part in application sessions that belong to the same conference. In loosely coupled conferences such a mechanism allows for coordination of application entities, e.g., to implement synchronization between media streams or to configure entities without user interaction. It can also be used to implement tightly coupled conferences enabling a conference controller to enforce conference wide control within an end system.
「マルチ-パーティー」マルチメディア会議システムの実現は簡単なコーディネートインフラストラクチャが役に立つ場合がある1つの例です: さまざまな会議シナリオでは、ローカルの通信チャネルは共同見つけられましたが、そうでなければ、独立しているアプリケーション実体(例えば同じ会議に属すアプリケーションセッションのときに参加するもの)の間に会議関連の情報交換を提供できます。 そのようなメカニズムでアプリケーション実体のコーディネート例えばメディアの流れの間の同期を実行するか、またはユーザ相互作用なしで実体を構成する緩く結合した会議で。 また、会議コントローラがエンドシステムの中で会議の広いコントロールを実施するのを可能にする密結合会議を実行するのにそれを使用できます。
Conferencing systems such as IP telephones can also be viewed as components of a distributed system and can thus be integrated into a group of application modules: For example, an IP telephony call that is conducted with a stand-alone IP telephone can be dynamically extended to include media engines for other media types using the coordination function of an appropriate coordination mechanism. Different individual conferencing components can thus be combined to build a coherent multimedia conferencing system for a user.
IP電話などの会議システムをまた、分散システムのコンポーネントとして見なすことができて、その結果、アプリケーションモジュールのグループと統合できます: 例えば、適切なコーディネートメカニズムのコーディネート機能を使用することで他のメディアタイプのためのメディアエンジンを含むようにダイナミックにスタンドアロンのIP電話で行われるIP電話技術呼び出しは広げることができます。 その結果、ユーザのコヒーレントマルチメディア会議システムを構築するために異なった個々の会議コンポーネントを結合できます。
Other possible scenarios include the coordination of application components that are distributed on different hosts in a network, for example, so-called Internet appliances.
他の可能なシナリオは異なったホストの上でネットワークで分配されるアプリケーション構成要素、例えば、いわゆるインターネット接続専用端末のコーディネートを含んでいます。
1.1 Mbus Overview
1.1 Mbus概観
Local coordination of application components requires a number of different interaction models: some messages (such as membership information, floor control notifications, dissemination of conference state changes, etc.) may need to be sent to all local application entities. Messages may also be targeted at a certain application class (e.g., all whiteboards or all audio tools) or agent type (e.g., all user interfaces rather than all media engines). Or there may be any (application- or message-specific) subgrouping defining the intended recipients, e.g., messages related to media synchronization. Finally, there may be messages that are directed at a single entity: for example, specific configuration settings that a conference controller sends to a particular application entity, or query- response exchanges between any local server and its clients.
アプリケーション構成要素の地元調整は多くの異なった相互作用モデルを必要とします: いくつかのメッセージ(会員資格情報、床のコントロール通知、会議州の変化の普及などの)が、すべての局所塗布実体に送られる必要があるかもしれません。 また、メッセージはあるアプリケーションのクラス(例えば、すべてのホワイトボードかすべてのオーディオのツール)かエージェントタイプ(すべてのメディアエンジンよりむしろ例えばすべてのユーザインタフェース)をターゲットにするかもしれません。 または、意図している受取人を定義するいくつかの(アプリケーションかメッセージ特有)の副分類があったかもしれません、例えば、メッセージはメディア同期に関連しました。 最終的に、単一体が向けられるメッセージがあるかもしれません: 例えば会議コントローラが特定用途実体に送る特定の構成設定、またはどんなローカルサーバとそのクライアントの間の質問応答交換。
The Mbus protocol as defined here satisfies these different communication needs by defining different message transport mechanisms (defined in Section 6) and by providing a flexible addressing scheme (defined in Section 4).
ここで定義されるMbusプロトコルは異なったメッセージ移送機構を定義して(セクション6では、定義されます)、フレキシブルなアドレシング計画を提供することによって(セクション4では、定義されます)異なったコミュニケーションが必要とするこれらを満たします。
Ott, et. al. Informational [Page 3] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[3ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
Furthermore, Mbus messages exchanged between application entities may have different reliability requirements (which are typically derived from their semantics). Some messages will have a rather transient character conveying ephemeral state information (which is refreshed/updated periodically), such as the volume meter level of an audio receiver entity to be displayed by its user interface agent. Certain Mbus messages (such as queries for parameters or queries to local servers) may require a response from the peer(s), thereby providing an explicit acknowledgment at the semantic level on top of the Mbus. Other messages will modify the application or conference state and hence it is crucial that they do not get lost. The latter type of message has to be delivered reliably to the recipient, whereas messages of the first type do not require reliability mechanisms at the Mbus transport layer. For messages confirmed at the application layer it is up to the discretion of the application whether or not to use a reliable transport underneath.
その上、アプリケーション実体の間で交換されたMbusメッセージは異なった信頼度要求事項(それらの意味論から通常得られる)を持っているかもしれません。 いくつかのメッセージで、ユーザーインタフェースエージェントによって表示されるように、かなり一時的なキャラクタはオーディオ受信機実体のボリュームメーターレベルなどのはかない州の情報(定期的にリフレッシュされるか、またはアップデートされる)を伝えるでしょう。 あるMbusメッセージ(パラメタのための質問かローカルサーバへの質問などの)は同輩から応答を必要とするかもしれません、その結果、Mbusの上で意味レベルで明白な承認を提供します。 他のメッセージはアプリケーションか会議状態を変更するでしょう、そして、したがって、失せないのは重要です。 後者のタイプに関するメッセージを受取人に確かに送らなければなりませんが、最初のタイプに関するメッセージはMbusトランスポート層で信頼性のメカニズムを必要としません。 メッセージが、応用層で下部で信頼できる輸送を使用するかどうかアプリケーションの思慮深さまで確認したので。
In some cases, application entities will want to tailor the degree of reliability to their needs, others will want to rely on the underlying transport to ensure delivery of the messages -- and this may be different for each Mbus message. The Mbus message passing mechanism specified in this document provides a maximum of flexibility by providing reliable transmission achieved through transport-layer acknowledgments (in case of point-to-point communications only) as well as unreliable message passing (for unicast, local multicast, and local broadcast). We address this topic in Section 4.
いくつかの場合、彼らの必要なことに、アプリケーション実体は信頼性の度合いを適合させたくなるでしょう、そして、他のものはメッセージの配送を確実にするために基本的な輸送に依存したくなるでしょう、そして、それぞれのMbusメッセージにおいて、これは異なっているかもしれません。 頼り無いメッセージ・パッシング(ユニキャスト、地方のマルチキャスト、およびローカル放送のための)と同様にトランスポート層承認で達成された信頼できるトランスミッションを提供することによって(二地点間コミュニケーションだけの場合に)、本書では指定されたMbusメッセージ・パッシングメカニズムは最大柔軟性を提供します。 私たちはセクション4のこの話題を記述します。
Finally, accidental or malicious disturbance of Mbus communications through messages originated by applications from other users needs to be prevented. Accidental reception of Mbus messages from other users may occur if either two users share the same host for using Mbus applications or if they are using Mbus applications that are spread across the same network link: in either case, the used Mbus multicast address and the port number may be identical leading to reception of the other party's Mbus messages in addition to the user's own ones. Malicious disturbance may happen because of applications multicasting (e.g., at a global scope) or unicasting Mbus messages. To eliminate the possibility of processing unwanted Mbus messages, the Mbus protocol contains message digests for authentication. Furthermore, the Mbus allows for encryption to ensure privacy and thus enable using the Mbus for local key distribution and other functions potentially sensitive to eavesdropping. This document defines the framework for configuring Mbus applications with regard to security parameters in Section 12.
最終的に、他のユーザからのアプリケーションで溯源されたメッセージを通したMbusコミュニケーションの偶然の、または、悪意がある騒動は、防がれる必要があります。 2人のユーザがMbusアプリケーションを使用するために同じホストを共有するか、または同じネットワークリンクの向こう側に広げられるMbusアプリケーションを使用しているなら、他のユーザからのMbusメッセージの偶然のレセプションは起こるかもしれません: どちらかの場合では、中古のMbusマルチキャストアドレスとポートナンバーはユーザの自己のものに加えた相手のMbusメッセージのレセプションへの同じ先導であるかもしれません。 悪意がある騒動はアプリケーションマルチキャスティング(例えば、グローバルな範囲の)かunicasting Mbusメッセージのために起こるかもしれません。 求められていないMbusメッセージを処理する可能性を排除するために、Mbusプロトコルは認証のためのメッセージダイジェストを含んでいます。 その上、Mbusは、暗号化が秘密を守って、その結果、地方の主要な分配のためのMbusを使用して、潜在的に雨垂れに敏感な他の機能を可能にするのを許容します。 このドキュメントは、セクション12のセキュリティパラメタに関してMbusアプリケーションを構成するために枠組みを定義します。
Ott, et. al. Informational [Page 4] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[4ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
1.2 Purpose of this Document
1.2 このDocumentの目的
Three components constitute the message bus: the low level message passing mechanisms, a command syntax and naming hierarchy, and the addressing scheme.
3つのコンポーネントがメッセージバスを構成します: 低い平らなメッセージ・パッシングメカニズムとコマンド構文と階層構造、およびアドレシング計画を命名すること。
The purpose of this document is to define the protocol mechanisms of the lower level Mbus message passing mechanism which is common to all Mbus implementations. This includes the specification of
このドキュメントの目的はすべてのMbus実現に共通の下のレベルMbusメッセージ・パッシングメカニズムのプロトコルメカニズムを定義することです。 これは仕様を含んでいます。
o the generic Mbus message format;
o 一般的なMbusメッセージ・フォーマット。
o the addressing concept for application entities (note that
concrete addressing schemes are to be defined by application-
specific profiles);
o アプリケーション実体(具体的なアドレシング計画がアプリケーションの特定のプロフィールによって定義されることであることに注意する)のためのアドレシング概念。
o the transport mechanisms to be employed for conveying messages
between (co-located) application entities;
o (共同見つけられる)のアプリケーション実体の間でメッセージを伝えるのに使われるべき移送機構。
o the security concept to prevent misuse of the Message Bus (such as
taking control of another user's conferencing environment);
o Message Bus(別のユーザの会議環境を制御などなどの)の誤用を防ぐセキュリティ概念。
o the details of the Mbus message syntax; and
o Mbusメッセージ構文の詳細。 そして
o a set of mandatory application independent commands that are used
for bootstrapping Mbus sessions.
o Mbusセッションを独力で進むのに使用される1セットの義務的なアプリケーション独立している命令。
1.3 Areas of Application
1.3 アプリケーションの領域
The Mbus protocol can be deployed in many different application areas, including but not limited to:
他を含む多くの異なった応用分野でMbusプロトコルを配備できます:
Local conference control: In the Mbone community a model has arisen
whereby a set of loosely coupled tools are used to participate in
a conference. A typical scenario is that audio, video, and shared
workspace functionality is provided by three separate tools
(although some combined tools exist). This maps well onto the
underlying RTP [8] (as well as other) media streams, which are
also transmitted separately. Given such an architecture, it is
useful to be able to perform some coordination of the separate
media tools. For example, it may be desirable to communicate
playout-point information between audio and video tools, in order
to implement lip-synchronization, to arbitrate the use of shared
resources (such as input devices), etc.
地方の会議コントロール: Mbone共同体では、1セットの緩く結合したツールが会議に参加するのに使用されるモデルは起きました。 典型的なシナリオは3個の別々のツールでオーディオ、ビデオ、および共有されたワークスペースの機能性を提供するという(いくつかの結合したツールが存在していますが)ことです。 これは基本的なRTP[8](他と同じくらいよく)にメディアの流れをよく写像します。(また、流れは別々に伝えられます)。 そのような構造を考えて、別々のメディアツールの何らかのコーディネートを実行できるのは役に立ちます。 例えば、オーディオとビデオツールの間の再生ポイント情報を伝えるのは望ましいかもしれません、共用資源(入力装置などの)などの使用を仲裁するために唇同期を実行するために
A refinement of this architecture relies on the presence of a
number of media engines which perform protocol functions as well
as capturing and playout of media. In addition, one (or more)
この構造の気品は捕らえることと同様にプロトコル機能を実行する多くのメディアエンジンの存在とメディアの再生を当てにします。 添加、1で(さらに)
Ott, et. al. Informational [Page 5] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[5ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
(separate) user interface agents exist that interact with and
control their media engine(s). Such an approach allows
flexibility in the user-interface design and implementation, but
obviously requires some means by which the various involved agents
may communicate with one another. This is particularly desirable
to enable a coherent response to a user's conference-related
actions (such as joining or leaving a conference).
彼らのメディアエンジンと対話して、制御する(別々)のユーザーインタフェースエージェントが、存在します。 そのようなアプローチは、ユーザーインターフェース設計と実現における柔軟性を許容しますが、明らかに、様々なかかわったエージェントがお互いにコミュニケートするかもしれないいくつかの手段を必要とします。 これはユーザの会議関連の動作(会議を参加するか、または出などなどの)への一貫性を持っている応答を可能にするのにおいて特に望ましいです。
Although current practice in the Mbone community is to work with a
loosely coupled conference control model, situations arise where
this is not appropriate and a more tightly coupled wide-area
conference control protocol must be employed. In such cases, it
is highly desirable to be able to re-use the existing tools (media
engines) available for loosely coupled conferences and integrate
them with a system component implementing the tight conference
control model. One appropriate means to achieve this integration
is a communication channel that allows a dedicated conference
control entity to "remotely" control the media engines in addition
to or instead of their respective user interfaces.
Mbone共同体の現在の習慣は緩く結合した会議規制モデルと共に働くことになっていますが、状況はこれが適切でないところに起こります、そして、しっかりより結合した広い領域会議制御プロトコルを使わなければなりません。 そのような場合、緩く結合した会議に利用可能な既存のツール(メディアエンジン)を再使用して、きつい会議規制モデルを実行するシステムの部品とそれらを統合できるのは非常に望ましいです。 この統合を達成する1つの適切な手段がひたむきな会議コントロール実体がインタフェースかそれらのそれぞれのユーザインタフェースの代わりにメディアエンジンを「離れて」制御できる通信チャネルです。
Control of device groups in a network: A group of devices that are
connected to a local network, e.g., home appliances in a home
network, require a local coordination mechanism. Minimizing
manual configuration and the the possibility to deploy group
communication will be useful in this application area as well.
ネットワークにおける、装置グループのコントロール: 企業内情報通信網に接続される装置のグループ(例えば、ホームネットワークにおける家電)は地元調整メカニズムを必要とします。 手動の構成とグループコミュニケーションを配備する可能性を最小にするのはまた、このアプリケーション部で役に立ちます。
1.4 Terminology for requirement specifications
1.4 要件仕様のための用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant Mbus implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[1]について説明して、対応するMbus実現のために要件レベルを示すとき解釈されることであるべきですか?
2. Common Formal Syntax Rules
2. 一般的な正式なシンタックス・ルール
This section contains definitions of common ABNF [13] syntax elements that are later referenced by other definitions in this document:
このセクションは他の定義で後で本書では参照をつけられる一般的なABNF[13]構文要素の定義を含みます:
base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] )
base64はbase64_端末/と等しいです。(1*(4base64_炭)[base64_端末])
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
「base64_炭=UPALPHA / LOALPHA / DIGIT /「+」/」/、」、。 大文字と小文字を区別
base64_terminal = (2base64_char "==") / (3base64_char "=")
base64_端末=(2base64_炭の「=」)/(3base64_炭の「=」)
UPALPHA = %x41-5A ;; Uppercase: A-Z
UPALPHA=%x41-5A。 以下を大文字してください。 1Zです。
Ott, et. al. Informational [Page 6] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[6ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
LOALPHA = %x61-7A ;; Lowercase: a-z
LOALPHA=%x61-7A。 小文字で印刷します: 1zです。
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
アルファー=%x41-5A/%x61-7A。 a A-Z/z
CHAR = %x01-7E
; any 7-bit US-ASCII character,
excluding NUL and delete
炭は%x01と-7E等しいです。 NULを除いたどんな7ビットの米国-ASCII文字、も削除
OCTET = %x00-FF
; 8 bits of data
八重奏は%x00ffと等しいです。 8ビットのデータ
CR = %x0D
; carriage return
CR=%x0D。 復帰
CRLF = CR LF
; Internet standard newline
CRLFはCR LFと等しいです。 インターネット標準ニューライン
DIGIT = %x30-39
; 0-9
ケタ=%x30-39。 0-9
DQUOTE = %x22
; " (Double Quote)
DQUOTE=%x22。 " (二重引用文)
HTAB = %x09
; horizontal tab
HTAB=%x09。 水平タブ
LF = %x0A
; linefeed
LF=%x0A。 ラインフィード
LWSP = *(WSP / CRLF WSP)
; linear white space (past newline)
LWSPは*(WSP / CRLF WSP)と等しいです。 直線的な余白(過去のニューライン)
SP = %x20
; space
SP=%x20。 スペース
WSP = SP / HTAB
; white space
WSPはSP / HTABと等しいです。 余白
Taken from RFC 2234 [13] and RFC 2554 [14].
RFC2234[13]とRFC2554[14]から、取ります。
3. Message Format
3. メッセージ・フォーマット
An Mbus message comprises a header and a body. The header is used to indicate how and where a message should be delivered and the body provides information and commands to the destination entity. The following pieces of information are included in the header:
Mbusメッセージはヘッダーとボディーを包括します。 ヘッダーは、どのように、どこでメッセージを送るべきであり、ボディーが目的地実体に情報とコマンドを備えるかを示すのに使用されます。 情報の以下の断片はヘッダーに含まれています:
Ott, et. al. Informational [Page 7] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[7ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
A fixed ProtocolID field identifies the version of the message bus
protocol used. The protocol defined in this document is
"mbus/1.0" (case-sensitive).
固定ProtocolID分野は使用されるメッセージバスプロトコルのバージョンを特定します。 本書では定義されたプロトコルは「mbus/1インチ(大文字と小文字を区別する)」です。
A sequence number (SeqNum) is contained in each message. The
first message sent by a source SHOULD set SeqNum to zero, and it
MUST increment by one for each message sent by that source. A
single sequence number is used for all messages from a source,
irrespective of the intended recipients and the reliability mode
selected. The value range of a sequence number is (0,4294967295).
An implementation MUST re-set its sequence number to 0 after
reaching 4294967295. Implementations MUST take into account that
the SeqNum of other entities may wrap-around.
一連番号(SeqNum)は各メッセージに含まれています。 SHOULDが、SeqNumがゼロに合わせるように設定して、それがそのソースによって送られた各メッセージあたり1つ増加しなければならないソースによって送られた最初のメッセージ。 ただ一つの一連番号はソースからのすべてのメッセージに使用されます、意図している受取人とモードが選んだ信頼性の如何にかかわらず。 一連番号の値の範囲は(0、4294967295)です。 4294967295に達した後に、実現は0に一連番号をリセットしなければなりません。 実現は、他の実体のSeqNumは巻きつけて着るドレスがそうするかもしれないのを考慮に入れなければなりません。
SeqNums are decimal numbers in ASCII representation.
SeqNumsはASCII表現で10進数です。
The TimeStamp field is also contained in each message and SHOULD
contain a decimal number representing the time of the message
construction in milliseconds since 00:00:00, UTC, January 1, 1970.
また、TimeStamp分野は各メッセージに含まれています、そして、SHOULDは1970年1月1日に00:00:00、UTC以来のミリセカンドで表現されるメッセージ工事の時間を表す10進数を含んでいます。
A MessageType field indicates the kind of message being sent. The
value "R" indicates that the message is to be transmitted reliably
and MUST be acknowledged by the recipient, "U" indicates an
unreliable message which MUST NOT be acknowledged.
MessageType分野は送られるメッセージの種類を示します。 値「R」をメッセージが確かに伝えられることであることを示して、受取人は認めなければならなくて、「U」は承認してはいけないあてにならないメッセージを示します。
The SrcAddr field identifies the sender of a message. This MUST
be a complete address, with all address elements specified. The
addressing scheme is described in Section 4.
SrcAddr分野はメッセージの送付者を特定します。 これはすべてのアドレス要素が指定されている完全なアドレスであるに違いありません。 アドレシング計画はセクション4で説明されます。
The DestAddr field identifies the intended recipient(s) of the
message. This field MAY be wildcarded by omitting address
elements and hence address any number (including zero) of
application entities. The addressing scheme is described in
Section 4.
DestAddr分野はメッセージの意図している受取人を特定します。 この分野は、アドレス要素を省略することによってwildcardedされて、したがって、どんな数(ゼロを含んでいる)のアプリケーション実体も記述するかもしれません。 アドレシング計画はセクション4で説明されます。
The AckList field comprises a list of SeqNums for which this
message is an acknowledgment. See Section 7 for details.
AckList分野はこのメッセージが承認であるSeqNumsのリストを包括します。 詳細に関してセクション7を見てください。
The header is followed by the message body which contains zero or more commands to be delivered to the destination entity. The syntax for a complete message is given in Section 5.
ゼロを含むメッセージ本体がヘッダーのあとに続いているか、または以上は目的地実体に渡されると命令します。 セクション5で完全なメッセージのための構文を与えます。
If multiple commands are contained within the same Mbus message payload, they MUST to be delivered to the Mbus application in the same sequence in which they appear in the message payload.
複数のコマンドが同じMbusメッセージペイロードの中に含まれているなら、彼らは含まれなければなりません。彼らがメッセージペイロードに現れる同じ系列におけるMbusアプリケーションに渡すために。
Ott, et. al. Informational [Page 8] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[8ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
4. Addressing
4. アドレシング
Each entity in the message has a unique Mbus address that is used to identify the entity. Mbus addresses are sequences of address elements that are tag/value pairs. The tag and the value are separated by a colon and tag/value pairs are separated by whitespace, like this:
メッセージの各実体には、実体を特定するのに使用されるユニークなMbusアドレスがあります。 Mbusアドレスはタグ/値の組であるアドレス要素の系列です。 タグと値はコロンによって切り離されます、そして、タグ/値の組はこのように空白によって切り離されます:
(tag:value tag:value ...)
(タグ: タグを評価してください: 値)
The formal ABNF syntax definition for Mbus addresses and their elements is as follows:
Mbusアドレスとそれらの要素のための正式なABNF構文定義は以下の通りです:
mbus_address = "(" *WSP *1address_list *WSP ")"
address_list = address_element
/ address_element 1*WSP address_list
「(「*WSP*1address_リスト*WSP」)」というmbus_アドレス=アドレス_リスト=アドレス_要素/アドレス_要素1*WSPアドレス_リスト
address_element = address_tag ":" address_value
「アドレス_要素=アドレス_タグ」:、」 アドレス_値
address_tag = 1*32(ALPHA)
アドレス_タグ=1*32(アルファー)
address_value = 1*64(%x21-27 / %x2A-7E)
; any 7-bit US-ASCII character
; excluding white space, delete,
; control characters, "(" and ")"
_値の=1*64(%x21-27/%x2A-7E)を記述してください。 どんな7ビットの米国-ASCII文字も。 余白を除く、削除します。 そして、制御文字、「(「」、)、」
Note that this and other ABNF definitions in this document use the non-terminal symbols defined in Section 2.
これと他のABNF定義が本書ではセクション2で定義された非終端記号を使用することに注意してください。
An address_tag MUST be unique within an Mbus address, i.e., it MUST only occur once.
アドレス_タグがMbusアドレスの中でユニークであるに違いない、すなわち、それは一度起こるだけでよいです。
Each entity has a fixed sequence of address elements constituting its address and MUST only process messages sent to addresses that either match all elements or consist of a subset of its own address elements. The order of address elements in an address sequence is not relevant. Two address elements match if both their tags and their values are equivalent. Equivalence for address element and address value strings means that each octet in the one string has the same value as the corresponding octet in the second string. For example, an entity with an address of:
各実体は、アドレスを構成するアドレス要素の固定系列を持って、すべての要素を合わせるか、またはそれ自身のアドレス要素の部分集合から成るアドレスに送られたメッセージを処理するだけでよいです。 アドレス系列における、アドレス要素の注文は関連していません。 それらの両方のタグとそれらの値が同等であるなら、2個のアドレス要素が合っています。 アドレス要素とアドレス値ストリングのための等価性は、1個のストリングにおける各八重奏には2番目のストリングにおける対応する八重奏と同じ値があることを意味します。 例えば、以下のアドレスがある実体
(conf:test media:audio module:engine app:rat id:4711-1@192.168.1.1)
(conf: テストメディア: オーディオモジュール: エンジン装置: ネズミイド: 4711-1@192.168.1.1 )
will process messages sent to
発信するメッセージを処理するでしょう。
(media:audio module:engine)
(メディア: オーディオモジュール: エンジン)
Ott, et. al. Informational [Page 9] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[9ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
and
そして
(module:engine)
(モジュール: エンジン)
but must ignore messages sent to
しかし、必須は発信するメッセージを無視します。
(conf:test media:audio module:engine app:rat id:123-4@192.168.1.1 foo:bar)
(conf: テストメディア: オーディオモジュール: エンジン装置: ネズミイド: 123-4@192.168.1.1 foo: バー)
and
そして
(foo:bar)
(foo: バー)
A message that should be processed by all entities requires an empty set of address elements.
すべての実体によって処理されるべきであるメッセージは空のセットにアドレス要素を要求します。
4.1 Mandatory Address Elements
4.1 義務的なアドレス要素
Each Mbus entity MUST provide one mandatory address element that allows it to identify the entity. The element tag is "id" and the value MUST be be composed of the following components:
それぞれのMbus実体はそれが実体を特定できる1個の義務的なアドレス要素を提供しなければなりません。 要素タグによる「イド」と値があるに違いないということです。以下のコンポーネントで構成されてください:
o The IP address of the interface that is used for sending messages
to the Mbus. For IPv4 this is the address in dotted decimal
notation. For IPv6 the interface-ID-part of the node's link-local
address in textual representation as specified in RFC 2373 [3]
MUST be used.
o 送付メッセージにMbusに使用されるインタフェースのIPアドレス。 IPv4に関しては、ドット付き10進法でこれはアドレスです。 IPv6のために、RFC2373[3]の指定されるとしての原文の表現におけるノードのリンクローカルアドレスのインタフェースID一部を使用しなければなりません。
In this specification, this part is called the "host-ID".
この仕様では、この部分は「ホストID」と呼ばれます。
o An identifier ("entity-ID") that is unique within the scope of a
single host-ID. The entity comprises two parts. For systems
where the concept of a process ID is applicable it is RECOMMENDED
that this identifier be composed using a process-ID and a per-
process disambiguator for different Mbus entities of a process.
If a process ID is not available, this part of the entity-ID may
be randomly chosen (it is recommended that at least a 32 bit
random number is chosen). Both numbers are represented in decimal
textual form and MUST be separated by a '-' (ASCII x2d) character.
o 単一のホストIDの範囲の中でユニークな識別子(「実体ID」)。 実体は2つの部品を包括します。 この識別子が過程IDとaを使用することで構成されるのが、過程IDの概念が適切であるシステムのための、RECOMMENDEDである、-、過程の異なったMbus実体のためのdisambiguatorを処理してください。 過程IDが利用可能でないなら、実体IDのこの部分は手当たりしだいに選ばれるかもしれません(それは乱数が選ばれることが少なくとも32ビット勧められます)。 両方の数を10進原文のフォームに表されて、'--'(ASCII x2d)キャラクタは切り離さなければなりません。
Note that the entity-ID cannot be the port number of the endpoint used for sending messages to the Mbus because implementations MAY use the common Mbus port number for sending to and receiving from the multicast group (as specified in Section 6).
マルチキャストグループから実体IDが実現が送付に一般的なMbusポートナンバーを使用するかもしれないので送付メッセージにMbusに使用される終点のポートナンバーであるはずがないことに注意して、受信してください(セクション6で指定されるように)。
The complete syntax definition for the entity identifier is as follows:
エンティティ識別名のための完全な構文定義は以下の通りです:
Ott, et. al. Informational [Page 10] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[10ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
id-element = "id:" id-value
イド要素=、「イド:」 イド値
id-value = entity-id "@" host-id
イド値は実体イド"@"ホストイドと等しいです。
entity-id = 1*10DIGIT "-" 1*5DIGIT
実体イド=1*10DIGIT「-」1*5DIGIT
host-id = (IPv4address / IPv6address)
ホストイド=(IPv4address / IPv6address)
Please refer to [3] for the productions of IPv4address and IPv6address.
Please refer to [3] for the productions of IPv4address and IPv6address.
An example for an id element:
An example for an id element:
id:4711-99@192.168.1.1
id:4711-99@192.168.1.1
5. Message Syntax
5. Message Syntax
5.1 Message Encoding
5.1 Message Encoding
All messages MUST use the UTF-8 character encoding. Note that US ASCII is a subset of UTF-8 and requires no additional encoding, and that a message encoded with UTF-8 will not contain zero bytes.
All messages MUST use the UTF-8 character encoding. Note that US ASCII is a subset of UTF-8 and requires no additional encoding, and that a message encoded with UTF-8 will not contain zero bytes.
Each Message MAY be encrypted using a secret key algorithm as defined in Section 11.
Each Message MAY be encrypted using a secret key algorithm as defined in Section 11.
5.2 Message Header
5.2 Message Header
The fields in the header are separated by white space characters, and followed by CRLF. The format of the header is as follows:
The fields in the header are separated by white space characters, and followed by CRLF. The format of the header is as follows:
msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP
MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList
msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList
The header fields are explained in Message Format (Section 3). Here are the ABNF syntax definitions for the header fields:
The header fields are explained in Message Format (Section 3). Here are the ABNF syntax definitions for the header fields:
SeqNum = 1*10DIGIT ; numeric range 0 - 2^32-1
SeqNum = 1*10DIGIT ; numeric range 0 - 2^32-1
TimeStamp = 1*13DIGIT
TimeStamp = 1*13DIGIT
MessageType = "R" / "U"
MessageType = "R" / "U"
ScrAddr = mbus_address
ScrAddr = mbus_address
DestAddr = mbus_address
DestAddr = mbus_address
Ott, et. al. Informational [Page 11] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 11] RFC 3259 A Message Bus for Local Coordination April 2002
AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")"
AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")"
See Section 4 for a definition of "mbus_address".
See Section 4 for a definition of "mbus_address".
The syntax definition of a complete message is as follows:
The syntax definition of a complete message is as follows:
mbus_message = msg_header *1(CRLF msg_payload)
mbus_message = msg_header *1(CRLF msg_payload)
msg_payload = mbus_command *(CRLF mbus_command)
msg_payload = mbus_command *(CRLF mbus_command)
The definition of production rules for an Mbus command is given in Section 5.3.
The definition of production rules for an Mbus command is given in Section 5.3.
5.3 Command Syntax
5.3 Command Syntax
The header is followed by zero, one, or more, commands to be delivered to the Mbus entities indicated by the DestAddr field. Each command consists of a command name that is followed by a list of zero, or more parameters and is terminated by a newline.
The header is followed by zero, one, or more, commands to be delivered to the Mbus entities indicated by the DestAddr field. Each command consists of a command name that is followed by a list of zero, or more parameters and is terminated by a newline.
command ( parameter parameter ... )
command ( parameter parameter ... )
Syntactically, the command name MUST be a `symbol' as defined in the following table. The parameters MAY be any data type drawn from the following table:
Syntactically, the command name MUST be a `symbol' as defined in the following table. The parameters MAY be any data type drawn from the following table:
val = Integer / Float / String / List /
Symbol / Data
val = Integer / Float / String / List / Symbol / Data
Integer = *1"-" 1*DIGIT
Integer = *1"-" 1*DIGIT
Float = *1"-" 1*DIGIT "." 1*DIGIT
Float = *1"-" 1*DIGIT "." 1*DIGIT
String = DQUOTE *CHAR DQUOTE
; see below for escape characters
String = DQUOTE *CHAR DQUOTE ; see below for escape characters
List = "(" *WSP *1(val *(1*WSP val)) *WSP ")"
List = "(" *WSP *1(val *(1*WSP val)) *WSP ")"
Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" /
".")
Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" / ".")
Data = "<" *base64 ">"
Data = "<" *base64 ">"
Boolean values are encoded as an integer, with the value of zero representing false, and non-zero representing true.
Boolean values are encoded as an integer, with the value of zero representing false, and non-zero representing true.
Ott, et. al. Informational [Page 12] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 12] RFC 3259 A Message Bus for Local Coordination April 2002
String parameters in the payload MUST be enclosed in the double quote
(") character. Within strings, the escape character is the backslash
(\), and the following escape sequences are defined:
String parameters in the payload MUST be enclosed in the double quote (") character. Within strings, the escape character is the backslash (\), and the following escape sequences are defined:
+----------------+-----------+
|Escape Sequence | Meaning |
+----------------+-----------+
| \\ | \ |
| \" | " |
| \n | newline |
+----------------+-----------+
+----------------+-----------+ |Escape Sequence | Meaning | +----------------+-----------+ | \\ | \ | | \" | " | | \n | newline | +----------------+-----------+
List parameters do not have to be homogeneous lists, i.e., they can contain parameters of different types.
List parameters do not have to be homogeneous lists, i.e., they can contain parameters of different types.
Opaque data is represented as Base64-encoded (see RFC 1521 [7]) character strings surrounded by "< " and "> "
Opaque data is represented as Base64-encoded (see RFC 1521 [7]) character strings surrounded by "< " and "> "
The ABNF syntax definition for Mbus commands is as follows:
The ABNF syntax definition for Mbus commands is as follows:
mbus_command = command_name arglist
mbus_command = command_name arglist
command_name = Symbol
command_name = Symbol
arglist = List
arglist = List
Command names SHOULD be constructed hierarchically to group conceptually related commands under a common hierarchy. The delimiter between names in the hierarchy MUST be "." (dot). Application profiles MUST NOT define commands starting with "mbus.".
Command names SHOULD be constructed hierarchically to group conceptually related commands under a common hierarchy. The delimiter between names in the hierarchy MUST be "." (dot). Application profiles MUST NOT define commands starting with "mbus.".
The Mbus addressing scheme defined in Section 4 allows specifying incomplete addresses by omitting certain elements of an address element list, enabling entities to send commands to a group of Mbus entities. Therefore, all command names SHOULD be unambiguous in a way that it is possible to interpret or ignore them without considering the message's address.
The Mbus addressing scheme defined in Section 4 allows specifying incomplete addresses by omitting certain elements of an address element list, enabling entities to send commands to a group of Mbus entities. Therefore, all command names SHOULD be unambiguous in a way that it is possible to interpret or ignore them without considering the message's address.
A set of commands within a certain hierarchy that MUST be understood by every entity is defined in Section 9.
A set of commands within a certain hierarchy that MUST be understood by every entity is defined in Section 9.
6. Transport
6. Transport
All messages are transmitted as UDP messages, with two possible alternatives:
All messages are transmitted as UDP messages, with two possible alternatives:
Ott, et. al. Informational [Page 13] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 13] RFC 3259 A Message Bus for Local Coordination April 2002
1. Local multicast/broadcast:
This transport class MUST be used for all messages that are not
sent to a fully qualified target address. It MAY also be used for
messages that are sent to a fully qualified target address. It
MUST be provided by conforming implementations. See Section 6.1
for details.
1. Local multicast/broadcast: This transport class MUST be used for all messages that are not sent to a fully qualified target address. It MAY also be used for messages that are sent to a fully qualified target address. It MUST be provided by conforming implementations. See Section 6.1 for details.
2. Directed unicast:
This transport class MAY be used for messages that are sent to a
fully qualified destination address. It is OPTIONAL and does not
have to be provided by conforming implementations.
2. Directed unicast: This transport class MAY be used for messages that are sent to a fully qualified destination address. It is OPTIONAL and does not have to be provided by conforming implementations.
A fully qualified target address is an Mbus address of an existing Mbus entity in an Mbus session. An implementation can identify an Mbus address as fully qualified by maintaining a list of known entities within an Mbus session. Each known entity has its own unique, fully qualified Mbus address.
A fully qualified target address is an Mbus address of an existing Mbus entity in an Mbus session. An implementation can identify an Mbus address as fully qualified by maintaining a list of known entities within an Mbus session. Each known entity has its own unique, fully qualified Mbus address.
Messages are transmitted in UDP datagrams, a maximum message size of 64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications using a non host-local scope do not exceed a message size of the link MTU.
Messages are transmitted in UDP datagrams, a maximum message size of 64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications using a non host-local scope do not exceed a message size of the link MTU.
Note that "unicast", "multicast" and "broadcast" mean IP Unicast, IP Multicast and IP Broadcast respectively. It is possible to send an Mbus message that is addressed to a single entity using IP Multicast.
Note that "unicast", "multicast" and "broadcast" mean IP Unicast, IP Multicast and IP Broadcast respectively. It is possible to send an Mbus message that is addressed to a single entity using IP Multicast.
This specification deals with both Mbus over UDP/IPv4 and Mbus over UDP/IPv6.
This specification deals with both Mbus over UDP/IPv4 and Mbus over UDP/IPv6.
6.1 Local Multicast/Broadcast
6.1 Local Multicast/Broadcast
In general, the Mbus uses multicast with a limited scope for message transport. Two different Mbus multicast scopes are defined, either of which can be configured to be used with an Mbus session:
In general, the Mbus uses multicast with a limited scope for message transport. Two different Mbus multicast scopes are defined, either of which can be configured to be used with an Mbus session:
1. host-local
1. host-local
2. link-local
2. link-local
Participants of an Mbus session have to know the multicast address in advance -- it cannot be negotiated during the session since it is already needed for initial communication between the Mbus entities during the bootstrapping phase. It also cannot be allocated prior to an Mbus session because there would be no mechanism to announce the allocated address to all potential Mbus entities. Therefore, the multicast address has to be assigned statically. This document defines the use of statically assigned addresses and also provides a
Participants of an Mbus session have to know the multicast address in advance -- it cannot be negotiated during the session since it is already needed for initial communication between the Mbus entities during the bootstrapping phase. It also cannot be allocated prior to an Mbus session because there would be no mechanism to announce the allocated address to all potential Mbus entities. Therefore, the multicast address has to be assigned statically. This document defines the use of statically assigned addresses and also provides a
Ott, et. al. Informational [Page 14] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 14] RFC 3259 A Message Bus for Local Coordination April 2002
specification of how an Mbus session can be configured to use non- standard, unassigned addresses (see Section 12).
specification of how an Mbus session can be configured to use non- standard, unassigned addresses (see Section 12).
The following sections specify the use of multicast addresses for IPv4 and IPv6.
The following sections specify the use of multicast addresses for IPv4 and IPv6.
6.1.1 Mbus multicast groups for IPv4
6.1.1 Mbus multicast groups for IPv4
For IPv4, a statically assigned, scope-relative multicast address as defined by RFC 2365 [11] is used. The offset for the scope relative address for Mbus is 8 (MBUS, see http://www.iana.org/assignments/multicast-addresses [19]).
For IPv4, a statically assigned, scope-relative multicast address as defined by RFC 2365 [11] is used. The offset for the scope relative address for Mbus is 8 (MBUS, see http://www.iana.org/assignments/multicast-addresses [19]).
Different scopes are defined by RFC 2365 [11]. The IPv4 Local Scope (239.255.0.0/16) is the minimal enclosing scope for administratively scoped multicast (as defined by RFC 2365 [11]) and not further divisible -- its exact extent is site dependent.
Different scopes are defined by RFC 2365 [11]. The IPv4 Local Scope (239.255.0.0/16) is the minimal enclosing scope for administratively scoped multicast (as defined by RFC 2365 [11]) and not further divisible -- its exact extent is site dependent.
For the IPv4 Local Scope, applying the rules of RFC 2365 [11] and using the assigned offset of 8, the Mbus multicast address is therefore 239.255.255.247.
For the IPv4 Local Scope, applying the rules of RFC 2365 [11] and using the assigned offset of 8, the Mbus multicast address is therefore 239.255.255.247.
For IPv4, the different defined Mbus scopes (host-local and link- local) are to be realized as follows:
For IPv4, the different defined Mbus scopes (host-local and link- local) are to be realized as follows:
host-local multicast: Unless configured otherwise, the assigned
scope-relative Mbus address in the Local Scope (239.255.255.247 as
of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent
with a TTL of 0.
host-local multicast: Unless configured otherwise, the assigned scope-relative Mbus address in the Local Scope (239.255.255.247 as of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent with a TTL of 0.
link-local multicast: Unless configured otherwise, the assigned
scope-relative Mbus address in the Local Scope (239.255.255.247 as
of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent
with a TTL of 1.
link-local multicast: Unless configured otherwise, the assigned scope-relative Mbus address in the Local Scope (239.255.255.247 as of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent with a TTL of 1.
6.1.2 Mbus multicast groups for IPv6
6.1.2 Mbus multicast groups for IPv6
IPv6 has different address ranges for different multicast scopes and distinguishes node local and link local scopes, that are implemented as a set of address prefixes for the different address ranges (RFC 2373 [3]). The link-local prefix is FF02, the node-local prefix is FF01. A permanently assigned multicast address will be used for Mbus multicast communication, i.e., an address that is independent of the scope value and that can be used for all scopes. Implementations for IPv6 MUST use the scope-independent address and the appropriate prefix for the selected scope. For host-local Mbus communication the IPv6 node-local scope prefix MUST be used, for link-local Mbus communication the IPv6 link-local scope prefix MUST be used.
IPv6 has different address ranges for different multicast scopes and distinguishes node local and link local scopes, that are implemented as a set of address prefixes for the different address ranges (RFC 2373 [3]). The link-local prefix is FF02, the node-local prefix is FF01. A permanently assigned multicast address will be used for Mbus multicast communication, i.e., an address that is independent of the scope value and that can be used for all scopes. Implementations for IPv6 MUST use the scope-independent address and the appropriate prefix for the selected scope. For host-local Mbus communication the IPv6 node-local scope prefix MUST be used, for link-local Mbus communication the IPv6 link-local scope prefix MUST be used.
Ott, et. al. Informational [Page 15] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 15] RFC 3259 A Message Bus for Local Coordination April 2002
The permanent IPv6 multicast address for Mbus/Ipv6 is FF0X:0:0:0:0:0:0:300.
The permanent IPv6 multicast address for Mbus/Ipv6 is FF0X:0:0:0:0:0:0:300.
FF0X:0:0:0:0:0:0:300 SHOULD be used for Mbus/IPv6 where the X in FF0X indicates that the scope is not fixed because this is an all scope address. This means, for node-local scope, FF01:0:0:0:0:0:0:300 SHOULD be used and for link-local scope FF02:0:0:0:0:0:0:300 SHOULD be used. See RFC 2375 [4] for IPv6 multicast address assignments.
FF0X:0:0:0:0:0:0:300 SHOULD be used for Mbus/IPv6 where the X in FF0X indicates that the scope is not fixed because this is an all scope address. This means, for node-local scope, FF01:0:0:0:0:0:0:300 SHOULD be used and for link-local scope FF02:0:0:0:0:0:0:300 SHOULD be used. See RFC 2375 [4] for IPv6 multicast address assignments.
If a single application system is distributed across several co- located hosts, link local scope SHOULD be used for multicasting Mbus messages that potentially have recipients on the other hosts. The Mbus protocol is not intended (and hence deliberately not designed) for communication between hosts not on the same link. See Section 12 for specifications of Mbus configuration mechanisms.
If a single application system is distributed across several co- located hosts, link local scope SHOULD be used for multicasting Mbus messages that potentially have recipients on the other hosts. The Mbus protocol is not intended (and hence deliberately not designed) for communication between hosts not on the same link. See Section 12 for specifications of Mbus configuration mechanisms.
6.1.3 Use of Broadcast
6.1.3 Use of Broadcast
In situations where multicast is not available, broadcast MAY be used instead. In these cases an IP broadcast address for the connected network SHOULD be used for sending. The node-local broadcast address for IPv6 is FF01:0:0:0:0:0:0:1, the link-local broadcast address for IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the generic broadcast address (for link-local broadcast) is 255.255.255.255. It is RECOMMENDED that IPv4-implementations use the generic broadcast address and a TTL of zero for host-local broadcast.
In situations where multicast is not available, broadcast MAY be used instead. In these cases an IP broadcast address for the connected network SHOULD be used for sending. The node-local broadcast address for IPv6 is FF01:0:0:0:0:0:0:1, the link-local broadcast address for IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the generic broadcast address (for link-local broadcast) is 255.255.255.255. It is RECOMMENDED that IPv4-implementations use the generic broadcast address and a TTL of zero for host-local broadcast.
Broadcast MUST NOT be used in situations where multicast is available and supported by all systems participating in an Mbus session.
Broadcast MUST NOT be used in situations where multicast is available and supported by all systems participating in an Mbus session.
See Section 12 for configuring the use of broadcast.
See Section 12 for configuring the use of broadcast.
6.1.4 Mbus UDP Port Number
6.1.4 Mbus UDP Port Number
The registered Mbus UDP port number is 47000.
The registered Mbus UDP port number is 47000.
6.2 Directed Unicast
6.2 Directed Unicast
Directed unicast (via UDP) to the port of a specific application is an alternative transport class to multicast. Directed unicast is an OPTIONAL optimization and MAY be used by Mbus implementations for delivering messages addressed to a single application entity only -- the address of which the Mbus implementation has learned from other message exchanges before. Note that the DestAddr field of such messages MUST be filled in properly nevertheless. Every Mbus entity SHOULD use a single unique endpoint address for sending messages to the Mbus multicast group or to individual receiving entities. A
Directed unicast (via UDP) to the port of a specific application is an alternative transport class to multicast. Directed unicast is an OPTIONAL optimization and MAY be used by Mbus implementations for delivering messages addressed to a single application entity only -- the address of which the Mbus implementation has learned from other message exchanges before. Note that the DestAddr field of such messages MUST be filled in properly nevertheless. Every Mbus entity SHOULD use a single unique endpoint address for sending messages to the Mbus multicast group or to individual receiving entities. A
Ott, et. al. Informational [Page 16] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 16] RFC 3259 A Message Bus for Local Coordination April 2002
unique endpoint address is a tuple consisting of the entity's IP address and a UDP source port number, where the port number is different from the standard Mbus port number.
unique endpoint address is a tuple consisting of the entity's IP address and a UDP source port number, where the port number is different from the standard Mbus port number.
Messages MUST only be sent via unicast if the Mbus target address is unique and if the sending entity can verify that the receiving entity uses a unique endpoint address. The latter can be verified by considering the last message received from that entity.
Messages MUST only be sent via unicast if the Mbus target address is unique and if the sending entity can verify that the receiving entity uses a unique endpoint address. The latter can be verified by considering the last message received from that entity.
Note that several Mbus entities, say within the same process, may
share a common transport address; in this case, the contents of
the destination address field is used to further dispatch the
message. Given the definition of "unique endpoint address" above,
the use of a shared endpoint address and a dispatcher still allows
other Mbus entities to send unicast messages to one of the
entities that share the endpoint address. So this can be
considered an implementation detail.
Note that several Mbus entities, say within the same process, may share a common transport address; in this case, the contents of the destination address field is used to further dispatch the message. Given the definition of "unique endpoint address" above, the use of a shared endpoint address and a dispatcher still allows other Mbus entities to send unicast messages to one of the entities that share the endpoint address. So this can be considered an implementation detail.
Messages with an empty target address list MUST always be sent to all Mbus entities (via multicast if available).
Messages with an empty target address list MUST always be sent to all Mbus entities (via multicast if available).
The following algorithm can be used by sending entities to determine whether an Mbus address is unique considering the current set of Mbus entities:
The following algorithm can be used by sending entities to determine whether an Mbus address is unique considering the current set of Mbus entities:
let ta=the target address;
iterate through the set of all
currently known Mbus addresses {
let ti=the address in each iteration;
count the addresses for which
the predicate isSubsetOf(ta,ti) yields true;
}
let ta=the target address; iterate through the set of all currently known Mbus addresses { let ti=the address in each iteration; count the addresses for which the predicate isSubsetOf(ta,ti) yields true; }
If the count of matching addresses is exactly 1 the address is
unique. The following algorithm can be used for the predicate
isSubsetOf, that checks whether the second message matches the
first according to the rules specified in Section 4. (A match
means that a receiving entity that uses the second Mbus address
must also process received messages with the first address as a
target address.)
If the count of matching addresses is exactly 1 the address is unique. The following algorithm can be used for the predicate isSubsetOf, that checks whether the second message matches the first according to the rules specified in Section 4. (A match means that a receiving entity that uses the second Mbus address must also process received messages with the first address as a target address.)
isSubsetOf(addr a1,a2) yields true, iff
every address element of a1 is contained
in a2's address element list.
isSubsetOf(addr a1,a2) yields true, iff every address element of a1 is contained in a2's address element list.
Ott, et. al. Informational [Page 17] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 17] RFC 3259 A Message Bus for Local Coordination April 2002
An address element a1 is contained in an address element list if
the list contains an element that is equal to a1. An address
element is considered equal to another address element if it has
the same values for both of the two address element fields (tag
and value).
An address element a1 is contained in an address element list if the list contains an element that is equal to a1. An address element is considered equal to another address element if it has the same values for both of the two address element fields (tag and value).
7. Reliability
7. Reliability
While most messages are expected to be sent using unreliable transport, it may be necessary to deliver some messages reliably. Reliability can be selected on a per message basis by means of the MessageType field. Reliable delivery is supported for messages with a single recipient only; i.e., to a fully qualified Mbus address. An entity can thus only send reliable messages to known addresses, i.e., it can only send reliable messages to entities that have announced their existence on the Mbus (e.g., by means of mbus.hello() messages as defined in Section 9.1). A sending entity MUST NOT send a message reliably if the target address is not unique. (See Section 6 for the specification of an algorithm to determine whether an address is unique.) A receiving entity MUST only process and acknowledge a reliable message if the destination address exactly matches its own source address (the destination address MUST NOT be a subset of the source address).
While most messages are expected to be sent using unreliable transport, it may be necessary to deliver some messages reliably. Reliability can be selected on a per message basis by means of the MessageType field. Reliable delivery is supported for messages with a single recipient only; i.e., to a fully qualified Mbus address. An entity can thus only send reliable messages to known addresses, i.e., it can only send reliable messages to entities that have announced their existence on the Mbus (e.g., by means of mbus.hello() messages as defined in Section 9.1). A sending entity MUST NOT send a message reliably if the target address is not unique. (See Section 6 for the specification of an algorithm to determine whether an address is unique.) A receiving entity MUST only process and acknowledge a reliable message if the destination address exactly matches its own source address (the destination address MUST NOT be a subset of the source address).
Disallowing reliable message delivery for messages sent to multiple destinations is motivated by simplicity of the implementation as well as the protocol. The desired effect can be achieved at the application layer by sending individual reliable messages to each fully qualified destination address, if the membership information for the Mbus session is available.
Disallowing reliable message delivery for messages sent to multiple destinations is motivated by simplicity of the implementation as well as the protocol. The desired effect can be achieved at the application layer by sending individual reliable messages to each fully qualified destination address, if the membership information for the Mbus session is available.
Each message is tagged with a message sequence number. If the MessageType is "R", the sender expects an acknowledgment from the recipient within a short period of time. If the acknowledgment is not received within this interval, the sender MUST retransmit the message (with the same message sequence number), increase the timeout, and restart the timer. Messages MUST be retransmitted a small number of times (see below) before the transmission or the recipient are considered to have failed. If the message is not delivered successfully, the sending application is notified. In this case, it is up to the application to determine the specific actions (if any) to be taken.
Each message is tagged with a message sequence number. If the MessageType is "R", the sender expects an acknowledgment from the recipient within a short period of time. If the acknowledgment is not received within this interval, the sender MUST retransmit the message (with the same message sequence number), increase the timeout, and restart the timer. Messages MUST be retransmitted a small number of times (see below) before the transmission or the recipient are considered to have failed. If the message is not delivered successfully, the sending application is notified. In this case, it is up to the application to determine the specific actions (if any) to be taken.
Ott, et. al. Informational [Page 18] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 18] RFC 3259 A Message Bus for Local Coordination April 2002
Reliable messages MUST be acknowledged by adding their SeqNum to the AckList field of a message sent to the originator of the reliable message. This message MUST be sent to a fully qualified Mbus target address. Multiple acknowledgments MAY be sent in a single message. Implementations MAY either piggy-back the AckList onto another message sent to the same destination, or MAY send a dedicated acknowledgment message, with no commands in the message payload part.
Reliable messages MUST be acknowledged by adding their SeqNum to the AckList field of a message sent to the originator of the reliable message. This message MUST be sent to a fully qualified Mbus target address. Multiple acknowledgments MAY be sent in a single message. Implementations MAY either piggy-back the AckList onto another message sent to the same destination, or MAY send a dedicated acknowledgment message, with no commands in the message payload part.
The precise procedures are as follows:
The precise procedures are as follows:
Sender: A sender A of a reliable message M to receiver B MUST
transmit the message either via IP-multicast or via IP-unicast,
keep a copy of M, initialize a retransmission counter N to '1',
and start a retransmission timer T (initialized to T_r). If an
acknowledgment is received from B, timer T MUST be cancelled and
the copy of M is discarded. If T expires, the message M MUST be
retransmitted, the counter N MUST be incremented by one, and the
timer MUST be restarted (set to N*T_r). If N exceeds the
retransmission threshold N_r, the transmission is assumed to have
failed, further retransmission attempts MUST NOT be undertaken,
the copy of M MUST be discarded, and the sending application
SHOULD be notified.
Sender: A sender A of a reliable message M to receiver B MUST transmit the message either via IP-multicast or via IP-unicast, keep a copy of M, initialize a retransmission counter N to '1', and start a retransmission timer T (initialized to T_r). If an acknowledgment is received from B, timer T MUST be cancelled and the copy of M is discarded. If T expires, the message M MUST be retransmitted, the counter N MUST be incremented by one, and the timer MUST be restarted (set to N*T_r). If N exceeds the retransmission threshold N_r, the transmission is assumed to have failed, further retransmission attempts MUST NOT be undertaken, the copy of M MUST be discarded, and the sending application SHOULD be notified.
Receiver: A receiver B of a reliable message from a sender A MUST
acknowledge reception of the message within a time period T_c <
T_r. This MAY be done by means of a dedicated acknowledgment
message or by piggy-backing the acknowledgment on another message
addressed only to A.
Receiver: A receiver B of a reliable message from a sender A MUST acknowledge reception of the message within a time period T_c < T_r. This MAY be done by means of a dedicated acknowledgment message or by piggy-backing the acknowledgment on another message addressed only to A.
Receiver optimization: In a simple implementation, B may choose to
immediately send a dedicated acknowledgment message. However, for
efficiency, it could add the SeqNum of the received message to a
sender-specific list of acknowledgments; if the added SeqNum is
the first acknowledgment in the list, B SHOULD start an
acknowledgment timer TA (initialized to T_c). When the timer
expires, B SHOULD create a dedicated acknowledgment message and
send it to A. If B is to transmit another Mbus message addressed
only to A, it should piggy-back the acknowledgments onto this
message and cancel TA. In either case, B should store a copy of
the acknowledgment list as a single entry in the per-sender copy
list, keep this entry for a period T_k, and empty the
acknowledgment list. In case any of the messages kept in an entry
of the copy list is received again from A, the entire
acknowledgment list stored in this entry is scheduled for (re-)
transmission following the above rules.
Receiver optimization: In a simple implementation, B may choose to immediately send a dedicated acknowledgment message. However, for efficiency, it could add the SeqNum of the received message to a sender-specific list of acknowledgments; if the added SeqNum is the first acknowledgment in the list, B SHOULD start an acknowledgment timer TA (initialized to T_c). When the timer expires, B SHOULD create a dedicated acknowledgment message and send it to A. If B is to transmit another Mbus message addressed only to A, it should piggy-back the acknowledgments onto this message and cancel TA. In either case, B should store a copy of the acknowledgment list as a single entry in the per-sender copy list, keep this entry for a period T_k, and empty the acknowledgment list. In case any of the messages kept in an entry of the copy list is received again from A, the entire acknowledgment list stored in this entry is scheduled for (re-) transmission following the above rules.
Ott, et. al. Informational [Page 19] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 19] RFC 3259 A Message Bus for Local Coordination April 2002
Constants and Algorithms: The following constants and algorithms
SHOULD be used by implementations:
Constants and Algorithms: The following constants and algorithms SHOULD be used by implementations:
T_r=100ms
T_r=100ms
N_r=3
N_r=3
T_c=70ms
T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r
T_k=((N_r)*(N_r+1)/2)*T_r
8. Awareness of other Entities
8. Awareness of other Entities
Before Mbus entities can communicate with one another, they need to mutually find out about their existence. After this bootstrap procedure that each Mbus entity goes through all other entities listening to the same Mbus know about the newcomer and the newcomer has learned about all the other entities. Furthermore, entities need to be able to to notice the failure (or leaving) of other entities.
Before Mbus entities can communicate with one another, they need to mutually find out about their existence. After this bootstrap procedure that each Mbus entity goes through all other entities listening to the same Mbus know about the newcomer and the newcomer has learned about all the other entities. Furthermore, entities need to be able to to notice the failure (or leaving) of other entities.
Any Mbus entity MUST announce its presence (on the Mbus) after starting up. This is to be done repeatedly throughout its lifetime to address the issues of startup sequence: Entities should always become aware of other entities independent of the order of starting.
Any Mbus entity MUST announce its presence (on the Mbus) after starting up. This is to be done repeatedly throughout its lifetime to address the issues of startup sequence: Entities should always become aware of other entities independent of the order of starting.
Each Mbus entity MUST maintain the number of Mbus session members and continuously update this number according to any observed changes. The mechanisms of how the existence and the leaving of other entities can be detected are dedicated Mbus messages for entity awareness: mbus.hello (Section 9.1) and mbus.bye (Section 9.2). Each Mbus protocol implementation MUST periodically send mbus.hello messages that are used by other entities to monitor the existence of that entity. If an entity has not received mbus.hello messages for a certain time (see Section 8.2) from an entity, the respective entity is considered to have left the Mbus and MUST be excluded from the set of currently known entities. Upon the reception of a mbus.bye message the respective entity is considered to have left the Mbus as well and MUST be excluded from the set of currently known entities immediately.
Each Mbus entity MUST maintain the number of Mbus session members and continuously update this number according to any observed changes. The mechanisms of how the existence and the leaving of other entities can be detected are dedicated Mbus messages for entity awareness: mbus.hello (Section 9.1) and mbus.bye (Section 9.2). Each Mbus protocol implementation MUST periodically send mbus.hello messages that are used by other entities to monitor the existence of that entity. If an entity has not received mbus.hello messages for a certain time (see Section 8.2) from an entity, the respective entity is considered to have left the Mbus and MUST be excluded from the set of currently known entities. Upon the reception of a mbus.bye message the respective entity is considered to have left the Mbus as well and MUST be excluded from the set of currently known entities immediately.
Each Mbus entity MUST send hello messages to the Mbus after startup. After transmission of the hello message, it MUST start a timer after the expiration of which the next hello message is to be transmitted. Transmission of hello messages MUST NOT be stopped unless the entity detaches from the Mbus. The interval for sending hello messages is dependent on the current number of entities in an Mbus group and can thus change dynamically in order to avoid congestion due to many entities sending hello messages at a constant high rate.
Each Mbus entity MUST send hello messages to the Mbus after startup. After transmission of the hello message, it MUST start a timer after the expiration of which the next hello message is to be transmitted. Transmission of hello messages MUST NOT be stopped unless the entity detaches from the Mbus. The interval for sending hello messages is dependent on the current number of entities in an Mbus group and can thus change dynamically in order to avoid congestion due to many entities sending hello messages at a constant high rate.
Ott, et. al. Informational [Page 20] RFC 3259 A Message Bus for Local Coordination April 2002
Ott, et. al. Informational [Page 20] RFC 3259 A Message Bus for Local Coordination April 2002
Section 8.1 specifies the calculation of hello message intervals that MUST be used by protocol implementations. Using the values that are calculated for obtaining the current hello message timer, the timeout for received hello messages is calculated in Section 8.2. Section 9 specifies the command synopsis for the corresponding Mbus messages.
Section 8.1 specifies the calculation of hello message intervals that MUST be used by protocol implementations. Using the values that are calculated for obtaining the current hello message timer, the timeout for received hello messages is calculated in Section 8.2. Section 9 specifies the command synopsis for the corresponding Mbus messages.
8.1 Hello Message Transmission Interval
8.1 Hello Message Transmission Interval
Since the number of entities in an Mbus session may vary, care must be taken to allow the Mbus protocol to automatically scale over a wide range of group sizes. The average rate at which hello messages are received would increase linearly to the number of entities in a session if the sending interval was set to a fixed value. Given an interval of 1 second this would mean that an entity taking part in an Mbus session with n entities would receive n hello messages per second. Assuming all entities resided on one host, this would lead to n*n messages that have to be processed per second -- which is obviously not a viable solution for larger groups. It is therefore necessary to deploy dynamically adapted hello message intervals, taking varying numbers of entities into account. In the following, we specify an algorithm that MUST be used by implementors to calculate the interval for hello messages considering the observed number of Mbus entities.
Since the number of entities in an Mbus session may vary, care must be taken to allow the Mbus protocol to automatically scale over a wide range of group sizes. The average rate at which hello messages are received would increase linearly to the number of entities in a session if the sending interval was set to a fixed value. Given an interval of 1 second this would mean that an entity taking part in an Mbus session with n entities would receive n hello messages per second. Assuming all entities resided on one host, this would lead to n*n messages that have to be processed per second -- which is obviously not a viable solution for larger groups. It is therefore necessary to deploy dynamically adapted hello message intervals, taking varying numbers of entities into account. In the following, we specify an algorithm that MUST be used by implementors to calculate the interval for hello messages considering the observed number of Mbus entities.
The algorithm features the following characteristics:
The algorithm features the following characteristics:
o The number of hello messages that are received by a single entity
in a certain time unit remains approximately constant as the
number of entities changes.
o The number of hello messages that are received by a single entity in a certain time unit remains approximately constant as the number of entities changes.
o The effective interval that is used by a specific Mbus entity is
randomized in order to avoid unintentional synchronization of
hello messages within an Mbus session. The first hello message of
an entity is also delayed by a certain random amount of time.
o The effective interval that is used by a specific Mbus entity is randomized in order to avoid unintentional synchronization of hello messages within an Mbus session. The first hello message of an entity is also delayed by a certain random amount of time.
o A timer reconsideration mechanism is deployed in order to adapt
the interval more appropriately in situations where a rapid change
of the number of entities is observed. This is useful when an
entity joins an Mbus session and is still learning of the
existence of other entities or when a larger number of entities
leaves the Mbus at once.
o A timer reconsideration mechanism is deployed in order to adapt the interval more appropriately in situations where a rapid change of the number of entities is observed. This is useful when an entity joins an Mbus session and is still learning of the existence of other entities or when a larger number of entities leaves the Mbus at once.
Ott, et. al. Informational [Page 21] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[21ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
8.1.1 Calculating the Interval for Hello Messages
8.1.1、間隔について計算する、こんにちは、メッセージ
The following variable names are used in the calculation specified below (all time values in milliseconds):
以下の変数名は(ミリセカンドで表現されるすべての時間的価値)の下で指定された計算に使用されます:
hello_p: The last time a hello message has been sent by a Mbus
entity.
_こんにちは、p: Mbus実体でこんにちはが通信する最後の時を送りました。
hello_now: The current time
_現在、こんにちは: 現在の時間
hello_d: The deterministic calculated interval between hello
messages.
こんにちは: 間の決定論的な計算された間隔、こんにちは、メッセージ。
hello_e: The effective (randomized) interval between hello messages.
_こんにちは、e: 間の(ランダマイズされます)間隔の有効である、こんにちは、メッセージ。
hello_n: The time for the next scheduled transmission of a hello
message.
こんにちは: 次がこんにちはのトランスミッションの計画をしたので、時間は通信します。
entities_p: The numbers of entities at the time hello_n has been last
recomputed.
実体_p: こんにちはように調節してください。実体の数、最後に再計算されました。
entities: The number of currently known entities.
実体: 現在知られている実体の数。
The interval between hello messages MUST be calculated as follows:
間の間隔、こんにちは、以下の通りメッセージについて計算しなければなりません:
The number of currently known entities is multiplied by c_hello_factor, yielding the interval between hello messages in milliseconds. This is the deterministic calculated interval, denoted hello_d. The minimum value for hello_d is c_hello_min which yields
c_が現在知られている実体の数に掛けられる、こんにちは、_間に間隔をもたらす要素、こんにちは、ミリセカンドで表現されるメッセージ。 これは、決定論的な計算された間隔であり、こんにちはを指示しました。 最小値、こんにちは、cが_である、こんにちは、もたらされる_分
hello_d = max(c_hello_min,c_hello_factor * entities * 1ms).
こんにちは、= 最大限にしてください、(c、__こんにちは、こんにちは、_分、c_要素*実体*1ms、)
Section 8 provides a specification of how to obtain the number of currently known entities. Section 10 provides values for the constants c_hello_factor and c_hello_min.
セクション8はどう現在知られている実体の数を得るかに関する仕様を提供します。 10が提供するセクションが、_こんにちは、定数cの_要素とc_のためにこんにちはを評価する、_分
The effective interval hello_e that is to be used by individual entities is calculated by multiplying hello_d with a randomly chosen number between c_hello_dither_min and c_hello_dither_max as follows:
_こんにちは、e、すなわちこんにちは、c_の間の数が手当たりしだいに選ばれていた状態でこんにちはを掛けながら個々の実体によって使用されるのが計算される、有効な間隔、_震え_分とc_、こんにちは、以下の_震え_最大:
hello_e = c_hello_dither_min +
RND * (c_hello_dither_max - c_hello_dither_min)
こんにちは、_e=c、_こんにちは、_震え_分+RND*(c_、こんにちは、_震え_最大--、c_、こんにちは、_震え_分)
with RND being a random function that yields an even distribution between 0 and 1. See also Section 10.
確率関数であるRNDで、それは0と1の間の同等の分配をもたらします。 また、セクション10を見てください。
hello_n, the time for the next hello message in milliseconds is set to hello_e + hello_now.
ミリセカンドで表現されるメッセージは_こんにちは、e+に設定されます。こんにちは、次のための時間、こんにちは、_現在、こんにちは。
Ott, et. al. Informational [Page 22] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[22ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
8.1.2 Initialization of Values
8.1.2 値の初期設定
Upon joining an Mbus session a protocol implementation sets hello_p=0, hello_now=0 and entities=1, entities_p=1 (the Mbus entity itself) and then calculates the time for the next hello message as specified in Section 8.1.1. The next hello message is scheduled for transmission at hello_n.
プロトコル実装が_こんにちは、p=0を設定する、こんにちはMbusセッションに参加すると、_が現在、0と実体=1、実体_p=1(Mbus実体自体)と等しく、次に、次のための時間について計算する、こんにちは、セクション8.1.1における指定されるとしてのメッセージ 次、こんにちは、メッセージがトランスミッションのために予定されている、こんにちは。
8.1.3 Adjusting the Hello Message Interval when the Number of Entities
increases
8.1.3 EntitiesのNumberが増加すると、Hello Message Intervalを調整します。
When the existence of a new entity is observed by a protocol implementation the number of currently known entities is updated. No further action concerning the calculation of the hello message interval is required. The reconsideration of the timer interval takes place when the current timer for the next hello message expires (see Section 8.1.5).
プロトコル実装で新しい実体の存在を観測するとき、現在知られている実体の数をアップデートします。 いいえが計算に関する動作を促進する、こんにちは、メッセージ間隔が必要です。 次のための現在のタイマであるときに、タイマ間隔の再考が行われる、こんにちは、メッセージは期限が切れます(セクション8.1.5を見てください)。
8.1.4 Adjusting the Hello Message Interval when the Number of Entities
decreases
8.1.4 EntitiesのNumberが減少すると、Hello Message Intervalを調整します。
Upon realizing that an entity has left the Mbus the number of currently known entities is updated and the following algorithm should be used to reconsider the timer interval for hello messages:
実体が現在知られている実体の数にMbusを残したとわかるのをアップデートして、以下のアルゴリズムがタイマ間隔を再考するのにおいて使用されているべきである、こんにちは、メッセージ:
1. The value for hello_n is updated by setting hello_n = hello_now +
(entities/entities_p)*(hello_n - hello_now)
1. 値、こんにちは、設定でアップデートする、こんにちは、等しさ、こんにちは、_+ 現在の(実体/実体_p)*(こんにちは--、こんにちは、現在の_)
2. The value for hello_p is updated by setting hello_p = hello_now -
(entities/entities_p)*(hello_now - hello_p)
2. _こんにちは、pのための値はこと= _現在、こんにちは--(実体/実体_p)*_こんにちは、pを設定することによってアップデートして、です。(_現在、こんにちは--_こんにちは、p)
3. The currently active timer for the next hello messages is
cancelled and a new timer is started for hello_n.
3. メッセージは取り消されます、そして、新しいタイマは出発されます。次のための現在アクティブなタイマ、こんにちは、こんにちは。
4. entities_p is set to entities.
4. 実体_pは実体に設定されます。
8.1.5 Expiration of hello timers
8.1.5 満了、こんにちは、タイマ
When the hello message timer expires, the protocol implementation MUST perform the following operations:
いつ、こんにちは、メッセージタイマは期限が切れて、プロトコル実装は以下の操作を実行しなければなりません:
The hello interval hello_e is computed as specified in Section
8.1.1.
こんにちは、こんにちは、_eが計算される間隔はセクション8.1で.1に指定しました。
1. IF hello_e + hello_p <= hello_now THEN a hello message is
transmitted. hello_p is set to hello_now, hello_e is
calculated again as specified in Section 8.1.1 and hello_n is
set to hello_e + hello_now.
1. _こんにちは、e+にはセットがあります。伝えられて. _こんにちは、pが_現在こんにちは、こんにちはが通信させる+ _こんにちは、_こんにちは、e p<=THENがそうであるならそうである、__現在こんにちは、こんにちは、eへのセットが再びセクション8.1.1で指定されるように計算されて、こんにちは、_現在、こんにちは。
Ott, et. al. Informational [Page 23] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[23ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
2. ELSE IF hello_e + hello_p > hello_now THEN hello_n is set to
hello_e + hello_p. A new timer for the next hello message is
started to expire at hello_n. No hello message is transmitted.
2. ELSE IF、+ _こんにちは、こんにちは、_e p>、_現在こんにちは、THEN、こんにちは、+ _こんにちは、_こんにちは、eへのセットはpですか? 次のための新しいタイマ、こんにちは、メッセージが期限が切れるために始められる、こんにちは。 いいえ、こんにちは、メッセージは送られます。
entities_p is set to entities.
実体_pは実体に設定されます。
8.2 Calculating the Timeout for Mbus Entities
8.2 Mbus実体のためのタイムアウトについて計算すること。
Whenever an Mbus entity has not heard for a time span of c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from another Mbus entity it may consider this entity to have failed (or have quit silently). The number of the currently known entities MUST be updated accordingly. See Section 8.1.4 for details. Note that no need for any further action is necessarily implied from this observation.
__こんにちは、Mbus実体がcのタイム・スパンに聞かれていないときはいつも、死者*、(hello_d*c_、こんにちは、_震え_最大) それが、この実体が失敗したと(または、静かに、やめました)考えるかもしれない別のMbus実体からのミリセカンド。 それに従って、現在知られている実体の数をアップデートしなければなりません。 詳細に関してセクション8.1.4を見てください。 どんなさらなる動作のどんな必要性もこの観測によって必ず暗示しているというわけではないことに注意してください。
Section 8.1.1 specifies how to obtain hello_d. Section 10 defines values for the constants c_hello_dead and c_hello_dither_max.
セクション8.1.1が得るためにその方法を指定する、こんにちは。 10が定義するセクションは、_こんにちは、定数cの死ぬ_とc_のためにこんにちはを評価します。_震え_最大。
9. Messages
9. メッセージ
This section defines some basic application-independent messages that MUST be understood by all implementations; these messages are required for proper operation of the Mbus. This specification does not contain application-specific messages. These are to be defined outside of the basic Mbus protocol specification in separate Mbus profiles.
このセクションはすべての実装に解釈しなければならないいくつかの基本のアプリケーションから独立しているメッセージを定義します。 これらのメッセージがMbusの適切な操作に必要です。 この仕様はアプリケーション特有のメッセージを含んでいません。 これらは別々のMbusプロフィールの基本のMbusプロトコル仕様の外で定義されることになっています。
9.1 mbus.hello
9.1 mbus.hello
Syntax:
mbus.hello()
構文: mbus.hello()
Parameters: - none -
パラメタ: - なにも、-
mbus.hello messages MUST be sent unreliably to all Mbus entities.
すべてのMbus実体にmbus.helloメッセージを当てにならずに送らなければなりません。
Each Mbus entity learns about other Mbus entities by observing their mbus.hello messages and tracking the sender address of each message and can thus calculate the current number of entities.
それぞれのMbus実体は、他のMbus実体に関してそれらのmbus.helloメッセージを観測して、それぞれのメッセージの送付者アドレスを追跡することによって学んで、その結果、実体の最新号について計算できます。
mbus.hello messages MUST be sent periodically in dynamically calculated intervals as specified in Section 8.
セクション8における指定されるとしてのダイナミックに計算された間隔で定期的にmbus.helloメッセージを送らなければなりません。
Upon startup the first mbus.hello message MUST be sent after a delay hello_delay, where hello_delay be a randomly chosen number between 0 and c_hello_min (see Section 10).
遅れの後に始動のときに最初のmbus.helloメッセージを送らなければならない、こんにちは、_遅れ、どこ、こんにちは、_0とcの間の手当たりしだいに選ばれた数が_であったなら延着してくださいか、こんにちは、_分(セクション10を見ます)。
Ott, et. al. Informational [Page 24] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[24ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
9.2 mbus.bye
9.2 mbus.bye
Syntax: mbus.bye()
構文: mbus.bye()
Parameters: - none -
パラメタ: - なにも、-
An Mbus entity that is about to terminate (or "detach" from the Mbus) SHOULD announce this by transmitting an mbus.bye message. The mbus.bye message MUST be sent unreliably to all entities.
終わろうとしている(または、Mbusからの「取り外し」)ために、SHOULDがmbus.byeメッセージを送ることによってこれを発表するということであるMbus実体。 mbus.byeメッセージをすべての実体に当てにならずに送らなければなりません。
9.3 mbus.ping
9.3 mbus.ping
Syntax: mbus.ping()
構文: mbus.ping()
Parameters: - none -
パラメタ: - なにも、-
mbus.ping can be used to solicit other entities to signal their existence by replying with an mbus.hello message. Each protocol implementation MUST understand mbus.ping and reply with an mbus.hello message. The reply hello message MUST be delayed for hello_delay milliseconds, where hello_delay be a randomly chosen number between 0 and c_hello_min (see Section 10). Several mbus.ping messages MAY be answered by a single mbus.hello: if one or more further mbus.ping messages are received while the entity is waiting hello_delay time units before transmitting the mbus.hello message, no extra mbus.hello message need be scheduled for those additional mbus.ping messages.
mbus.helloメッセージで返答することによってそれらの存在に合図するために他の実体に請求するのにmbus.pingを使用できます。 それぞれのプロトコル実装は、mbus.helloメッセージでmbus.pingを理解して、返答しなければなりません。 こんにちはと返答してください、メッセージを遅らせなければならない、こんにちは、_ミリセカンドを遅らせてください、どこ、こんにちは、_0とcの間の手当たりしだいに選ばれた数が_であったなら延着してくださいか、こんにちは、_分(セクション10を見ます)。 いくつかのmbus.pingメッセージが単一のmbus.helloによって答えられるかもしれません: mbus.helloメッセージを送る_遅延時間ユニット前にこんにちは、実体が待っている間、さらなる1つ以上のmbus.pingメッセージが受信されているなら、どんな付加的なmbus.helloメッセージもそれらの追加mbus.pingメッセージのために予定される必要はありません。
As specified in Section 9.1 hello messages MUST be sent unreliably to all Mbus entities. This is also the case for replies to ping messages. An entity that replies to mbus.ping with mbus.hello SHOULD stop any outstanding timers for hello messages after sending the hello message and schedule a new timer event for the subsequent hello message. (Note that using the variables and the algorithms of Section 8.1.1 this can be achieved by setting hello_p to hello_now.)
セクション9.1でこんにちはと指定するとき、すべてのMbus実体にメッセージを当てにならずに送らなければなりません。 また、これは回答がメッセージを確認するそうです。 mbus.hello SHOULDとmbus.pingへの回答がどんな傑出しているタイマも止める実体、こんにちは、発信した後のメッセージ、こんにちは、その後のために新しいタイマイベントの通信して、計画をしてください、こんにちは、メッセージ。 (セクション8.1.1の変数とアルゴリズムを使用して、_こんにちは、pを設定することによってこれを達成できることに注意してください、こんにちは、現在の_)。
mbus.ping allows a new entity to quickly check for other entities without having to wait for the regular individual hello messages. By specifying a target address the new entity can restrict the solicitation for hello messages to a subset of entities it is interested in.
mbus.pingは他の実体がないかどうかレギュラーの個人を待つ必要はなくてこんにちはを新しい実体をすぐにチェックさせます。メッセージ。 新しい実体が懇願を制限する場合があるあて先アドレスを指定する、こんにちは、それが興味を持っている実体の部分集合へのメッセージ。
Ott, et. al. Informational [Page 25] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[25ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
9.4 mbus.quit
9.4 mbus.quit
Syntax:
mbus.quit()
構文: mbus.quit()
Parameters: - none -
パラメタ: - なにも、-
The mbus.quit message is used to request other entities to terminate themselves (and detach from the Mbus). Whether this request is honoured by receiving entities or not is application specific and not defined in this document.
mbus.quitメッセージが自分たちを終えるために他の実体を要求するのに使用される、(Mbusからの取り外し、) この要求が実体を受けることによって尊敬されるかどうかが、特定の、そして、本書では定義されなかったアプリケーションです。
The mbus.quit message can be multicast or sent reliably via unicast to a single Mbus entity or a group of entities.
mbus.quitメッセージは、マルチキャストであることができるかただ一つのMbus実体か実体のグループへのユニキャストで確かに発信しました。
9.5 mbus.waiting
9.5 mbus.waiting
Syntax:
mbus.waiting(condition)
構文: mbus.waiting(状態)
Parameters:
パラメタ:
symbol condition
The condition parameter is used to indicate that the entity
transmitting this message is waiting for a particular event to
occur.
状態パラメタがこのメッセージを送る実体が、特定のイベントが起こるのを待っているのを示すのに使用されるというシンボル条件。
An Mbus entity SHOULD be able to indicate that it is waiting for a certain event to happen (similar to a P() operation on a semaphore but without creating external state somewhere else). In conjunction with this, an Mbus entity SHOULD be capable of indicating to another entity that this condition is now satisfied (similar to a semaphore's V() operation).
Mbus実体SHOULD、あるイベントが起こるのを待っているのを示すことができてください(腕木信号機にもかかわらず、外部の状態を他のどこかに創設しないての進行中のP()操作と同様の)。 これに関連したMbus実体SHOULD、この状態が現在満たされているのを別の実体に示すことができてください(腕木信号機のV()操作と同様の)。
The mbus.waiting message MAY be broadcast to all Mbus entities, MAY be multicast to an arbitrary subgroup, or MAY be unicast to a particular peer. Transmission of the mbus.waiting message MUST be unreliable and hence MUST be repeated at an application-defined interval (until the condition is satisfied).
mbus.waitingメッセージは、すべてのMbus実体に放送されるかもしれないか、任意のサブグループへのマルチキャストであるかもしれない、または特定の同輩へのユニキャストであるかもしれません。 mbus.waitingメッセージの伝達を頼り無くなければならなく、したがって、アプリケーションで定義された間隔で、繰り返さなければなりません(状態が満たされるまで)。
If an application wants to indicate that it is waiting for several conditions to be met, several mbus.waiting messages are sent (possibly included in the same Mbus payload). Note that mbus.hello and mbus.waiting messages may also be transmitted in a single Mbus payload.
アプリケーションが、いくつかの会われるべき状態を待っているのを示したいなら、いくつかのmbus.waitingメッセージを送ります(ことによると同じMbusペイロードに含まれています)。 また、mbus.helloとmbus.waitingメッセージがただ一つのMbusペイロードで送られるかもしれないことに注意してください。
Ott, et. al. Informational [Page 26] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[26ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
9.6 mbus.go
9.6 mbus.go
Syntax:
mbus.go(condition)
構文: mbus.go(状態)
Parameters:
パラメタ:
symbol condition
This parameter specifies which condition is met.
シンボル状態Thisパラメタは、どの条件が満たされるかを指定します。
The mbus.go message is sent by an Mbus entity to "unblock" another Mbus entity -- which has indicated that it is waiting for a certain condition to be met. Only a single condition can be specified per mbus.go message. If several conditions are satisfied simultaneously multiple mbus.go messages MAY be combined in a single Mbus payload.
"非ブロック"への別のMbus実体(会われるべきある状態を待っているのを示した)ごとにmbus.goメッセージに送ります。 mbus.goメッセージ単位でただ一つの状態しか指定できません。 いくつかの状態が同時に満たされているなら、複数のmbus.goメッセージがただ一つのMbusペイロードで結合されるかもしれません。
The mbus.go message MUST be sent reliably via unicast to the Mbus entity to unblock.
mbus.goメッセージを非ブロックにMbus実体へのユニキャストで確かに送らなければなりません。
10. Constants
10. 定数
The following values for timers and counters mentioned in this document SHOULD be used by implementations:
タイマとカウンタへの以下の値は、このドキュメントSHOULDで実装によって使用されるように言及しました:
+-------------------+------------------------+--------------+
|Timer / Counter | Value | Unit |
+-------------------+------------------------+--------------+
|c_hello_factor | 200 | - |
|c_hello_min | 1000 | milliseconds |
|c_hello_dither_min | 0.9 | - |
|c_hello_dither_max | 1.1 | - |
|c_hello_dead | 5 | - |
+-------------------+------------------------+--------------+
+-------------------+------------------------+--------------+ |タイマ/カウンタ| 値| ユニット| +-------------------+------------------------+--------------+ |c_、こんにちは、_要素| 200 | - | |c_、こんにちは、_分| 1000 | ミリセカンド| |c_、こんにちは、_震え_分| 0.9 | - | |c_、こんにちは、_震え_最大| 1.1 | - | |c、__こんにちは、死者| 5 | - | +-------------------+------------------------+--------------+
T_r=100ms
T_r=100ms
N_r=3
N_r=3
T_c=70ms
T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r
T_kは*T_rと等しいです(N_r)*(N_r+1)/2)。
Ott, et. al. Informational [Page 27] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[27ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
11. Mbus Security
11. Mbusセキュリティ
11.1 Security Model
11.1 機密保護モデル
In order to prevent accidental or malicious disturbance of Mbus communications through messages originated by applications from other users, message authentication is deployed (Section 11.3). For each message, a digest MUST be calculated based on the value of a shared secret key value. Receivers of messages MUST check if the sender belongs to the same Mbus security domain by re-calculating the digest and comparing it to the received value. The messages MUST only be processed further if both values are equal. In order to allow different simultaneous Mbus sessions at a given scope and to compensate defective implementations of host local multicast, message authentication MUST be provided by conforming implementations.
他のユーザからのアプリケーションで溯源されたメッセージを通したMbusコミュニケーションの偶然の、または、悪意がある騒動を防ぐために、通報認証は(セクション11.3)であると配布されます。 各メッセージに関しては、共有秘密キーキー値の値に基づいてダイジェストについて計算しなければなりません。 メッセージの受信機は、送付者がダイジェストについて再計算して、容認された値とそれを比較することによって同じMbusセキュリティー領域に属すかどうかチェックしなければなりません。 両方の値が等しいなら、さらにメッセージを処理するだけでよいです。 与えられた範囲に異なった同時のMbusセッションを許容して、地方のマルチキャスト、通報認証がそうしなければならないホストの欠陥がある実装を代償するには、実装を従わせることによって、提供してください。
Privacy of Mbus message transport can be achieved by optionally using symmetric encryption methods (Section 11.2). Each message MAY be encrypted using an additional shared secret key and a symmetric encryption algorithm. Encryption is OPTIONAL for applications, i.e., it is allowed to configure an Mbus domain not to use encryption. But conforming implementations MUST provide the possibility to use message encryption (see below).
任意に、左右対称の暗号化メソッド(セクション11.2)を使用することによって、Mbusメッセージ転送のプライバシーを達成できます。 追加共有された秘密鍵と左右対称の暗号化アルゴリズムを使用することで暗号化されていて、各メッセージはそうするかもしれません。 暗号化がアプリケーションのためのOPTIONALである、すなわち、それは暗号化を使用しないようにMbusドメインを構成できます。 しかし、実装を従わせると、メッセージ暗号化を使用する可能性は提供されなければなりません(以下を見てください)。
Message authentication and encryption can be parameterized: the algorithms to apply, the keys to use, etc. These and other parameters are defined in an Mbus configuration object that is accessible by all Mbus entities that participate in an Mbus session. In order to achieve interoperability conforming implementations SHOULD use the values provided by such an Mbus configuration. Section 12 defines the mandatory and optional parameters as well as storage procedures for different platforms. Only in cases where none of the options mentioned in Section 12 is applicable alternative methods of configuring Mbus protocol entities MAY be deployed.
通報認証と暗号化をparameterizedされることができます: 適用するアルゴリズム、使用のキーなど これらと他のパラメタはMbusセッションのときに参加するすべてのMbus実体でアクセスしやすいMbus構成オブジェクトで定義されます。 相互運用性の従うことを達成するために、実装SHOULDはそのようなMbus構成によって提供された値を使用します。 セクション12は異なったプラットホームへのストレージ手順と同様に義務的で任意のパラメタを定義します。場合だけでは、セクション12で言及されたオプションのいずれかがどこのMbusプロトコル実体を構成する適切な別法でないかは配布されるかもしれません。
The algorithms and procedures for applying encryption and authentication techniques are specified in the following sections.
暗号化と認証のテクニックを適用するためのアルゴリズムと手順は以下のセクションで指定されます。
11.2 Encryption
11.2 暗号化
Encryption of messages is OPTIONAL, that means, an Mbus MAY be configured not to use encryption.
それは、メッセージの暗号化がOPTIONALであることを意味して、Mbusは、暗号化を使用しないように構成されるかもしれません。
Ott, et. al. Informational [Page 28] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[28ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
Implementations can choose between different encryption algorithms. Every conforming implementation MUST provide the AES [18] algorithm. In addition, the following algorithms SHOULD be supported: DES [16], 3DES (triple DES) [16] and IDEA [20].
実装は異なった暗号化アルゴリズムを選ぶことができます。あらゆる従う実装がAES[18]アルゴリズムを提供しなければなりません。 追加、以下のアルゴリズムSHOULD、サポートされてください: DES[16]、3DES(三重のDES)[16]、および考え[20]。
For algorithms requiring en/decryption data to be padded to certain boundaries octets with a value of 0 SHOULD be used for padding characters.
アン/復号化データが0SHOULDの値で、ある境界八重奏に水増しされるのを必要とするアルゴリズムには、暫定記号にとって、使用されてください。
The length of the encryption keys is determined by the currently used encryption algorithm. This means, the configured encryption key MUST NOT be shorter than the native key length for the currently configured algorithm.
暗号化キーの長さは現在中古の暗号化アルゴリズムで測定されます。 この手段、構成された暗号化キーは現在構成されたアルゴリズムの割にはネイティブのキー長より短いはずがありません。
DES implementations MUST use the DES Cipher Block Chaining (CBC) mode. DES keys (56 bits) MUST be encoded as 8 octets as described in RFC 1423 [12], resulting in 12 Base64-encoded characters. IDEA uses 128-bit keys (24 Base64-encoded characters). AES can use either 128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES only 128-bit keys (24 Base64-encoded characters) MUST be used.
DES実装はDES Cipher Block Chaining(CBC)モードを使用しなければなりません。 RFC1423[12]で説明される8つの八重奏としてDESキー(56ビット)をコード化しなければなりません、12のBase64によってコード化されたキャラクタをもたらして。 IDEAは128ビットのキー(24のBase64によってコード化されたキャラクタ)を使用します。 AESは128ビットと、192ビットの、または、256ビットのキーを使用できます。 AESだけを使用するMbus暗号化のために、128ビットのキー(24のBase64によってコード化されたキャラクタ)を使用しなければなりません。
11.3 Message Authentication
11.3 通報認証
For authentication of messages, hashed message authentication codes (HMACs) as described in RFC 2104 [5] are deployed. In general, implementations can choose between a number of digest algorithms. For Mbus authentication, the HMAC algorithm MUST be applied in the following way:
メッセージの認証において、RFC2104[5]で説明される論じ尽くされたメッセージ確認コード(HMACs)は配布されます。 一般に、実装は多くのダイジェストアルゴリズムを選ぶことができます。Mbus認証において、HMACアルゴリズムを以下の方法で適用しなければなりません:
The keyed hash value is calculated using the HMAC algorithm
specified in RFC 2104 [5]. The specific hash algorithm and the
secret hash key MUST be obtained from the Mbus configuration (see
Section 12).
合わせられたハッシュ値は、RFC2104[5]で指定されたHMACアルゴリズムを使用することで計算されます。 Mbus構成から特定のハッシュアルゴリズムと秘密のナンバー記号のキーを入手しなければなりません(セクション12を見てください)。
The keyed hash values (see RFC 2104 [5]) MUST be truncated to 96
bits (12 octets).
合わせるのは値を論じ尽くします。(96ビット(12の八重奏)にRFC2104[5])に先端を切らせなければならないのを確実にしてください。
Subsequently, the resulting 12 octets MUST be Base64-encoded,
resulting in 16 Base64-encoded characters (see RFC 1521 [7]).
16のBase64によってコード化されたキャラクタをもたらして、次に、結果として起こる12の八重奏がBase64はコード化していなければなりません。(RFC1521[7])を見てください。
Either MD5 [15] or SHA-1 [17] SHOULD be used for message authentication codes (MACs). An implementation MAY provide MD5, whereas SHA-1 MUST be implemented.
MD5[15]かSHA-1[17]SHOULDのどちらか、メッセージ確認コード(MACs)のために、使用されてください。 ところが、実装がMD5を提供するかもしれない、SHA-1 MUST、実装されてください。
The length of the hash keys is determined by the selected hashing algorithm. This means, the configured hash key MUST NOT be shorter than the native key length for the currently configured algorithm.
ナンバー記号のキーの長さは選択された論じ尽くすアルゴリズムで測定されます。 この手段、構成されたナンバー記号のキーは現在構成されたアルゴリズムの割にはネイティブのキー長より短いはずがありません。
Ott, et. al. Informational [Page 29] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[29ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
11.4 Procedures for Senders and Receivers
送付者と受信機のための11.4の手順
The algorithms that MUST be provided by implementations are AES and SHA-1.
実装で提供しなければならないアルゴリズムは、AESとSHA-1です。
See Section 12 for a specification of notations for Base64-strings.
記法の仕様に関してBase64-ストリングに関してセクション12を見てください。
A sender MUST apply the following operations to a message that is to be sent:
送付者は送られることになっているメッセージに以下の操作を適用しなければなりません:
1. If encryption is enabled, the message MUST be encrypted using the
configured algorithm and the configured encryption key. Padding
(adding extra-characters) for block-ciphers MUST be applied as
specified in Section 11.2. If encryption is not enabled, the
message is left unchanged.
1. 暗号化が可能にされるなら、構成されたアルゴリズムと構成された暗号化キーを使用して、メッセージを暗号化しなければなりません。 セクション11.2で指定されるように適用されていて、ブロック暗号のためにそっと歩くのは(付加的なキャラクタを加えます)そうしなければなりません。 暗号化が可能にされないなら、メッセージは変わりがないままにされます。
2. Subsequently, a message authentication code (MAC) for the
(encrypted) message MUST be calculated using the configured HMAC-
algorithm and the configured hash key.
2. 次に、構成されたHMACアルゴリズムと構成されたナンバー記号のキーを使用して、(暗号化される)のメッセージのためのメッセージ確認コード(MAC)について計算しなければなりません。
3. The MAC MUST then be converted to Base64 encoding, resulting in 16
Base64-characters as specified in Section 11.3.
3. そして、セクション11.3における指定されるとしての16のBase64-キャラクタをもたらして、Base64コード化にMacを変換しなければなりません。
4. At last, the sender MUST construct the final message by placing
the (encrypted) message after the base64-encoded MAC and a CRLF.
The ABNF definition for the final message is as follows:
4. ついに、送付者は、base64によってコード化されたMACとCRLFの後に(暗号化される)のメッセージを置くことによって、最終的なメッセージを構成しなければなりません。 最終的なメッセージのためのABNF定義は以下の通りです:
final_msg = MsgDigest CRLF encr_msg
最終的な_msg=MsgDigest CRLF encr_msg
MsgDigest = base64
MsgDigestはbase64と等しいです。
encr_msg = *OCTET
encr_msgは*OCTETと等しいです。
A receiver MUST apply the following operations to a message that it has received:
受信機は以下の操作を受信したというメッセージに適用しなければなりません:
1. Separate the base64-encoded MAC from the (encrypted) message and
decode the MAC.
1. (暗号化される)のメッセージとbase64によってコード化されたMACを切り離してください、そして、MACを解読してください。
2. Re-calculate the MAC for the message using the configured HMAC-
algorithm and the configured hash key.
2. メッセージのために構成されたHMACアルゴリズムと構成されたナンバー記号のキーを使用することでMACについて再計算してください。
3. Compare the original MAC with re-calculated MAC. If they differ,
the message MUST be discarded without further processing.
3. 再計算されたMACとオリジナルのMACを比べてください。 彼らが異なるなら、さらなる処理なしでメッセージを捨てなければなりません。
4. If encryption is enabled, the message MUST be decrypted using the
configured algorithm and the configured encryption key. Trailing
octets with a value of 0 MUST be deleted. If the message does not
4. 暗号化が可能にされるなら、構成されたアルゴリズムを使用して、構成された暗号化キーであるとメッセージを解読しなければなりません。 0の値がある引きずっている八重奏を削除しなければなりません。 メッセージがそうしないなら
Ott, et. al. Informational [Page 30] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[30ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
start with the string "mbus/" the message MUST be discarded
without further processing.
さらに処理しないメッセージが捨てなければならないストリング「mbus/」から始めてください。
12. Mbus Configuration
12. Mbus構成
An implementation MUST be configurable by the following parameters:
実装は以下のパラメタで構成可能であるに違いありません:
Configuration version
構成バージョン
The version number of the given configuration entity. Version
numbers allow implementations to check if they can process the
entries of a given configuration entity. Version number are
integer values. The version number for the version specified
here is 1.
与えられた構成実体のバージョン番号。 バージョン番号で、実装は、それらが与えられた構成実体のエントリーを処理できるかどうかチェックできます。 バージョン番号は整数値です。 ここで指定されたバージョンのバージョン番号は1です。
Encryption key
暗号化キー
The secret key used for message encryption.
メッセージ暗号化に使用される秘密鍵。
Hash key
ナンバー記号のキー
The hash key used for message authentication.
ナンバー記号のキーはメッセージに認証を使用しました。
Scope
範囲
The multicast scope to be used for sent messages.
使用されるマルチキャスト範囲はメッセージを送りました。
The above parameters are mandatory and MUST be present in every Mbus configuration entity.
上記のパラメタは、義務的であり、あらゆるMbus構成実体で存在していなければなりません。
The following parameters are optional. When they are present they MUST be honored. When they are not present implementations SHOULD fall back to the predefined default values (as defined in Transport (Section 6)):
以下のパラメタは任意です。 存在しているとき、それらは光栄に思っているに違いありません。 それらが存在していないとき、実装SHOULDは事前に定義されたデフォルト値へ後ろへ下がります(Transport(セクション6)で定義されるように):
Address
アドレス
The non-standard multicast address to use for message
transport.
メッセージ転送に使用する標準的でないマルチキャストアドレス。
Use of Broadcast
放送の使用
It can be specified whether broadcast should be used. If
broadcast has been configured implementations SHOULD use the
network broadcast address (as specified in Section 6.1.3)
instead of the standard multicast address.
放送が使用されるべきであるかどうか指定できます。 放送が構成されたなら、実装SHOULDは標準のマルチキャストアドレスの代わりにネットワーク放送アドレスを使用します(セクション6.1.3で指定されるように)。
Ott, et. al. Informational [Page 31] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[31ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
Port Number
ポートナンバー
The non-standard UDP port number to use for message transport.
標準的でないUDPはメッセージ転送に使用する数を移植します。
Two distinct facilities for parameter storage are considered: For Unix-like systems a per-user configuration file SHOULD be used and for Windows-95/98/NT/2000/XP systems a set of registry entries is defined that SHOULD be used. For other systems it is RECOMMENDED that the file-based configuration mechanism is used.
パラメタストレージのための2つの異なった施設が考えられます: 1ユーザあたりのUnixのようなシステムa構成ファイルに関して、SHOULDは使用されて、aが設定した登録エントリーのWindows-95/98/NT/2000/XPシステムのために定義されます。SHOULDは使用されます。 他のシステムのために、ファイルベースの構成メカニズムが使用されているのは、RECOMMENDEDです。
The syntax of the values for the respective parameter entries remains the same for both configuration facilities. The following defines a set of ABNF (see RFC 2234 [13]) productions that are later re-used for the definitions for the configuration file syntax and registry entries:
それぞれのパラメタエントリーへの値の構文は両方の構成施設に同じままで残っています。 以下はABNFの1セットを定義します。(後で構成ファイル構文と登録エントリーのための定義に再使用されるRFC2234[13])創作を見てください:
algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
"HMAC-MD5-96" / "HMAC-SHA1-96"
痛イド="NOENCR"/「AES」/「デス」/「3DES」/「IDEA」/、「HMAC-MD5-96インチの/の「HMAC-SHA1-96インチ」
scope = "HOSTLOCAL" / "LINKLOCAL"
範囲は"HOSTLOCAL"/"LINKLOCAL"と等しいです。
key = base64
主要な=base64
version_number = 1*10DIGIT
バージョン_数は1*10DIGITと等しいです。
key_value = "(" algo-id "," key ")"
「主要な_値が等しい、「(」 「痛イド」、キー、」、)、」
address = IPv4address / IPv6address / "BROADCAST"
アドレス=IPv4address / IPv6address /「放送」
port = 1*5DIGIT ; values from 0 through 65535
ポートは1*5DIGITと等しいです。 0〜65535の値
Given the definition above, a key entry MUST be specified using this notation:
定義を考えて、この記法を使用して、上では、打鍵入力を指定しなければなりません:
"("algo-id","base64string")"
「(「痛イド」、"base64string")」
algo-id is one of the character strings specified above. For algo- id=="NOENCR" the other fields are ignored. The delimiting commas MUST always be present though.
痛イドは上で指定された文字列の1つです。 痛イド="NOENCR"において、他の分野は無視されます。 もっとも、区切りコンマはいつも存在していなければなりません。
A Base64 string consists of the characters defined in the Base64 char-set (see RFC 1521 [7]) including all possible padding characters, i.e., the length of a Base64-string is always a multiple of 4.
Base64炭セットで定義されて、Base64ストリングはキャラクタから成ります。(Base64-ストリングについて可能な暫定記号、すなわち、すべての長さを含むRFC1521[7])がいつも4の倍数であることを確実にしてください。
The scope parameter is used to configure an IP-Multicast scope and may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations SHOULD choose an appropriate IP-Multicast scope depending on the
範囲パラメタは、IP-マルチキャスト範囲を構成するのに使用されて、"HOSTLOCAL"か"LINKLOCAL"のどちらかに設定されるかもしれません。 実装SHOULDは適切なIP-マルチキャスト範囲依存を選びます。
Ott, et. al. Informational [Page 32] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[32ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
value of this parameter and construct an effective IP-Address considering the specifications of Section 6.1.
このパラメタと構造物セクションの仕様を考える有効なIP-アドレス6.1の値。
The use of broadcast is configured by providing the value "BROADCAST" for the address field. If broadcast has been configured, implementations SHOULD use the network broadcast address for the used IP version instead of the standard multicast address.
放送の使用は、アドレス・フィールドのための値の「放送」を提供することによって、構成されます。 放送が構成されたなら、実装SHOULDは標準のマルチキャストアドレスの代わりに中古のIPバージョンにネットワーク放送アドレスを使用します。
The version_number parameter specifies a version number for the used configuration entity.
バージョン_数のパラメタは中古の構成実体のバージョン番号を指定します。
12.1 File based parameter storage
12.1ファイルはパラメタストレージを基礎づけました。
The file name for an Mbus configuration file is ".mbus" in the user's home-directory. If an environment variable called MBUS is defined implementations SHOULD interpret the value of this variable as a fully qualified file name that is to be used for the configuration file. Implementations MUST ensure that this file has appropriate file permissions that prevent other users to read or write it. The file MUST exist before a conference is initiated. Its contents MUST be UTF-8 encoded and MUST comply to the following syntax definition:
Mbus構成ファイルのためのファイル名はユーザのホームディレクトリの".mbus"です。 MBUSと呼ばれる環境変数が定義されるなら、実装SHOULDは構成ファイルに使用されることになっている完全に適切なファイル名としてこの変数の値を解釈します。 実装は、このファイルにはそれを読むか、または書くために他のユーザを防ぐ適切なファイル許容があるのを確実にしなければなりません。 会議が開始される前にファイルは存在しなければなりません。 コンテンツは、コード化されたUTF-8でなければならなく、以下の構文定義に応じなければなりません:
mbus-file = mbus-topic LF *(entry LF)
mbus-ファイル=mbus-話題LF*(エントリーLF)
mbus-topic = "[MBUS]"
「[MBUS]」というmbus-話題=
entry = 1*(version_info / hashkey_info
/ encryptionkey_info / scope_info
/ port_info / address_info)
エントリーは1*と等しいです。(バージョン_インフォメーション/hashkey_インフォメーション/encryptionkey_インフォメーション/範囲_インフォメーション/港の_インフォメーション/アドレス_インフォメーション)
version_info = "CONFIG_VERSION=" version_number
バージョン_インフォメーションは「コンフィグ_バージョン=」バージョン_番号と等しいです。
hashkey_info = "HASHKEY=" key_value
hashkey_インフォメーションは「HASHKEY=」主要な_価値と等しいです。
encrkey_info = "ENCRYPTIONKEY=" key_value
encrkey_インフォメーションは「ENCRYPTIONKEY=」主要な_価値と等しいです。
scope_info = "SCOPE=" scope
範囲_インフォメーションは「範囲=」範囲と等しいです。
port_info = "PORT=" port
ポート_インフォメーションは「ポート=」ポートと等しいです。
address_info = "ADDRESS=" address
アドレス_インフォメーションは「アドレス=」というアドレスと等しいです。
The following entries are defined: CONFIG_VERSION, HASHKEY, ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.
以下のエントリーは定義されます: _バージョン、HASHKEY、ENCRYPTIONKEY、範囲が移植するコンフィグ、アドレス。
The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory, they MUST be present in every Mbus configuration file. The order of entries is not significant.
エントリーCONFIG_バージョン、HASHKEY、およびENCRYPTIONKEYが義務的である、それらはあらゆるMbus構成ファイルに存在していなければなりません。 エントリーの注文は重要ではありません。
Ott, et. al. Informational [Page 33] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[33ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
An example for an Mbus configuration file:
Mbus構成ファイルのための例:
[MBUS]
CONFIG_VERSION=1
HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy)
ENCRYPTIONKEY=(DES,MTIzMTU2MQ==)
SCOPE=HOSTLOCAL
ADDRESS=224.255.222.239
PORT=47000
224.255.222.239ポート=[MBUS]コンフィグ_バージョン=1HASHKEY=(HMAC-MD5-96、MTIzMTU2MTg5MTEy)ENCRYPTIONKEY=(DES、MTIzMTU2MQ=)範囲=HOSTLOCALアドレス=47000
12.2 Registry-based parameter storage
12.2 登録ベースのパラメタストレージ
For systems lacking the concept of a user's home-directory as a place for configuration files the suggested database for configuration settings (e.g., the Windows9x, Windows NT, Windows 2000, Windows XP registry) SHOULD be used. The hierarchy for Mbus related registry entries is as follows:
ユーザのホームディレクトリの概念を欠いているシステム、構成ファイルの場とした構成設定(例えば、Windows9x、Windows NT、Windows2000、Windows XP登録)SHOULDのための提案されたデータベース、使用されてください。 Mbusの関連する登録エントリーへの階層構造は以下の通りです:
HKEY_CURRENT_USER\Software\Mbus
HKEYの_の現在の_ユーザ\ソフトウェア\Mbus
The entries in this hierarchy section are:
この階層構造部でのエントリーは以下の通りです。
+---------------+--------+----------------+
|Name | Type | ABNF production|
+---------------+--------+----------------|
|CONFIG_VERSION | DWORD | version_number |
|HASHKEY | String | key_value |
|ENCRYPTIONKEY | String | key_value |
|SCOPE | String | scope |
|ADDRESS | String | address |
|PORT | DWORD | port |
+---------------+--------+----------------+
+---------------+--------+----------------+ |名前| タイプ| ABNF生産| +---------------+--------+----------------| |コンフィグ_バージョン| DWORD| バージョン_数| |HASHKEY| ストリング| 主要な_値| |ENCRYPTIONKEY| ストリング| 主要な_値| |範囲| ストリング| 範囲| |アドレス| ストリング| アドレス| |ポート| DWORD| ポート| +---------------+--------+----------------+
The same syntax for key values as for the file based configuration facility MUST be used.
ファイルのようなキー値が構成施設を基礎づけたので、同じ構文を使用しなければなりません。
13. Security Considerations
13. セキュリティ問題
The Mbus security mechanisms are specified in Section 11.1.
Mbusセキュリティー対策はセクション11.1で指定されます。
It should be noted that the Mbus transport specification defines a mandatory baseline set of algorithms that have to be supported by implementations. This baseline set is intended to provide reasonable security by mandating algorithms and key lengths that are considered to be cryptographically strong enough at the time of writing.
Mbus輸送仕様が実装によってサポートされなければならない義務的な基線セットのアルゴリズムを定義することに注意されるべきです。 この基線セットが書くこと時点で十分強い状態で暗号でである考えられるアルゴリズムとキー長を強制することによって手頃なセキュリティを提供することを意図します。
However, in order to allow for efficiency it is allowable to use cryptographically weaker algorithms, for example HMAC-MD5 instead of
の代わりにするしかしながら、暗号でより弱いアルゴリズム、例えばHMAC-MD5を使用するのが効率を考慮するために許容できる。
Ott, et. al. Informational [Page 34] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[34ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
HMAC-SHA1. Furthermore, encryption can be turned off completely if privacy is provided by other means or not considered important for a certain application.
HMAC-SHA1。 その上、完全に、プライバシーを他の手段で前提とするか、またはあるアプリケーションに重要であると考えないなら、暗号化をオフにすることができます。
Users of the Mbus should therefore be aware of the selected security configuration and should check if it meets the security demands for a given application. Since every implementation MUST provide the cryptographically strong algorithm it should always be possible to configure an Mbus in a way that secure communication with authentication and privacy is ensured.
Mbusのユーザは、したがって、選択されたセキュリティ設定を意識しているべきであり、それが与えられたアプリケーションの治安上の要求を満たすかどうかチェックするべきです。 以来にあらゆる実装が提供されなければならない、暗号で、強いアルゴリズム、認証とプライバシーとの安全なコミュニケーションが確実にされる方法でMbusを構成するのはいつも可能であるべきです。
In any way, application developers should be aware of incorrect IP implementations that do not conform to RFC 1122 [2] and do send datagrams with TTL values of zero, resulting in Mbus messages sent to the local network link although a user might have selected host local scope in the Mbus configuration. When using administratively scoped multicast, users cannot always assume the presence of correctly configured boundary routers. In these cases the use of encryption SHOULD be considered if privacy is desired.
何らかの方法で、アプリケーション開発者が1122[2]をRFCに従わせないで、ゼロのTTL値と共にデータグラムを送る不正確なIP実装を意識しているべきである、なって、ユーザはホストを選んだかもしれませんが、Mbusメッセージでは、Mbus構成の地方の範囲は企業内情報通信網リンクに発信していました。 行政上見られたマルチキャストを使用するとき、ユーザはいつも正しく構成された境界ルータの存在を仮定できるというわけではありません。 これらでは、プライバシーが望まれているなら考えられて、暗号化SHOULDの使用をケースに入れます。
14. IANA Considerations
14. IANA問題
The IANA has assigned a scope-relative multicast address with an offset of 8 for Mbus/IPv4. The IPv6 permanent multicast address is FF0X:0:0:0:0:0:0:300.
IANAはMbus/IPv4のために8のオフセットで範囲親類マルチキャストアドレスを割り当てました。 IPv6の永久的なマルチキャストアドレスはFF0Xです:、0:、0:0:0、:、0:0:300
The registered Mbus UDP port number is 47000.
登録されたMbus UDPポートナンバーは47000です。
15. References
15. 参照
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[2] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", STD 3, RFC 1122, October 1989.
[2] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[3]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[4] Hinden, R. and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[4]HindenとR.とS.デアリング、「IPv6マルチキャストアドレス課題」、RFC2375、1998年7月。
[5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、1997年2月。
[6] Resnick, P., Editor, "Internet Message Format", RFC 2822, April
2001.
[6] レズニック、P.、エディタ、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
Ott, et. al. Informational [Page 35] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[35ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
[7] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September
1993.
[7] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、1993年9月。
[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[8]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェイコブセン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
[10] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[10] ハンドレー、M.、およびV.ジェイコブセン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[11] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC
2365, July 1998.
[11] マイヤー、D.、「行政上見られたIPマルチキャスト」、BCP23、RFC2365、1998年7月。
[12] Balenson, D., "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423,
February 1993.
[12]Balenson、D.、「インターネット電子メールのためのプライバシー増進:」 パートIII: 「アルゴリズム、モード、および識別子」、RFC1423、2月1993日
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[13] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[14] Myers, J., "SMTP Service Extension for Authentication", RFC
2554, March 1999.
[14] マイアーズ、J.、「認証のためのSMTPサービス拡張子」、RFC2554、1999年3月。
[15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
1992.
[15] 1992年4月、最もRivestなR.、「MD5メッセージダイジェストアルゴリズム」RFC1321。
[16] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and
Technology, "Data Encryption Standard (DES)", FIPS PUB 46-3,
Category Computer Security, Subcategory Cryptography, October
1999.
[16]米国商務省/米国商務省標準技術局、「データ暗号化規格(デス)」、FIPSパブ46-3、カテゴリコンピュータセキュリティ、副カテゴリ暗号(1999年10月)。
[17] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and
Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995.
[17]米国商務省/米国商務省標準技術局、「安全なハッシュ規格」、FIPSパブ180-1、1995年4月。
[18] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March
1999.
[18]Daemen、J.D.、およびV.R.Rijmen、「AES提案:」 1999年3月の「ラインダール。」
[19] IANA, "Internet Multicast Addresses", URL
http://www.iana.org/assignments/multicast-addresses, May 2001.
[19] IANA(「インターネットマルチキャストアドレス」、URL http://www.iana.org/assignments/multicast-addresses )は2001がそうするかもしれません。
[20] Schneier, B., "Applied Cryptography", Edition 2, Publisher John
Wiley & Sons, Inc., status: non-normative, 1996.
[20]シュナイアー、B.、「適用された暗号」、Edition2、Publisherジョン・ワイリー、およびソンスInc.、状態: 1996に非標準
Ott, et. al. Informational [Page 36] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[36ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
Appendix A. About References
参照に関する付録A.
Please note that the list of references contains normative as well as non-normative references. Each Non-normative references is marked as "status: non-normative". All unmarked references are normative.
標準と非引用規格で参考文献一覧が含む注意を喜ばせます。 Non-引用規格がマークされるそれぞれ、「状態:」 「非規範的です」。 すべての無印の参照が規範的です。
Appendix B. Limitations and Future Work
付録B.制限と今後の活動
The Mbus is a light-weight local coordination mechanism and deliberately not designed for larger scope coordination. It is expected to be used on a single node or -- at most -- on a single network link.
Mbusはメカニズムであって、より大きい範囲コーディネートのために故意に設計されなかった軽量の地元調整です。 または、ただ一つのノードの上で使用されると予想される、--単一のネットワークリンクの上の大部分で。
Therefore the Mbus protocol does not contain features that would be required to qualify it for the use over the global Internet:
したがって、Mbusプロトコルは世界的なインターネットの上の使用のそれに資格を与えるのに必要である特徴を含んでいません:
There are no mechanisms to provide congestion control. The issue
of congestion control is a general problem for multicast
protocols. The Mbus allows for un-acknowledged messages that are
sent unreliably, for example as event notifications, from one
entity to another. Since negative acknowledgements are not
defined there is no way the sender could realize that it is
flooding another entity or congesting a low bandwidth network
segment.
輻輳制御を提供するために、メカニズムは全くありません。 輻輳制御の問題はマルチキャストプロトコルのための一般的問題です。 Mbusは当てにならずに、そして、例えば、1つの実体から別の実体までのイベント通知として送られる不承認のメッセージを考慮します。 否定的承認が定義されないので、送付者が、別の実体をあふれさせるか、または低い帯域幅ネットワークセグメントを充血させているとわかることができた方法が全くありません。
The reliability mechanism, i.e., the retransmission timers, are
designed to provide effective, responsive message transport on
local links but are not suited to cope with larger delays that
could be introduced from router queues etc.
信頼性のメカニズム、すなわち、再送信タイマーは、地方のリンクの上に有効で、敏感なメッセージ転送を提供するように設計されていますが、ルータ待ち行列などから導入できたより大きい遅れに対処するために合っていません。
Some experiments are currently underway to test the applicability of bridges between different distributed Mbus domains without changing the basic protocol semantics. Since the use of such bridges should be orthogonal to the basic Mbus protocol definitions and since these experiments are still work in progress there is no mention of this concept in this specification.
いくつかの実験が、現在、基本プロトコル意味論を変えないで異なった分配されたMbusドメインの間のブリッジの適用性をテストするために進行中です。 そのようなブリッジの使用が基本的なMbusプロトコル定義と直交しているべきであり、それでも、これらの実験が進行中の仕事であるので、この仕様に基づく、この概念の言及が全くありません。
Ott, et. al. Informational [Page 37] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[37ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
Authors' Addresses
作者のアドレス
Joerg Ott TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany
ヨルクオットTZI、UniversitaetブレーメンBibliothekstr。 1 ブレーメン28359ドイツ
Phone: +49.421.201-7028 Fax: +49.421.218-7000 EMail: jo@tzi.uni-bremen.de
以下に電話をしてください。 +49.421 .201-7028Fax: +49.421 .218-7000メール: jo@tzi.uni-bremen.de
Colin Perkins USC Information Sciences Institute 3811 N. Fairfax Drive #200 Arlington VA 22203 USA
コリンパーキンスUSC情報科学研究所3811N.フェアファクスドライブ#200アーリントンヴァージニア22203米国
EMail: csp@isi.edu
メール: csp@isi.edu
Dirk Kutscher TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany
短剣クッチャーTZI、UniversitaetブレーメンBibliothekstr。 1 ブレーメン28359ドイツ
Phone: +49.421.218-7595 Fax: +49.421.218-7000 EMail: dku@tzi.uni-bremen.de
以下に電話をしてください。 +49.421 .218-7595Fax: +49.421 .218-7000メール: dku@tzi.uni-bremen.de
Ott, et. al. Informational [Page 38] RFC 3259 A Message Bus for Local Coordination April 2002
etオット、アル。 1メッセージあたり情報[38ページ]のRFC3259は2002年4月に地元調整のためにバスで行きます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Ott, et. al. Informational [Page 39]
etオット、アル。 情報[39ページ]
一覧
スポンサーリンク
