[要約] RFC 3259は、ローカルな調整のためのメッセージバスに関する情報を提供しています。このRFCの目的は、異なるプロセス間での通信と調整を容易にするためのメッセージバスの設計と実装に関するガイドラインを提供することです。
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
A Message Bus for Local Coordination
ローカル調整のためのメッセージバス
Status of this Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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.
ローカルメッセージバス（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
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
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.
他の考えられるシナリオには、いわゆるインターネットアプライアンスなど、ネットワーク内の異なるホストに分散されているアプリケーションコンポーネントの調整が含まれます。
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で定義）を提供することにより、これらのさまざまな通信ニーズを満たします。
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メッセージを受信することになる同一の場合があります。アプリケーションのマルチキャスト（グローバルスコープなど）またはMbusメッセージのユニキャストにより、悪意のある妨害が発生する可能性があります。不要なMbusメッセージを処理する可能性を排除するために、Mbusプロトコルには認証用のメッセージダイジェストが含まれています。さらに、Mbusは暗号化を可能にしてプライバシーを確保し、Mbusを使用してローカルキーの配布や盗聴の影響を受けやすい他の機能を使用できるようにします。このドキュメントでは、セクション12のセキュリティパラメータに関してMbusアプリケーションを構成するためのフレームワークを定義します。
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 メッセージバスの誤用を防ぐためのセキュリティの概念（別のユーザーの会議環境を制御するなど）。
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セッションのブートストラップに使用される、アプリケーションに依存しない必須のコマンドのセット。
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コミュニティでは、疎結合ツールのセットを使用して会議に参加するモデルが生まれました。典型的なシナリオは、オーディオ、ビデオ、および共有ワークスペースの機能が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) (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).
このアーキテクチャの改良は、プロトコル機能を実行するだけでなく、メディアのキャプチャおよび再生を実行する多数のメディアエンジンの存在に依存しています。さらに、メディアエンジンと対話して制御する1つ（または複数）の（個別の）ユーザーインターフェイスエージェントが存在します。このようなアプローチでは、ユーザーインターフェイスの設計と実装に柔軟性を持たせることができますが、関連するさまざまなエージェントが互いに通信するための手段が明らかに必要です。これは、ユーザーの会議関連のアクション（会議への参加や会議からの退出など）に対する首尾一貫した応答を可能にするために特に望ましいものです。
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.
ネットワーク内のデバイスグループの制御：ローカルネットワークに接続されているデバイスのグループ（たとえば、ホームネットワーク内の家電製品）には、ローカル調整メカニズムが必要です。手動構成を最小限に抑え、グループ通信を展開する可能性は、このアプリケーション領域でも役立ちます。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」 RFC 2119 [1]で説明されているように解釈され、準拠するMbus実装の要件レベルを示します。
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_terminal /（1 *（4base64_CHAR）[base64_terminal]）
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive
base64_terminal = (2base64_char "==") / (3base64_char "=")
UPALPHA = %x41-5A ;; Uppercase: A-Z
LOALPHA = %x61-7A ;; Lowercase: a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
CHAR = %x01-7E
; any 7-bit US-ASCII character,
excluding NUL and delete
OCTET = %x00-FF
; 8 bits of data
CR = %x0D
; carriage return
CRLF = CR LF ; Internet standard newline
CRLF = CR LF;インターネット標準改行
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote)
HTAB = %x09
; horizontal tab
LF = %x0A
; linefeed
LWSP = *(WSP / CRLF WSP)
; linear white space (past newline)
SP = %x20
; space
WSP = SP / HTAB ; white space
WSP = SP / HTAB;ホワイトスペース
Taken from RFC 2234 [13] and RFC 2554 [14].
RFC 2234 [13]およびRFC 2554 [14]から取得。
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メッセージは、ヘッダーと本文で構成されます。ヘッダーは、メッセージを配信する方法と場所を示すために使用され、本文は宛先エンティティに情報とコマンドを提供します。ヘッダーには次の情報が含まれています。
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.0」です（大文字と小文字が区別されます）。
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）が含まれています。ソースから送信された最初のメッセージはSeqNumをゼロに設定する必要があり（SHOULD）、そのソースから送信されたメッセージごとに1ずつインクリメントする必要があります。目的の受信者や選択した信頼性モードに関係なく、単一のシーケンス番号がソースからのすべてのメッセージに使用されます。シーケンス番号の値の範囲は（0,4294967295）です。実装は、4294967295に達した後、シーケンス番号を0に再設定する必要があります。実装は、他のエンティティのSeqNumがラップアラウンドする可能性があることを考慮する必要があります。
SeqNums are decimal numbers in ASCII representation.
SeqNumは、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フィールドも各メッセージに含まれており、1970年1月1日のUTC 00:00:00からのメッセージ構築時間をミリ秒で表す10進数が含まれている必要があります（SHOULD）。
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フィールドは、メッセージの目的の受信者を識別します。このフィールドは、アドレス要素を省略してワイルドカードにすることができるため、任意の数（ゼロを含む）のアプリケーションエンティティをアドレス指定できます。アドレッシング方式については、セクション4で説明します。
The AckList field comprises a list of SeqNums for which this message is an acknowledgment. See Section 7 for details.
BLAckListフィールドは、このメッセージが確認応答であるSynoNymのリストで構成されます。詳細については、セクション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.
ヘッダーの後には、宛先エンティティに配信される0個以上のコマンドを含むメッセージ本文が続きます。完全なメッセージの構文は、セクション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アプリケーションに配信される必要があります。
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
address_element = address_tag ":" address_value
address_element = address_tag "：" address_value
address_tag = 1*32(ALPHA)
address_value = 1*64(%x21-27 / %x2A-7E)
; any 7-bit US-ASCII character
; excluding white space, delete,
; control characters, "(" and ")"
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.
address_tagは、Mbusアドレス内で一意である必要があります。つまり、1回だけ発生する必要があります。
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)
will process messages sent to
に送信されたメッセージを処理します
(media:audio module:engine) and
（media：audio module：engine）および
(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)
and
そして
(foo:bar)
（foo：bar）
A message that should be processed by all entities requires an empty set of address elements.
すべてのエンティティで処理されるメッセージには、空のアドレス要素のセットが必要です。
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つの必須アドレス要素を提供する必要があります。要素タグは「id」であり、値は次のコンポーネントで構成する必要があります。
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の場合、RFC 2373 [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の概念が適用されるシステムの場合、このIDは、プロセスのさまざまなMbusエンティティのプロセスIDとプロセスごとの曖昧性除去子を使用して構成することをお勧めします。プロセス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:
エンティティ識別子の完全な構文定義は次のとおりです。
id-element = "id:" id-value
id-element = "id：" id-value
id-value = entity-id "@" host-id
id-value = entity-id "@" host-id
entity-id = 1*10DIGIT "-" 1*5DIGIT
host-id = (IPv4address / IPv6address)
Please refer to [3] for the productions of IPv4address and IPv6address.
IPv4addressとIPv6addressの生成については、[3]を参照してください。
An example for an id element:
id要素の例：
id:4711-99@192.168.1.1
id：4711-99@192.168.1.1
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.
すべてのメッセージはUTF-8文字エンコーディングを使用する必要があります。 US ASCIIはUTF-8のサブセットであり、追加のエンコードは不要であり、UTF-8でエンコードされたメッセージにはゼロバイトが含まれないことに注意してください。
Each Message MAY be encrypted using a secret key algorithm as defined in Section 11.
各メッセージは、セクション11で定義されている秘密鍵アルゴリズムを使用して暗号化される場合があります。
The fields in the header are separated by white space characters, and followed by CRLF. The format of the header is as follows:
ヘッダーのフィールドは空白文字で区切られ、その後にCRLFが続きます。ヘッダーの形式は次のとおりです。
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:
ヘッダーフィールドについては、メッセージ形式（セクション3）で説明します。ヘッダーフィールドのABNF構文定義は次のとおりです。
SeqNum = 1*10DIGIT ; numeric range 0 - 2^32-1
TimeStamp = 1*13DIGIT
MessageType = "R" / "U"
ScrAddr = mbus_address
DestAddr = mbus_address
AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")"
See Section 4 for a definition of "mbus_address".
「mbus_address」の定義については、セクション4を参照してください。
The syntax definition of a complete message is as follows:
完全なメッセージの構文定義は次のとおりです。
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.
Mbusコマンドのプロダクションルールの定義は、セクション5.3に記載されています。
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.
ヘッダーの後には、DestAddrフィールドで示されるMbusエンティティに配信されるゼロ、1つ、または複数のコマンドが続きます。各コマンドは、0個以上のパラメーターのリストが後に続くコマンド名で構成され、改行で終了します。
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:
構文的には、コマンド名は次の表で定義されている「シンボル」でなければなりません。パラメータは、次の表から抽出された任意のデータ型である場合があります。
val = Integer / Float / String / List /
Symbol / Data
Integer = *1"-" 1*DIGIT
Float = *1"-" 1*DIGIT "." 1*DIGIT
String = DQUOTE *CHAR DQUOTE ; see below for escape characters
文字列= DQUOTE * CHAR DQUOTE;エスケープ文字については以下を参照してください
List = "(" *WSP *1(val *(1*WSP val)) *WSP ")"
Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" /
".")
Data = "<" *base64 ">"
Boolean values are encoded as an integer, with the value of zero representing false, and non-zero representing true.
ブール値は整数としてエンコードされ、ゼロの値はfalseを表し、ゼロ以外の値はtrueを表します。
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 |
+----------------+-----------+
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 "> "
不透明なデータは、 "<"および ">"で囲まれたBase64エンコード（RFC 1521 [7]を参照）文字列として表されます
The ABNF syntax definition for Mbus commands is as follows:
MbusコマンドのABNF構文定義は次のとおりです。
mbus_command = command_name arglist
command_name = Symbol
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.".
コマンド名は、概念的に関連するコマンドを共通の階層の下にグループ化するために、階層的に構築する必要があります。階層内の名前間の区切り文字は「。」である必要があります。 （ドット）。アプリケーションプロファイルは、「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.
セクション4で定義されているMbusアドレス指定スキームでは、アドレス要素リストの特定の要素を省略して不完全なアドレスを指定できるため、エンティティはMbusエンティティのグループにコマンドを送信できます。したがって、メッセージのアドレスを考慮せずにコマンド名を解釈または無視できるように、すべてのコマンド名を明確にする必要があります。
A set of commands within a certain hierarchy that MUST be understood by every entity is defined in Section 9.
特定の階層内のすべてのエンティティが理解しなければならない一連のコマンドは、セクション9で定義されています。
All messages are transmitted as UDP messages, with two possible alternatives: 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.
すべてのメッセージは、UDPメッセージとして送信され、2つの選択肢があります。1.ローカルマルチキャスト/ブロードキャスト：このトランスポートクラスは、完全修飾ターゲットアドレスに送信されないすべてのメッセージに使用する必要があります。また、完全修飾ターゲットアドレスに送信されるメッセージにも使用できます。準拠する実装によって提供される必要があります。詳細については、セクション6.1を参照してください。
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. ダイレクトユニキャスト：このトランスポートクラスは、完全修飾宛先アドレスに送信されるメッセージに使用される場合があります。これはオプションであり、準拠する実装によって提供される必要はありません。
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.
完全修飾ターゲットアドレスは、Mbusセッションの既存のMbusエンティティのMbusアドレスです。実装は、Mbusセッション内の既知のエンティティのリストを維持することにより、Mbusアドレスを完全修飾として識別できます。既知の各エンティティには、独自の完全修飾Mbusアドレスがあります。
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.
メッセージはUDPデータグラムで送信されます。最大メッセージサイズは64 KBです。非ホストローカルスコープを使用するアプリケーションは、リンク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.
「ユニキャスト」、「マルチキャスト」、「ブロードキャスト」は、それぞれIPユニキャスト、IPマルチキャスト、IPブロードキャストを意味することに注意してください。 IPマルチキャストを使用して単一のエンティティにアドレス指定されたMbusメッセージを送信することが可能です。
This specification deals with both Mbus over UDP/IPv4 and Mbus over UDP/IPv6.
この仕様は、UDP / IPv4上のMbusとUDP / IPv6上のMbusの両方を扱います。
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:
一般に、Mbusはメッセージ転送のスコープが限定されたマルチキャストを使用します。 2つの異なるMbusマルチキャストスコープが定義されています。いずれもMbusセッションで使用するように構成できます。
1. host-local
1. ホストローカル
2. link-local
2. リンクローカル
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 specification of how an Mbus session can be configured to use non-standard, unassigned addresses (see Section 12).
Mbusセッションの参加者は、マルチキャストアドレスを事前に知っておく必要があります。これは、ブートストラップフェーズ中のMbusエンティティ間の初期通信にすでに必要であるため、セッション中に交渉することはできません。また、割り当てられたアドレスをすべての潜在的なMbusエンティティに通知するメカニズムがないため、Mbusセッションの前に割り当てることもできません。したがって、マルチキャストアドレスは静的に割り当てる必要があります。このドキュメントは、静的に割り当てられたアドレスの使用を定義し、非標準の未割り当てアドレスを使用するようにMbusセッションを構成する方法の仕様も提供します（セクション12を参照）。
The following sections specify the use of multicast addresses for IPv4 and IPv6.
次のセクションでは、IPv4およびIPv6のマルチキャストアドレスの使用について説明します。
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]).
IPv4の場合、静的に割り当てられた、RFC 2365 [11]で定義されているスコープ相対マルチキャストアドレスが使用されます。 Mbusのスコープ相対アドレスのオフセットは8です（MBUS、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.
RFC 2365 [11]によってさまざまなスコープが定義されています。 IPv4ローカルスコープ（239.255.0.0/16）は、管理用スコープマルチキャスト（RFC 2365 [11]で定義されている）の最小の囲みスコープであり、それ以上分割できません-その正確な範囲はサイトに依存します。
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.
IPv4ローカルスコープの場合、RFC 2365 [11]のルールを適用し、割り当てられたオフセット8を使用すると、Mbusマルチキャストアドレスは239.255.255.247になります。
For IPv4, the different defined Mbus scopes (host-local and link-local) are to be realized as follows:
IPv4の場合、定義された異なるMbusスコープ（ホストローカルおよびリンクローカル）は、次のように実現されます。
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マルチキャスト：特に設定されていない限り、ローカルスコープ（RFC 2365 [11]の時点で239.255.255.247）で割り当てられたスコープ相対Mbusアドレスを使用する必要があります。 Mbus UDPデータグラムは0のTTLで送信されるべきです（SHOULD）。
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.
リンクローカルマルチキャスト：特に構成されていない限り、ローカルスコープ（RFC 2365 [11]の時点で239.255.255.247）で割り当てられたスコープ相対Mbusアドレスを使用する必要があります。 Mbus UDPデータグラムは1のTTLで送信されるべきです（SHOULD）。
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は、異なるマルチキャストスコープに対して異なるアドレス範囲を持ち、ノードローカルスコープとリンクローカルスコープを区別します。これらは、異なるアドレス範囲のセットのアドレスプレフィックスとして実装されます（RFC 2373 [3]）。リンクローカルプレフィックスはFF02、ノードローカルプレフィックスはFF01です。恒久的に割り当てられたマルチキャストアドレスは、Mbusマルチキャスト通信に使用されます。つまり、スコープ値に依存せず、すべてのスコープに使用できるアドレスです。 IPv6の実装では、スコープに依存しないアドレスと選択したスコープの適切なプレフィックスを使用する必要があります。ホストローカルMbus通信にはIPv6ノードローカルスコーププレフィックスを使用する必要があり、リンクローカルMbus通信にはIPv6リンクローカルスコーププレフィックスを使用する必要があります。
The permanent IPv6 multicast address for Mbus/Ipv6 is FF0X:0:0:0:0:0:0:300.
Mbus / Ipv6の永続的なIPv6マルチキャストアドレスは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はMbus / IPv6に使用する必要があります（SHOULD）。FF0XのXは、これが全スコープアドレスであるため、スコープが固定されていないことを示します。つまり、ノードローカルスコープの場合はFF01：0：0：0：0：0：0：0：300を使用する必要があり、リンクローカルスコープの場合はFF02：0：0：0：0：0：0：300を使用する必要があります（SHOULD）。中古。 IPv6マルチキャストアドレスの割り当てについては、RFC 2375 [4]を参照してください。
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.
単一のアプリケーションシステムが同じ場所に配置された複数のホストに分散されている場合は、リンクローカルスコープを使用して、他のホストに受信者がいる可能性のあるMbusメッセージをマルチキャストする必要があります（SHOULD）。 Mbusプロトコルは、同じリンク上にないホスト間の通信を目的としていません（故意に設計されていません）。 Mbus構成メカニズムの仕様については、セクション12を参照してください。
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.
マルチキャストが利用できない状況では、代わりにブロードキャストを使用できます。これらの場合、接続されたネットワークのIPブロードキャストアドレスを送信に使用する必要があります（SHOULD）。 IPv6のノードローカルブロードキャストアドレスはFF01：0：0：0：0：0：0：1、IPv6のリンクローカルブロードキャストアドレスはFF02：0：0：0：0：0：0：1です。 IPv4の場合、一般的なブロードキャストアドレス（リンクローカルブロードキャストの場合）は255.255.255.255です。 IPv4の実装では、ホストローカルブロードキャストに汎用ブロードキャストアドレスとゼロのTTLを使用することをお勧めします。
Broadcast MUST NOT be used in situations where multicast is available and supported by all systems participating in an Mbus session.
ブロードキャストは、Mbusセッションに参加しているすべてのシステムでマルチキャストが利用可能でサポートされている状況では使用してはなりません（MUST NOT）。
See Section 12 for configuring the use of broadcast.
ブロードキャストの使用の構成については、セクション12を参照してください。
The registered Mbus UDP port number is 47000.
登録されているMbus UDPポート番号は47000です。
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 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.
特定のアプリケーションのポートへの（UDPを介した）ダイレクトユニキャストは、マルチキャストの代替トランスポートクラスです。ダイレクトユニキャストはオプションの最適化であり、単一のアプリケーションエンティティ（Mbus実装が他のメッセージ交換から以前に学習したアドレス）にアドレス指定されたメッセージを配信するためにMbus実装によって使用される場合があります。ただし、そのようなメッセージのDestAddrフィールドは適切に入力する必要があります。すべてのMbusエンティティは、Mbusマルチキャストグループまたは個々の受信エンティティにメッセージを送信するために、単一の一意のエンドポイントアドレスを使用する必要があります（SHOULD）。一意のエンドポイントアドレスは、エンティティのIPアドレスとUDPソースポート番号で構成されるタプルであり、ポート番号は標準のMbusポート番号とは異なります。
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.
Mbusターゲットアドレスが一意であり、送信エンティティが受信エンティティが一意のエンドポイントアドレスを使用していることを確認できる場合にのみ、メッセージをユニキャスト経由で送信する必要があります。後者は、そのエンティティから受信した最後のメッセージを検討することで確認できます。
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.
同じプロセス内など、複数のMbusエンティティが共通のトランスポートアドレスを共有する場合があることに注意してください。この場合、宛先アドレスフィールドの内容は、メッセージをさらにディスパッチするために使用されます。上記の「一意のエンドポイントアドレス」の定義を前提として、共有エンドポイントアドレスとディスパッチャを使用すると、他のMbusエンティティは、エンドポイントアドレスを共有するエンティティの1つにユニキャストメッセージを送信できます。したがって、これは実装の詳細と考えることができます。
Messages with an empty target address list MUST always be sent to all Mbus entities (via multicast if available).
空のターゲットアドレスリストを持つメッセージは、常にすべてのMbusエンティティに送信されます（可能な場合はマルチキャストを介して）。
The following algorithm can be used by sending entities to determine whether an Mbus address is unique considering the current set of Mbus entities:
次のアルゴリズムを使用してエンティティを送信すると、現在のMbusエンティティのセットを考慮して、Mbusアドレスが一意であるかどうかを判断できます。
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.)
一致するアドレスの数が正確に1の場合、アドレスは一意です。次のアルゴリズムを述語isSubsetOfに使用できます。これは、セクション4で指定されたルールに従って、2番目のメッセージが最初のメッセージと一致するかどうかをチェックします（一致とは、2番目のMbusアドレスを使用する受信エンティティも、ターゲットアドレスとしての最初のアドレス）
isSubsetOf(addr a1,a2) yields true, iff every address element of a1 is contained in a2's address element list.
isSubsetOf（addr a1、a2）は、a1のすべてのアドレス要素がa2のアドレス要素リストに含まれている場合に限り、trueを生成します。
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).
リストにa1と等しい要素が含まれている場合、アドレス要素a1はアドレス要素リストに含まれています。 2つの住所要素フィールド（タグと値）の両方に同じ値がある場合、住所要素は別の住所要素と等しいと見なされます。
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).
ほとんどのメッセージは信頼性の低いトランスポートを使用して送信されることが予想されますが、一部のメッセージを確実に配信する必要がある場合があります。信頼性は、MessageTypeフィールドを使用してメッセージごとに選択できます。信頼できる配信は、受信者が1人だけのメッセージでサポートされています。つまり、完全修飾されたMbusアドレスに。したがって、エンティティは信頼できるメッセージを既知のアドレスにのみ送信できます。つまり、エンティティは、Mbusでの存在を通知したエンティティにのみ送信できます（たとえば、セクション9.1で定義されているmbus.hello()メッセージによって）。ターゲットアドレスが一意でない場合、送信エンティティはメッセージを確実に送信してはなりません（MUST NOT）。 （アドレスが一意であるかどうかを判断するアルゴリズムの仕様については、セクション6を参照してください。）受信エンティティは、宛先アドレスが自身の送信元アドレスと完全に一致する場合にのみ、信頼できるメッセージを処理して確認する必要があります（宛先アドレスは、送信元アドレス）。
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.
複数の宛先に送信されるメッセージの信頼性の高いメッセージ配信を禁止するのは、プロトコルと同様に実装が単純なためです。 Mbusセッションのメンバーシップ情報が利用可能な場合、完全修飾された各宛先アドレスに個別の信頼できるメッセージを送信することにより、アプリケーション層で望ましい効果を得ることができます。
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.
各メッセージには、メッセージシーケンス番号のタグが付けられます。 MessageTypeが "R"の場合、送信者は受信者からの確認応答を短時間のうちに期待します。この間隔内に確認応答が受信されない場合、送信者は（同じメッセージシーケンス番号で）メッセージを再送信し、タイムアウトを増やし、タイマーを再起動する必要があります。送信または受信者が失敗したと見なされる前に、メッセージを数回再送信する必要があります（以下を参照）。メッセージが正常に配信されない場合、送信側アプリケーションに通知されます。この場合、実行する特定のアクション（存在する場合）を決定するのはアプリケーションです。
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.
信頼性のあるメッセージの発信者に送信されるメッセージのAckListフィールドにSeqNumを追加して、信頼性のあるメッセージを確認する必要があります。このメッセージは、完全修飾されたMbusターゲットアドレスに送信する必要があります。複数の確認応答が単一のメッセージで送信される場合があります。実装は、同じ宛先に送信された別のメッセージにAckListをピギーバックするか、メッセージペイロード部分にコマンドを指定せずに専用の確認応答メッセージを送信してもよい（MAY）。
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.
送信者：信頼できるメッセージMの送信者Aから受信者Bへは、IPマルチキャストまたはIPユニキャストを介してメッセージを送信し、Mのコピーを保持し、再送信カウンターNを「1」に初期化して、再送信タイマーTを開始する必要があります。 （T_rに初期化されます）。確認応答がBから受信された場合、タイマーTをキャンセルする必要があり、Mのコピーは破棄されます。 Tの期限が切れた場合、メッセージMを再送信する必要があり、カウンターNを1だけインクリメントする必要があり、タイマーを再起動する必要があります（N * T_rに設定）。 Nが再送信しきい値N_rを超える場合、送信は失敗したと見なされ、それ以上の再送信試行は行われてはならず（MUST）、Mのコピーは破棄されなければならず（MUST）、送信アプリケーションに通知する必要があります（SHOULD）。
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.
受信者：送信者Aからの信頼できるメッセージの受信者Bは、期間T_c <T_r内のメッセージの受信を確認しなければなりません（MUST）。これは、専用の確認応答メッセージを使用するか、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.
受信機の最適化：単純な実装では、Bは専用の確認応答メッセージをすぐに送信することを選択できます。ただし、効率を高めるために、受信したメッセージのSeqNumを送信者固有の確認応答リストに追加できます。追加されたSeqNumがリストの最初の確認応答である場合、Bは確認応答タイマーTA（T_cに初期化）を開始する必要があります（SHOULD）。タイマーが時間切れになると、Bは専用の確認応答メッセージを作成してAに送信する必要があります。BがA宛ての別のMbusメッセージを送信する場合は、このメッセージに確認応答をピギーバックしてTAをキャンセルする必要があります。どちらの場合も、Bは確認応答リストのコピーを送信者ごとのコピーリストの単一のエントリとして保存し、このエントリを期間T_kの間保持し、確認応答リストを空にする必要があります。コピーリストのエントリに保持されているメッセージのいずれかがAから再度受信された場合、このエントリに格納されている確認応答リスト全体が、上記の規則に従って（再）送信されるようにスケジュールされます。
Constants and Algorithms: The following constants and algorithms SHOULD be used by implementations:
定数とアルゴリズム：次の定数とアルゴリズムは、実装で使用する必要があります（SHOULD）。
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
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.
Mbusエンティティが相互に通信できるようになる前に、Mbusエンティティはお互いの存在を知る必要があります。このブートストラップ手順の後、各Mbusエンティティは同じMbusをリッスンしている他のすべてのエンティティを通過し、新人は他のすべてのエンティティについて学習します。さらに、エンティティは他のエンティティの失敗（または終了）に気付くことができる必要があります。
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.
Mbusエンティティは、起動後に（Mbus上で）その存在を通知する必要があります。これは、起動シーケンスの問題に対処するために、その存続期間を通じて繰り返し行われます。エンティティは、起動の順序に関係なく、常に他のエンティティを認識する必要があります。
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.
各Mbusエンティティは、Mbusセッションメンバーの数を維持し、観察された変更に従ってこの数を継続的に更新する必要があります。他のエンティティの存在と離脱を検出する方法のメカニズムは、エンティティ認識専用のMbusメッセージです：mbus.hello（セクション9.1）およびmbus.bye（セクション9.2）。各Mbusプロトコルの実装は、他のエンティティがそのエンティティの存在を監視するために使用するmbus.helloメッセージを定期的に送信する必要があります。エンティティがエンティティからmbus.helloメッセージを一定時間受信しない場合（セクション8.2を参照）、それぞれのエンティティはMbusを離れたと見なされ、現在既知のエンティティのセットから除外する必要があります。 mbus.byeメッセージを受信すると、それぞれのエンティティもMbusを離れたと見なされ、現在既知のエンティティのセットからすぐに除外する必要があります。
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.
各Mbusエンティティは、起動後にhelloメッセージをMbusに送信する必要があります。 helloメッセージの送信後、次のhelloメッセージが送信される期限が切れた後、タイマーを開始する必要があります。エンティティがMbusから切り離されない限り、helloメッセージの送信を停止してはならない（MUST NOT）。 helloメッセージを送信する間隔は、Mbusグループ内のエンティティの現在の数に依存しているため、多くのエンティティが一定の高速でhelloメッセージを送信することによる輻輳を回避するために、動的に変更できます。
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メッセージ間隔の計算を指定しています。現在のhelloメッセージタイマーを取得するために計算された値を使用して、受信したhelloメッセージのタイムアウトがセクション8.2で計算されます。セクション9では、対応するMbusメッセージのコマンド概要を指定します。
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.
Mbusセッションのエンティティの数は変わる可能性があるため、Mbusプロトコルが幅広いグループサイズに自動的にスケーリングできるように注意する必要があります。 helloメッセージが受信される平均レートは、送信間隔が固定値に設定されている場合、セッション内のエンティティの数に比例して増加します。 1秒の間隔が与えられた場合、これは、nエンティティとのMbusセッションに参加しているエンティティが1秒あたりn個のhelloメッセージを受信することを意味します。すべてのエンティティが1つのホストに存在すると仮定すると、1秒あたりに処理する必要のあるn * nメッセージが発生します。これは、明らかに大規模なグループでは実行可能なソリューションではありません。したがって、さまざまな数のエンティティを考慮に入れて、動的に調整されたhelloメッセージ間隔を展開する必要があります。以下では、観測されたMbusエンティティの数を考慮して、helloメッセージの間隔を計算するために実装者が使用する必要があるアルゴリズムを指定します。
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 エンティティの数が変化しても、特定の時間単位で単一のエンティティが受信するhelloメッセージの数はほぼ一定のままです。
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 Mbusセッション内のhelloメッセージの意図しない同期を回避するために、特定のMbusエンティティによって使用される有効な間隔はランダム化されます。エンティティの最初のhelloメッセージも、一定のランダムな時間だけ遅延します。
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 エンティティの数の急激な変化が観察される状況で、間隔をより適切に調整するために、タイマー再検討メカニズムが導入されています。これは、エンティティがMbusセッションに参加し、他のエンティティの存在をまだ学習している場合や、多数のエンティティが一度にMbusを離れる場合に役立ちます。
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.
hello_p：Mbusエンティティによってhelloメッセージが最後に送信された時間。
hello_now: The current time
hello_now：現在の時刻
hello_d: The deterministic calculated interval between hello messages.
hello_d：helloメッセージ間の決定論的に計算された間隔。
hello_e: The effective (randomized) interval between hello messages.
hello_e：helloメッセージ間の有効な（ランダム化された）間隔。
hello_n: The time for the next scheduled transmission of a hello message.
hello_n：helloメッセージの次のスケジュールされた送信の時間。
entities_p: The numbers of entities at the time hello_n has been last recomputed.
entities_p：hello_nが最後に再計算されたときのエンティティの数。
entities: The number of currently known entities.
エンティティ：現在既知のエンティティの数。
The interval between hello messages MUST be calculated as follows:
helloメッセージの間隔は、次のように計算する必要があります。
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_hello_factorを掛けると、helloメッセージの間隔がミリ秒単位になります。これはhello_dで示される決定論的に計算された間隔です。 hello_dの最小値はc_hello_minであり、
hello_d = max(c_hello_min,c_hello_factor * entities * 1ms).
hello_d = max（c_hello_min、c_hello_factor *エンティティ* 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_hello_factorおよびc_hello_minの値を提供します。
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:
個々のエンティティによって使用される有効な間隔hello_eは、次のようにhello_dにc_hello_dither_minとc_hello_dither_maxの間のランダムに選択された数を掛けることによって計算されます。
hello_e = c_hello_dither_min +
RND * (c_hello_dither_max - c_hello_dither_min)
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.
hello_n。ミリ秒単位の次のhelloメッセージの時間は、hello_e + hello_nowに設定されます。
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.
Mbusセッションに参加すると、プロトコル実装はhello_p = 0、hello_now = 0、entities = 1、entities_p = 1（Mbusエンティティ自体）を設定し、セクション8.1.1で指定されている次のhelloメッセージの時間を計算します。次のhelloメッセージは、hello_nでの送信がスケジュールされています。
8.1.3 Adjusting the Hello Message Interval when the Number of Entities increases
8.1.3 エンティティ数が増加した場合のHelloメッセージの間隔の調整
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).
プロトコル実装によって新しいエンティティの存在が観察されると、現在既知のエンティティの数が更新されます。 helloメッセージ間隔の計算に関する追加のアクションは必要ありません。タイマー間隔の再検討は、次のhelloメッセージの現在のタイマーが期限切れになったときに行われます（セクション8.1.5を参照）。
8.1.4 Adjusting the Hello Message Interval when the Number of Entities decreases
8.1.4 エンティティ数が減少した場合のHelloメッセージの間隔の調整
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を離れたことを認識すると、現在知られているエンティティの数が更新され、次のアルゴリズムを使用してhelloメッセージのタイマー間隔を再検討する必要があります。
1. The value for hello_n is updated by setting hello_n = hello_now + (entities/entities_p)*(hello_n - hello_now)
1. hello_nの値は、hello_n = hello_now +（entities / entities_p）*（hello_n-hello_now）を設定することによって更新されます
2. The value for hello_p is updated by setting hello_p = hello_now - (entities/entities_p)*(hello_now - hello_p)
2. hello_p = hello_now-（entities / entities_p）*（hello_now-hello_p）を設定すると、hello_pの値が更新されます
3. The currently active timer for the next hello messages is cancelled and a new timer is started for hello_n.
3. 次のhelloメッセージの現在アクティブなタイマーがキャンセルされ、hello_nの新しいタイマーが開始されます。
4. entities_p is set to entities.
4. entities_pはエンティティに設定されます。
When the hello message timer expires, the protocol implementation MUST perform the following operations:
helloメッセージタイマーが期限切れになると、プロトコル実装は次の操作を実行する必要があります。
The hello interval hello_e is computed as specified in Section 8.1.1.
hello間隔hello_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. IF hello_e + hello_p <= hello_now THEN helloメッセージが送信されます。 hello_pはhello_nowに設定され、hello_eはセクション8.1.1で指定されているように再計算され、hello_nはhello_e + hello_nowに設定されます。
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 hello_e + hello_p> hello_now THEN hello_nはhello_e + hello_pに設定されます。次のhelloメッセージの新しいタイマーがhello_nで期限切れになります。 helloメッセージは送信されません。
entities_p is set to entities.
entities_pはエンティティに設定されます。
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エンティティが別のMbusエンティティからc_hello_dead *（hello_d * c_hello_dither_max）ミリ秒の時間にわたって聞こえなかった場合は常に、このエンティティが失敗した（またはサイレントで終了した）と見なされる場合があります。現在既知のエンティティの数は、それに応じて更新する必要があります。詳細については、セクション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は、hello_dの取得方法を指定しています。セクション10では、定数c_hello_deadおよびc_hello_dither_maxの値を定義します。
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プロトコル仕様の外で定義されます。
Syntax: mbus.hello()
構文：mbus.hello()
Parameters: - none -
mbus.hello messages MUST be sent unreliably to all Mbus entities.
mbus.helloメッセージは、信頼できない方法ですべてのMbusエンティティに送信する必要があります。
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.helloメッセージを監視し、各メッセージの送信者アドレスを追跡することにより、他のMbusエンティティについて学習し、エンティティの現在の数を計算できます。
mbus.hello messages MUST be sent periodically in dynamically calculated intervals as specified in Section 8.
mbus.helloメッセージは、セクション8で指定されているように、動的に計算された間隔で定期的に送信する必要があります。
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メッセージを遅延hello_delayの後に送信する必要があります。ここで、hello_delayは0からc_hello_minまでのランダムに選択された数値です（セクション10を参照）。
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から「切り離す」）Mbusエンティティは、mbus.byeメッセージを送信してこれを通知する必要があります（SHOULD）。 mbus.byeメッセージは、すべてのエンティティに信頼性なく送信される必要があります。
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.pingを使用して、mbus.helloメッセージで返信することにより、他のエンティティにその存在を通知するように要請できます。各プロトコル実装は、mbus.pingを理解し、mbus.helloメッセージで応答する必要があります。 helloメッセージの返信は、hello_delayミリ秒遅延する必要があります。hello_delayは、0からc_hello_minまでのランダムに選択された数値です（セクション10を参照）。いくつかのmbus.pingメッセージは単一のmbus.helloで応答できます：エンティティがmbus.helloメッセージを送信する前にhello_delay時間単位を待っている間に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で指定されているように、helloメッセージはすべてのMbusエンティティに信頼性なく送信される必要があります。これは、pingメッセージへの返信にも当てはまります。 mbus.helloでmbus.pingに応答するエンティティは、helloメッセージの送信後にhelloメッセージの未解決のタイマーを停止し、後続のhelloメッセージの新しいタイマーイベントをスケジュールする必要があります（SHOULD）。 （セクション8.1.1の変数とアルゴリズムを使用することは、hello_pをhello_nowに設定することで実現できることに注意してください。）
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を使用すると、新しいエンティティは、通常の個々のhelloメッセージを待つ必要なく、他のエンティティをすばやく確認できます。ターゲットアドレスを指定することにより、新しいエンティティは、helloメッセージの送信請求を、関心のあるエンティティのサブセットに制限できます。
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エンティティまたはエンティティのグループにユニキャスト経由で確実に送信できます。
Syntax: mbus.waiting(condition)
構文：mbus.waiting（condition）
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エンティティは、特定のイベントが発生するのを待っていることを示す必要があります（セマフォのP()操作に似ていますが、他の場所に外部状態を作成しません）。これと併せて、Mbusエンティティは、この条件が現在満たされていることを別のエンティティに示すことができる必要があります（セマフォの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メッセージの送信は信頼できなければならず（MUST）、アプリケーションで定義された間隔で（条件が満たされるまで）繰り返されなければなりません（MUST）。
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ペイロードで送信される場合があることに注意してください。
Syntax: mbus.go(condition)
構文：mbus.go（condition）
Parameters:
パラメーター：
symbol condition This parameter specifies which condition is met.
シンボル条件このパラメーターは、どの条件が満たされるかを指定します。
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.goメッセージはMbusエンティティによって送信され、別のMbusエンティティを「ブロック解除」します。これは、特定の条件が満たされるのを待っていることを示しています。 mbus.goメッセージごとに指定できる条件は1つだけです。複数の条件が同時に満たされる場合、複数のmbus.goメッセージが1つのMbusペイロードに結合される場合があります。
The mbus.go message MUST be sent reliably via unicast to the Mbus entity to unblock.
ブロックを解除するには、mbus.goメッセージをユニキャスト経由でMbusエンティティに確実に送信する必要があります。
The following values for timers and counters mentioned in this document SHOULD be used by implementations:
このドキュメントで言及されているタイマーとカウンターの次の値は、実装で使用する必要があります。
+-------------------+------------------------+--------------+
|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 | - |
+-------------------+------------------------+--------------+
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
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).
Mbusメッセージ転送のプライバシーは、オプションで対称暗号化方式を使用することで実現できます（セクション11.2）。各メッセージは、追加の共有秘密鍵と対称暗号化アルゴリズムを使用して暗号化される場合があります。暗号化はアプリケーションではオプションです。つまり、暗号化を使用しないように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.
メッセージの認証と暗号化はパラメーター化できます。適用するアルゴリズム、使用するキーなどです。これらおよびその他のパラメーターは、Mbusセッションに参加するすべてのMbusエンティティからアクセス可能なMbus構成オブジェクトで定義されます。相互運用性に適合する実装を実現するために、このようなMbus構成によって提供される値を使用する必要があります（SHOULD）。セクション12では、必須およびオプションのパラメーターと、さまざまなプラットフォームのストレージ手順を定義します。セクション12で言及されているオプションのいずれも適用できない場合にのみ、Mbusプロトコルエンティティを構成する代替方法を展開できます。
The algorithms and procedures for applying encryption and authentication techniques are specified in the following sections.
暗号化および認証技術を適用するためのアルゴリズムと手順は、次のセクションで指定されます。
Encryption of messages is OPTIONAL, that means, an Mbus MAY be configured not to use encryption.
メッセージの暗号化はオプションです。つまり、Mbusは暗号化を使用しないように構成できます（MAY）。
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]アルゴリズムを提供する必要があります。さらに、DES [16]、3DES（トリプルDES）[16]、およびIDEA [20]のアルゴリズムをサポートする必要があります（SHOULD）。
For algorithms requiring en/decryption data to be padded to certain boundaries octets with a value of 0 SHOULD be used for padding characters.
en / decryptionデータを特定の境界までパディングする必要があるアルゴリズムでは、値0のオクテットを文字のパディングに使用する必要があります（SHOULD）。
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暗号ブロック連鎖（CBC）モードを使用する必要があります。 DESキー（56ビット）は、RFC 1423 [12]で説明されているように8オクテットとしてエンコードする必要があり、その結果、12のBase64エンコード文字になります。 IDEAは128ビットのキー（24個のBase64エンコード文字）を使用します。 AESは、128ビット、192ビット、または256ビットのキーを使用できます。 AESを使用するMbus暗号化では、128ビットキー（Base64でエンコードされた24文字）のみを使用する必要があります。
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:
メッセージの認証には、RFC 2104 [5]で説明されているハッシュメッセージ認証コード（HMAC）が配備されます。一般に、実装では、いくつかのダイジェストアルゴリズムから選択できます。 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).
キー付きハッシュ値は、RFC 2104 [5]で指定されたHMACアルゴリズムを使用して計算されます。特定のハッシュアルゴリズムと秘密ハッシュキーは、Mbus構成から取得する必要があります（セクション12を参照）。
The keyed hash values (see RFC 2104 [5]) MUST be truncated to 96 bits (12 octets).
キー付きハッシュ値（RFC 2104 [5]を参照）は、96ビット（12オクテット）に切り捨てられる必要があります。
Subsequently, the resulting 12 octets MUST be Base64-encoded, resulting in 16 Base64-encoded characters (see RFC 1521 [7]).
その後、結果の12オクテットはBase64でエンコードされている必要があり、16のBase64でエンコードされた文字になります（RFC 1521 [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]のいずれかをメッセージ認証コード（MAC）に使用する必要があります。実装はMD5を提供する場合がありますが、SHA-1を実装する必要があります。
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.
ハッシュキーの長さは、選択したハッシュアルゴリズムによって決まります。つまり、構成されているハッシュキーは、現在構成されているアルゴリズムのネイティブキーの長さよりも短くてはなりません。
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. 続いて、（暗号化された）メッセージのメッセージ認証コード（MAC）は、構成されたHMACアルゴリズムと構成されたハッシュキーを使用して計算する必要があります。
3. The MAC MUST then be converted to Base64 encoding, resulting in 16 Base64-characters as specified in Section 11.3.
3. 次にMACをBase64エンコーディングに変換する必要があり、セクション11.3で指定されているように16のBase64文字になります。
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
MsgDigest = base64
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 start with the string "mbus/" the message MUST be discarded without further processing.
4.暗号化が有効になっている場合、構成されたアルゴリズムと構成された暗号化キーを使用してメッセージを復号化する必要があります。値が0の後続オクテットは削除する必要があります。メッセージが文字列「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)):
以下のパラメーターはオプションです。彼らがいるとき、彼らは尊敬されなければなりません。それらが存在しない場合、実装は事前定義されたデフォルト値（トランスポート（セクション6）で定義）にフォールバックする必要があります（SHOULD）。
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.
ブロードキャストを使用するかどうかを指定できます。ブロードキャストが構成されている場合、実装は標準のマルチキャストアドレスの代わりにネットワークブロードキャストアドレス（セクション6.1.3で指定）を使用する必要があります（SHOULD）。
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つの異なる機能が考慮されます。Unixのようなシステムではユーザーごとの構成ファイルを使用する必要があり（SHOULD）、Windows-95 / 98 / NT / 2000 / XPシステムではレジストリエントリのセットを定義して使用する必要があります（SHOULD）。他のシステムでは、ファイルベースの構成メカニズムを使用することをお勧めします。
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（RFC 2234 [13]を参照）プロダクションを定義しています。
algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
"HMAC-MD5-96" / "HMAC-SHA1-96"
scope = "HOSTLOCAL" / "LINKLOCAL"
key = base64
version_number = 1*10DIGIT
key_value = "(" algo-id "," key ")"
key_value = "（" algo-id "、" key "）"
address = IPv4address / IPv6address / "BROADCAST"
port = 1*5DIGIT ; values from 0 through 65535
Given the definition above, a key entry MUST be specified using this notation:
上記の定義を前提として、次の表記法を使用してキーエントリを指定する必要があります。
"("algo-id","base64string")"
"（" something-id "、" 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.
algo-idは、上記で指定した文字列の1つです。 algo-id == "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文字セット（RFC 1521 [7]を参照）で定義された文字で構成されます。つまり、Base64文字列の長さは常に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 value of this parameter and construct an effective IP-Address considering the specifications of Section 6.1.
スコープパラメータは、IPマルチキャストスコープを構成するために使用され、「HOSTLOCAL」または「LINKLOCAL」のいずれかに設定できます。実装は、このパラメーターの値に応じて適切なIPマルチキャストスコープを選択し、セクション6.1の仕様を考慮して効果的なIPアドレスを構築する必要があります（SHOULD）。
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.
ブロードキャストの使用は、アドレスフィールドに値 "BROADCAST"を提供することによって構成されます。ブロードキャストが構成されている場合、実装は、標準のマルチキャストアドレスの代わりに、使用されているIPバージョンのネットワークブロードキャストアドレスを使用する必要があります（SHOULD）。
The version_number parameter specifies a version number for the used configuration entity.
version_numberパラメーターは、使用される構成エンティティーのバージョン番号を指定します。
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-file = mbus-topic LF *（エントリLF）
mbus-topic = "[MBUS]"
mbus-topic = "[MBUS]"
entry = 1*(version_info / hashkey_info
/ encryptionkey_info / scope_info
/ port_info / address_info)
version_info = "CONFIG_VERSION=" version_number
version_info = "CONFIG_VERSION =" version_number
hashkey_info = "HASHKEY=" key_value
hashkey_info = "HASHKEY =" key_value
encrkey_info = "ENCRYPTIONKEY=" key_value
encrkey_info = "ENCRYPTIONKEY =" key_value
scope_info = "SCOPE=" scope
scope_info = "SCOPE ="スコープ
port_info = "PORT=" port
port_info = "PORT ="ポート
address_info = "ADDRESS=" address
address_info = "ADDRESS ="アドレス
The following entries are defined: CONFIG_VERSION, HASHKEY, ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.
次のエントリが定義されています：CONFIG_VERSION、HASHKEY、ENCRYPTIONKEY、SCOPE、PORT、ADDRESS。
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_VERSION、HASHKEY、およびENCRYPTIONKEYは必須であり、すべてのMbus構成ファイルに存在している必要があります。エントリの順序は重要ではありません。
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
[MBUS] CONFIG_VERSION = 1 HASHKEY =（HMAC-MD5-96、MTIzMTU2MTg5MTEy）ENCRYPTIONKEY =（DES、MTIzMTU2MQ ==）SCOPE = HOSTLOCAL ADDRESS = 224.255.222.239 PORT = 47000
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、Windows 2000、Windows XPレジストリなど）を使用する必要があります。 Mbus関連のレジストリエントリの階層は次のとおりです。
HKEY_CURRENT_USER\Software\Mbus
HKEY_CURRENT_USER \ Software \ 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 |
+---------------+--------+----------------+
The same syntax for key values as for the file based configuration facility MUST be used.
ファイルベースの構成機能と同じキー値の構文を使用する必要があります。
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-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の代わりにHMAC-MD5を使用することができます。さらに、プライバシーが他の方法で提供されている場合、または特定のアプリケーションにとって重要ではないと見なされている場合は、暗号化を完全にオフにすることができます。
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.
いずれにしても、アプリケーション開発者は、RFC 1122 [2]に準拠していない誤ったIP実装を認識し、TTL値がゼロのデータグラムを送信するため、ユーザーがホストを選択した可能性があるにもかかわらず、ローカルネットワークリンクにMbusメッセージが送信されます。 Mbus構成のローカルスコープ。管理スコープのマルチキャストを使用する場合、ユーザーは正しく構成された境界ルーターの存在を常に想定できるわけではありません。これらの場合、プライバシーが必要な場合は、暗号化の使用を検討してください。
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です。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[2] ブレーデン、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[3] Hinden、R. and S. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
[4] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.
[4] Hinden、R。およびS. Deering、「IPv6マルチキャストアドレス割り当て」、RFC 2375、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. Canetti、「HMAC：Keyed-Hashing for Message Authentication」、RFC 2104、1997年2月。
[6] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[6] Resnick、P。、編集者、「インターネットメッセージ形式」、RFC 2822、2001年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. Freed、「MIME（多目的インターネットメール拡張）パート1：インターネットメッセージ本文の形式を指定および説明するためのメカニズム」、RFC 1521、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.、Frederick、R。およびV. Jacobsen、「RTP：A Transport Protocol for Real-Time Applications」、RFC 1889、1996年1月。
[9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley、M.、Schulzrinne、H.、Schooler、E. and J. Rosenberg、 "SIP：Session Initiation Protocol"、RFC 2543、March 1999。
[10] Handley, M. and V. Jacobsen, "SDP: Session Description Protocol", RFC 2327, April 1998.
[10] Handley、M。およびV. Jacobsen、「SDP：Session Description Protocol」、RFC 2327、1998年4月。
[11] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[11] Meyer、D。、「Administratively Scoped IP Multicast」、BCP 23、RFC 2365、1998年7月。
[12] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.
[12] バレンソン、D。、「インターネット電子メールのプライバシー強化：パートIII：アルゴリズム、モード、および識別子」、RFC 1423、1993年2月。
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[13] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、RFC 2234、1997年11月。
[14] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[14] マイヤーズ、J。、「認証用のSMTPサービス拡張」、RFC 2554、1999年3月。
[15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[15] Rivest、R。、「MD5メッセージダイジェストアルゴリズム」、RFC 1321、1992年4月。
[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] 米国商務省/国立標準技術研究所、「データ暗号化標準（DES）」、FIPS PUB 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] 米国商務省/国立標準技術研究所、「Secure Hash Standard」、FIPS PUB 180-1、1995年4月。
[18] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March 1999.
[18] 大門、J.D。およびV.R.ライムス、「AES Proposal：Rijndael」、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年5月。
[20] Schneier, B., "Applied Cryptography", Edition 2, Publisher John Wiley & Sons, Inc., status: non-normative, 1996.
[20] Schneier、B。、「Applied Cryptography」、第2版、発行者John Wiley＆Sons、Inc.、ステータス：非規範的、1996年。
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.
参考文献のリストには、規範的参考文献と非規範的参考文献が含まれていることに注意してください。各非規範的参照は、「ステータス：非規範的」としてマークされます。マークのない参照はすべて規範的です。
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プロトコルの定義と直交している必要があり、これらの実験はまだ進行中であるため、この仕様ではこの概念について言及していません。
Authors' Addresses
著者のアドレス
Joerg Ott TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany
Joerg Ott TZI、ブレーメン大学Bibliothekstr。 1ブレーメン28359ドイツ
Phone: +49.421.201-7028
Fax: +49.421.218-7000
EMail: jo@tzi.uni-bremen.de
Colin Perkins USC Information Sciences Institute 3811 N. Fairfax Drive #200 Arlington VA 22203 USA
コリンパーキンスUSC情報科学研究所3811 N.フェアファックスドライブ＃200アーリントンVA 22203米国
EMail: csp@isi.edu
Dirk Kutscher TZI, Universitaet Bremen Bibliothekstr. 1 Bremen 28359 Germany
Dirk Kutscher TZI、ブレーメン大学Bibliothekstr。 1ブレーメン28359ドイツ
Phone: +49.421.218-7595
Fax: +49.421.218-7000
EMail: dku@tzi.uni-bremen.de
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができます。ただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、この文書自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。