RFC 3259

A Message Bus for Local Coordination

📅 published May 2002, from ietf

RFC 3259: A Message Bus for Local Coordination 💖

okay bestie, this one is the Mbus spec, and it's written by three people 🫶 J. Ott and D. Kutscher are both from TZI at Universitaet Bremen, and C. Perkins is from the USC Information Sciences Institute. It came out in April 2002 as an Informational doc, so it's sharing info rather than setting an Internet standard. It's part of the Network Working Group stream. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Status of this Memo 📝

this memo gives information to the Internet community. it doesn't specify an Internet standard of any kind, and you can distribute it as much as you want 🌸

Copyright (C) The Internet Society (2002). All Rights Reserved. 💅

Abstract ✨

so the local Message Bus (Mbus) is a light-weight, message-oriented coordination protocol for group communication between application components. it's giving automatic location of communication peers, subject-based addressing, reliable message transfer, and different types of communication schemes 🧚

it's layered on top of IP multicast and it's specified for both IPv4 and IPv6. the IP multicast scope is limited to link-local multicast, so it stays on the local link 🍓 this doc specifies the Mbus protocol itself, meaning the message syntax, the addressing, and the transport mechanisms. iconic 👑

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

1. Introduction 🎀

okay so the first example that comes to mind is multiparty multimedia conferencing systems. these need a simple coordination setup that can really help. picture a bunch of conferencing scenarios where you want a local channel for conference info to get swapped between apps that live on the same machine (co-located) but don't otherwise depend on each other. like, apps that are all in sessions belonging to the same conference 💅

in loosely coupled conferences, that channel lets apps coordinate. you can use it to sync media streams, or to set up entities without anyone clicking anything. it also works for tightly coupled conferences, where a conference controller can enforce conference-wide control inside one end system. iykyk, control freak energy but make it protocol 👑

conferencing systems like IP telephones can also be seen as parts of a distributed system, so they can join a group of application modules 📞 for example, an IP telephony call on a stand-alone IP telephone can grow dynamically to add media engines for other media types, using the coordination function of a suitable mechanism. then different conferencing pieces can team up to make one coherent multimedia conferencing system for a user 🧚

other possible scenarios include coordinating application components spread across different hosts in a network, like so-called Internet appliances 🍓

1.1. Mbus Overview 🦋

local coordination of app components needs a bunch of different interaction models 😭 some messages (membership info, floor control notifications, conference state change updates, etc.) might need to go out to all local application entities. other messages can target one application class (all whiteboards or all audio tools) or one agent type (all user interfaces, not all media engines). or there could be any subgrouping, defined by the app or the message, like messages about media synchronization. and finally, some messages go to a single entity. think specific config settings a conference controller sends to one particular app entity, or query-response exchanges between a local server and its clients 🫶

the Mbus protocol handles all these different comms needs by defining different message transport mechanisms (see Section 6) and by giving you a flexible addressing scheme (see Section 4) ✨

now here's the tea ☕ Mbus messages between app entities can have different reliability requirements, and those usually come from what the message actually means. some messages are pretty transient, carrying ephemeral state that gets refreshed or updated on a schedule. like the volume meter level of an audio receiver entity that its user interface agent displays 📊 certain Mbus messages (like queries for parameters or queries to local servers) might need a response from their peers. that gives you an explicit acknowledgment at the semantic level on top of Mbus 💖 other messages change the app or conference state, so they absolutely can't get lost. that second type has to be delivered reliably to the recipient 🚨 the first type doesn't need reliability at the Mbus transport layer. and for messages that get confirmed at the application layer, it's up to the app whether it wants a reliable transport underneath 🙈

some entities want to customize how reliable things are, and others just want to lean on the underlying transport to make sure messages arrive. and it can change for each Mbus message 💅 the Mbus message passing mechanism in this doc gives you maximum flexibility. you get reliable transmission through transport-layer acknowledgments (only for point-to-point communications), plus unreliable message passing for unicast, local multicast, and local broadcast. we'll get into this topic in Section 4 🌈

last but not least, accidental or malicious disruption of Mbus comms from messages sent by apps belonging to other users needs to be prevented 🔥 accidental reception can happen if two users share the same host for Mbus apps, or if their Mbus apps are spread across the same network link. in either case, the Mbus multicast address and port number could be identical, so you end up receiving the other party's Mbus messages alongside your own 👀 malicious disruption can happen when apps multicast (like at global scope) or unicast Mbus messages. to get rid of the chance of processing unwanted Mbus messages, the protocol includes message digests for authentication 🔐 the Mbus also allows encryption for privacy, which means you can use it for local key distribution and other stuff that's sensitive to eavesdropping 🙊 this document sets up the framework for configuring Mbus apps with their security parameters in Section 12 💜

1.2. Purpose of this Document 🎀

okay so the message bus is basically three pieces working together 🧚: the low-level message passing stuff, a command syntax with a naming hierarchy, and the addressing scheme. ✨

This doc is all about the low-level Mbus message passing mechanism, the part that every Mbus implementation shares 💅. It defines:

  • the generic Mbus message format;
  • the addressing concept for application entities (note that concrete addressing schemes are to be defined by application-specific profiles);
  • the transport mechanisms used to get messages between (co-located) application entities;
  • the security concept that stops misuse of the Message Bus, like someone grabbing control of another user's conferencing environment 😭 absolutely not;
  • the details of the Mbus message syntax; and
  • a set of mandatory application-independent commands used for bootstrapping Mbus sessions.

1.3. Areas of Application 🌈

Mbus can show up in lots of application areas, not just one, including but not limited to:

Local conference control: So in the Mbone community, people basically landed on a model where a bunch of loosely coupled tools team up to join a conference 🎧. Usually audio, video, and shared workspace each get their own tool, though some tools combine them. That lines up nicely with the underlying RTP [8] media streams (and other media streams), which also travel separately. With an architecture like that, it's really handy to coordinate the separate media tools. For example, you might want to share playout-point info between the audio and video tools for lip-synchronization, or arbitrate who gets shared resources like input devices, etc. 💖

A refinement of this setup has a bunch of media engines that handle the protocol functions plus capturing and playing out media. On top of that you've got one (or more) separate user interface agents that talk to and control those media engines. This gives you super flexible UI design 🦋, but the agents obviously need some way to talk to each other. That's especially important for giving one coherent response to a user's conference actions, like joining or leaving a conference.

Now, the Mbone community currently sticks with the loosely coupled conference control model, but sometimes that's not the right fit and you need a more tightly coupled wide-area conference control protocol. In that case, it's highly desirable to reuse the existing tools (media engines) built for loosely coupled conferences and plug them into a system component that runs the tight model 🔥. One good way to do that integration is a communication channel that lets a dedicated conference control entity "remotely" control the media engines, either alongside their user interfaces or instead of them.

Control of device groups in a network: A group of devices connected to a local network, like home appliances on a home network, needs a local coordination mechanism 🏠. Minimizing manual configuration and being able to deploy group communication will be useful in this area too.

1.4. Terminology for requirement specifications 📝

Okay, the key words are the BCP 14 ones, and they get read the way RFC 2119 [1] describes 💅. In this document, the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are interpreted as described in RFC 2119 [1], and they show the requirement levels for compliant Mbus implementations.

2. Common Formal Syntax Rules 📜

This section has the common ABNF [13] syntax elements that later definitions in this document keep referring back to 🧁.

   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

   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

Credit where it's due: these come from RFC 2234 [13] and RFC 2554 [14] 🫶.

3. Message Format 📨

An Mbus message is a header plus a body 💌. The header tells you how and where the message should get delivered, and the body carries the info and commands for the destination entity. The header includes these pieces of info:

  • ProtocolID: a fixed field that identifies the version of the message bus protocol being used. The protocol defined in this document is mbus/1.0 (case-sensitive).
  • SeqNum: every message carries a sequence number ✨. 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. One sequence number is used for all messages from a source, no matter who the intended recipients are or which reliability mode is picked. 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.
    • SeqNums are decimal numbers in ASCII representation.
  • TimeStamp: also in every message 🕰️. It SHOULD contain a decimal number for the time the message was constructed, in milliseconds since 00:00:00, UTC, January 1, 1970.
  • MessageType: tells you what kind of message it is 🔥. The value "R" means the message is sent reliably and MUST be acknowledged by the recipient. The value "U" means it's an unreliable message and MUST NOT be acknowledged.
  • SrcAddr: identifies the sender of the message. This MUST be a complete address, with all address elements specified. The addressing scheme is described in Section 4.
  • DestAddr: identifies the intended recipient(s) of the message. This field MAY be wildcarded by leaving out address elements, which means it can address any number (including zero) of application entities. The addressing scheme is described in Section 4.
  • AckList: a list of SeqNums that this message is an acknowledgment for. See Section 7 for details.

The header is followed by the message body, which holds zero or more commands to be delivered to the destination entity. The syntax for a complete message is given in Section 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 🍓.

4. Addressing 📍

Every entity in the message has its own unique Mbus address that identifies it 🧚. Mbus addresses are sequences of address elements, and each element is a tag/value pair. The tag and the value are split by a colon, and the tag/value pairs are split by whitespace, like this:

   (tag:value tag:value ...)

Here's the formal ABNF syntax for Mbus addresses and their elements:

   mbus_address    = "(" *WSP *1address_list *WSP ")"
   address_list    = address_element
                   / address_element 1*WSP address_list

   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 the other ABNF definitions in this document use the non-terminal symbols defined in Section 2 🤓.

Each address_tag MUST be unique within an Mbus address. In other words, it MUST only occur once 🔒.

Each entity has a fixed sequence of address elements that make up its address, and it MUST only process messages sent to addresses that either match all of its elements or consist of a subset of its own address elements 🎯. The order of the address elements in an address sequence doesn't matter. 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 one string has the same value as the corresponding octet in the second string. For example, an entity with the address of:

   (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

   (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)

A message that should be processed by all entities requires an empty set of address elements 🌸 the "everyone" address, basically.

4.1. Mandatory Address Elements ✨

Okay bestie, every Mbus entity MUST provide one mandatory address element so it can identify itself 🫶. The tag is "id" and the value MUST be composed of the following components 💖

  • The IP address of the interface that gets used for sending messages to the Mbus 🌸. For IPv4 that's 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.

In this specification, this part is called the "host-ID".

  • An identifier ("entity-ID") that is unique within the scope of a single host-ID 🔥. The entity-ID has two parts. For systems where a process ID makes sense, it is RECOMMENDED that this identifier is built from a process-ID and a per-process disambiguator for different Mbus entities of a process. If a process ID isn't 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 written in decimal textual form and MUST be separated by a '-' (ASCII x2d) character.
Heads up: the entity-ID cannot be the port number of the endpoint used for sending messages to the Mbus 🙈. That's because implementations MAY use the common Mbus port number for sending to and receiving from the multicast group (as specified in Section 6).

The complete syntax definition for the entity identifier looks like this 👑

id-element   = "id:" id-value

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.

And here's an example of an id element 🧚

id:4711-99@192.168.1.1

5. Message Syntax 💅

5.1. Message Encoding

All messages MUST use the UTF-8 character encoding 🌈. US ASCII is a subset of UTF-8, so it needs no extra encoding, and a message encoded with UTF-8 won't contain zero bytes.

Each Message MAY be encrypted using a secret key algorithm, as defined in Section 11 🔐.

5.2. Message Header

The fields in the header are separated by white space characters and then followed by CRLF 🎀. The header looks like this:

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 🦋

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".

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)

The definition of production rules for an Mbus command is given in Section 5.3.

5.3. Command Syntax

The header is followed by zero, one, or more commands, delivered to the Mbus entities listed in the DestAddr field 📨. Each command is a command name followed by a list of zero or more parameters, and it ends with a newline.

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 table below 💜

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

List            = "(" *WSP *1(val *(1*WSP val)) *WSP ")"

Symbol          = ALPHA *(ALPHA / DIGIT / "_" / "-" /
                  ".")

Data            = "<" *base64 ">"

Boolean values get encoded as an integer. A value of zero means false, and anything non-zero means true 🍓.

String parameters in the payload MUST be enclosed in the double quote (") character 💅. Inside strings, the escape character is the backslash (), and these escape sequences are defined:

+----------------+-----------+
|Escape Sequence |  Meaning  |
+----------------+-----------+
|      \\        |    \      |
|      \"        |     "     |
|      \n        | newline   |
+----------------+-----------+

List parameters don't have to be homogeneous. They can hold parameters of different types, which is very main character energy 👑

Opaque data is represented as Base64-encoded (see RFC 1521 [7]) character strings surrounded by "< " and "> " 🌸

The ABNF syntax definition for Mbus commands looks like this 🦋

mbus_command = command_name arglist

command_name = Symbol

arglist      = List

Command names SHOULD be built hierarchically, so conceptually related commands sit together under a common hierarchy 🗂️. The delimiter between names in the hierarchy MUST be "." (dot). Application profiles MUST NOT define commands starting with "mbus.". Not allowed, bestie 🙅

The Mbus addressing scheme defined in Section 4 lets you specify incomplete addresses by leaving out some elements of an address element list. That way, entities can send commands to a whole group of Mbus entities 🧁. So all command names SHOULD be unambiguous, meaning they can be interpreted or ignored without considering the message's address.

A set of commands within a certain hierarchy that MUST be understood by every entity is defined in Section 9 💖.

6. Transport 🚀

All messages are sent 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 sent to a fully qualified target address. It MUST be provided by conforming implementations. See Section 6.1 for details.

  1. Directed unicast:

This transport class MAY be used for messages sent to a fully qualified destination address. It is OPTIONAL and does not have to be provided by conforming implementations.

A fully qualified target address is an Mbus address of an existing Mbus entity in an Mbus session 🎯. An implementation can tell that an Mbus address is fully qualified by keeping a list of known entities within an Mbus session. Each known entity has its own unique, fully qualified Mbus address.

Messages travel in UDP datagrams, and a maximum message size of 64 KBytes MUST NOT be exceeded 🙅. It is RECOMMENDED that applications using a non host-local scope don't exceed a message size of the link MTU.

Note that "unicast", "multicast" and "broadcast" mean IP Unicast, IP Multicast and IP Broadcast respectively. It's possible to send an Mbus message addressed to a single entity using IP Multicast 🧚.

This specification covers both Mbus over UDP/IPv4 and Mbus over UDP/IPv6 🎀.

6.1. Local Multicast/Broadcast

In general, the Mbus uses multicast with a limited scope for message transport 📣. Two different Mbus multicast scopes are defined, and either one can be configured for use with an Mbus session:

  1. host-local
  2. link-local

Participants of an Mbus session have to know the multicast address in advance 🫣. It can't be negotiated during the session, because it's already needed for the initial communication between Mbus entities during the bootstrapping phase. It also can't be allocated before an Mbus session, since there'd be no mechanism to announce the allocated address to all potential Mbus entities. So the multicast address has to be assigned statically. This document defines the use of statically assigned addresses, and it also specifies how an Mbus session can be configured to use non-standard, unassigned addresses (see Section 12) 🌟.

The following sections specify how multicast addresses are used for IPv4 and IPv6 🦋.

6.1.1. Mbus multicast groups for IPv4

For IPv4, a statically assigned, scope-relative multicast address is used, as defined by RFC 2365 [11]. The offset for the scope relative address for Mbus is 8 (MBUS, see http://www.iana.org/assignments/multicast-addresses [19]) 🍓.

Different scopes are defined by RFC 2365 [11]. The IPv4 Local Scope (239.255.0.0/16) is the minimal enclosing scope for administratively scoped multicast (as defined by RFC 2365 [11]), and it isn't further divisible. Its exact extent is site dependent 🌸.

For the IPv4 Local Scope, applying the rules of RFC 2365 [11] and using the assigned offset of 8, the Mbus multicast address is therefore 239.255.255.247 ✨.

For IPv4, the two Mbus scopes (host-local and link-local) are realized as follows 💅

  • host-local multicast: Unless configured otherwise, the assigned scope-relative Mbus address in the Local Scope (239.255.255.247 as of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent with a TTL of 0.
  • link-local multicast: Unless configured otherwise, the assigned scope-relative Mbus address in the Local Scope (239.255.255.247 as of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent with a TTL of 1.

6.1.2. Mbus multicast groups for IPv6

IPv6 has different address ranges for different multicast scopes. It distinguishes node local and link local scopes, which are implemented as a set of address prefixes for the different address ranges (RFC 2373 [3]). The link-local prefix is FF02, and the node-local prefix is FF01 🌈. A permanently assigned multicast address will be used for Mbus multicast communication. That means an address that doesn't depend on the scope value and can be used for all scopes. Implementations for IPv6 MUST use the scope-independent address together with 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 🫶.

The permanent IPv6 multicast address for Mbus/Ipv6 is FF0X:0:0:0:0:0:0:300 🔥.

FF0X:0:0:0:0:0:0:300 SHOULD be used for Mbus/IPv6. The X in FF0X shows that the scope isn't fixed, because this is an all scope address. So for node-local scope, FF01:0:0:0:0:0:0:300 SHOULD be used, and for link-local scope, FF02:0:0:0:0:0:0:300 SHOULD be used 💖. See RFC 2375 [4] for IPv6 multicast address assignments.

If a single application system is spread across several co-located hosts, link local scope SHOULD be used for multicasting Mbus messages that might have recipients on the other hosts 🧚. The Mbus protocol is not intended for communication between hosts that aren't on the same link, so it's deliberately not designed for that 🙈. See Section 12 for specifications of Mbus configuration mechanisms.

6.1.3. Use of Broadcast 📡

okay so if multicast isn't an option, broadcast MAY be used instead 🌸 In that case an IP broadcast address for the connected network SHOULD be used for sending. For IPv6, the node-local broadcast address is FF01:0:0:0:0:0:0:1 and the link-local broadcast address is FF02:0:0:0:0:0:0:1. For IPv4, the generic broadcast address (for link-local broadcast) is 255.255.255.255. IPv4 implementations are RECOMMENDED to use the generic broadcast address with a TTL of zero for host-local broadcast 💅

But here's the big rule, bestie 💀 Broadcast MUST NOT be used in situations where multicast is available and supported by all systems participating in an Mbus session. Don't be that main character who broadcasts when multicast is right there! 🙈

See Section 12 for configuring the use of broadcast. ✨

6.1.4. Mbus UDP Port Number 🎀

The registered Mbus UDP port number is 47000. Write it down, it's iconic 🔥

6.2. Directed Unicast 🦋

Directed unicast (via UDP) to the port of a specific application is basically an alternative transport class to multicast 💖 It's an OPTIONAL optimization, so Mbus implementations MAY use it, but only for delivering messages addressed to a single application entity. The implementation has to have learned that entity's address from earlier message exchanges. 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 made of the entity's IP address and a UDP source port number, where that port number is different from the standard Mbus port number ✨

Messages MUST only be sent via unicast if the Mbus target address is unique and if the sending entity can verify that the receiving entity uses a unique endpoint address. The latter can be verified by considering the last message received from that entity 👀

Note that several Mbus entities, say within the same process, may share a common transport address. In this case, the contents of the destination address field is used to further dispatch the message. Given the definition of "unique endpoint address" above, the use of a shared endpoint address and a dispatcher still allows other Mbus entities to send unicast messages to one of the entities that share the endpoint address. So this can be considered an implementation detail 🧚

Messages with an empty target address list MUST always be sent to all Mbus entities (via multicast if available) 📣

The following algorithm can be used by sending entities to determine whether an Mbus address is unique, considering the current set of Mbus entities: 🧐

      let ta=the target address;
      iterate through the set of all
      currently known Mbus addresses {
         let ti=the address in each iteration;
         count the addresses for which
         the predicate isSubsetOf(ta,ti) yields true;
      }

If the count of matching addresses is exactly 1, the address is unique 🎉 The following algorithm can be used for the predicate isSubsetOf, which checks whether the second message matches the first according to the rules specified in Section 4. (A match means that a receiving entity that uses the second Mbus address must also process received messages with the first address as a target address.)

   isSubsetOf(addr a1,a2) yields true, iff
      every address element of a1 is contained
      in a2's address element list.

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 both of the two address element fields (tag and value) have the same values 💜

7. Reliability 🔥

Okay, so most messages are expected to go out using unreliable transport. But sometimes some messages really need to arrive 😭 Reliability can be selected on a per-message basis using the MessageType field. Reliable delivery is only supported for messages with a single recipient, meaning a fully qualified Mbus address. So an entity can only send reliable messages to known addresses, i.e., to entities that have announced their existence on the Mbus (for example, with 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 algorithm that determines whether an address is unique.) A receiving entity MUST only process and acknowledge a reliable message if the destination address exactly matches its own source address. The destination address MUST NOT be a subset of the source address 🙅‍♀️

Disallowing reliable delivery for messages sent to multiple destinations is motivated by simplicity, both of the implementation and of the protocol 🧠 The desired effect can still be achieved at the application layer, by sending individual reliable messages to each fully qualified destination address, as long as the membership information for the Mbus session is available.

Each message is tagged with a message sequence number. If the MessageType is "R", the sender expects an acknowledgment from the recipient within a short period of time. If that acknowledgment doesn't arrive within the 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 is considered to have failed 😬 If the message isn't delivered successfully, the sending application is notified. In this case, it's up to the application to decide what actions (if any) to take.

Reliable messages MUST be acknowledged by adding their SeqNum to the AckList field of a message sent to the originator of the reliable message. This message MUST be sent to a fully qualified Mbus target address. Multiple acknowledgments MAY be sent in a single message. Implementations MAY either piggy-back the AckList onto another message sent to the same destination, or MAY send a dedicated acknowledgment message with no commands in the message payload part 🦋

The precise procedures are as follows: 📝

  • Sender: A sender A of a reliable message M to receiver B MUST transmit the message either via IP-multicast or via IP-unicast, keep a copy of M, initialize a retransmission counter N to 1, and start a retransmission timer T (initialized to T_r). If an acknowledgment is received from B, timer T MUST be cancelled and the copy of M is discarded. If T expires, the message M MUST be retransmitted, the counter N MUST be incremented by one, and the timer MUST be restarted (set to N*T_r). If N exceeds the retransmission threshold N_r, the transmission is assumed to have failed. Further retransmission attempts MUST NOT be undertaken, the copy of M MUST be discarded, and the sending application SHOULD be notified. 💌
  • Receiver: A receiver B of a reliable message from a sender A MUST acknowledge reception of the message within a time period T_c < T_r. This MAY be done by means of a dedicated acknowledgment message, or by piggy-backing the acknowledgment on another message addressed only to A. 🫶
  • Receiver 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. 🧃
  • Constants and Algorithms: The following constants and algorithms SHOULD be used by implementations:
   T_r=100ms

   N_r=3

   T_c=70ms

   T_k=((N_r)*(N_r+1)/2)*T_r

8. Awareness of other Entities 👀✨

Before Mbus entities can communicate with one another, they need to find out about each other's existence 🥹 After this bootstrap procedure, every Mbus entity listening to the same Mbus knows about the newcomer, and the newcomer has learned about all the other entities. Entities also need to be able to notice when another entity fails or leaves 🫠

Any Mbus entity MUST announce its presence (on the Mbus) after starting up 📣 This is to be done repeatedly throughout its lifetime, to deal with startup sequence issues. Entities should always become aware of each other regardless of the order in which they start 🌈

Each Mbus entity MUST maintain the number of Mbus session members and continuously update this number according to any observed changes. The mechanisms for detecting the existence and leaving of other entities 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, which other entities use to monitor that entity's existence. If an entity has not received mbus.hello messages from another entity for a certain time (see Section 8.2), that entity is considered to have left the Mbus and MUST be excluded from the set of currently known entities. Upon receiving an mbus.bye message, the respective entity is considered to have left the Mbus as well and MUST be excluded from the set of currently known entities immediately 💔

Each Mbus entity MUST send hello messages to the Mbus after startup. After transmitting a hello message, it MUST start a timer, and when that timer expires, 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 depends on the current number of entities in an Mbus group, so it can change dynamically to avoid congestion from many entities sending hello messages at a constant high rate 🚦

Section 8.1 specifies the calculation of hello message intervals that MUST be used by protocol implementations. Using the values calculated for the current hello message timer, the timeout for received hello messages is calculated in Section 8.2. Section 9 specifies the command synopsis for the corresponding Mbus messages 🎀

8.1. Hello Message Transmission Interval ✨

okay so the number of entities in an Mbus session can totally change, which means the protocol has to automatically scale across a huge range of group sizes 📈. If every entity sent hello messages at a fixed rate, the average rate at which each entity receives them would grow linearly with the number of entities. With a 1 second interval, an entity in a session of n entities would receive n hello messages every second. If they all lived on one host, that's n*n messages to process per second... which is honestly not it for bigger groups 💀. So we need dynamically adapted hello intervals that take the number of entities into account 🦋. Below, we specify an algorithm that MUST be used by implementors to calculate the interval for hello messages, based on the number of Mbus entities they've observed.

The algorithm has three main vibes:

  • The number of hello messages a single entity receives in a certain time unit stays roughly constant, even as the number of entities changes 💅.
  • Each entity's effective interval is randomized so hello messages don't accidentally sync up across the session 🎲. An entity's very first hello is also delayed by a random amount of time ⏰.
  • A timer reconsideration mechanism adapts the interval when the entity count changes fast. This helps when an entity just joined and is still learning who else is around, or when a bunch of entities leave the Mbus at once 🏃‍♀️💨.

8.1.1. Calculating the Interval for Hello Messages

The following variable names are used in the calculation below (all time values are in milliseconds) 🧮:

  • hello_p: The last time a hello message has been sent by an Mbus entity.
  • hello_now: The current time.
  • hello_d: The deterministic calculated interval between hello messages.
  • hello_e: The effective (randomized) interval between hello messages.
  • hello_n: The time for the next scheduled transmission of a hello message.
  • entities_p: The number of entities at the time hello_n was last recomputed.
  • entities: The number of currently known entities.

The interval between hello messages MUST be calculated as follows 👀:

Multiply the number of currently known entities by c_hello_factor, and you get the interval between hello messages in milliseconds. That's the deterministic calculated interval, called hello_d. The minimum value for hello_d is c_hello_min, so:

hello_d = max(c_hello_min,c_hello_factor * entities * 1ms)

Section 8 explains how to get the number of currently known entities. Section 10 has the values for the constants c_hello_factor and c_hello_min.

The effective interval hello_e that individual entities use is calculated by multiplying hello_d by a randomly chosen number between c_hello_dither_min and c_hello_dither_max, like this:

hello_e = c_hello_dither_min +
          RND * (c_hello_dither_max - c_hello_dither_min)

RND is a random function that gives an even distribution between 0 and 1. See also Section 10.

hello_n, the time for the next hello message in milliseconds, is set to hello_e + hello_now 🎯.

8.1.2. Initialization of Values

When an entity joins an Mbus session, the protocol implementation sets hello_p=0, hello_now=0, and entities=1, entities_p=1 (that's the Mbus entity itself) 🙋‍♀️. Then it calculates the time for the next hello message as specified in Section 8.1.1. The next hello message gets scheduled for transmission at hello_n.

8.1.3. Adjusting the Hello Message Interval when the Number of Entities increases

When a protocol implementation spots a new entity, it updates its count of currently known entities. No further action is needed for the hello message interval calculation 🙌. The timer gets reconsidered when the current timer for the next hello message expires (see Section 8.1.5).

8.1.4. Adjusting the Hello Message Interval when the Number of Entities decreases

When an entity realizes another entity has left the Mbus, it updates the count of currently known entities. Then the following algorithm should be used to reconsider the timer interval for hello messages 🔄:

  1. The value for hello_n is updated by setting 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)
  3. The currently active timer for the next hello messages is cancelled, and a new timer is started for hello_n.
  4. entities_p is set to entities.

8.1.5. Expiration of hello timers

When the hello message timer expires, the protocol implementation MUST perform the following operations ⏱️:

The hello interval hello_e is computed as specified in Section 8.1.1.

  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.
  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.

entities_p is set to entities.

8.2. Calculating the Timeout for Mbus Entities

Whenever an Mbus entity hasn't heard from another Mbus entity for a time span of c_hello_dead*(hello_d*c_hello_dither_max) milliseconds, it may consider that entity to have failed (or to have quit silently) 💀. The number of currently known entities MUST be updated accordingly. See Section 8.1.4 for details. Note that this observation doesn't necessarily mean any further action is needed 🤷‍♀️.

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.

9. Messages 💌

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. Those get defined outside of the basic Mbus protocol specification, in separate Mbus profiles.

9.1. mbus.hello

Syntax:

mbus.hello()

Parameters: - none -

mbus.hello messages MUST be sent unreliably to all Mbus entities 📣.

Each Mbus entity learns about the others by observing their mbus.hello messages and tracking the sender address of each message. That's how it can calculate the current number of entities 🧮.

mbus.hello messages MUST be sent periodically, in dynamically calculated intervals as specified in Section 8.

Upon startup, the first mbus.hello message MUST be sent after a delay hello_delay, where hello_delay is a randomly chosen number between 0 and c_hello_min (see Section 10) 🎲.

9.2. mbus.bye

Syntax:

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.

9.3. mbus.ping

Syntax:

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 is 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 arrive while the entity is waiting hello_delay time units before transmitting the mbus.hello message, no extra mbus.hello message needs to be scheduled for those additional mbus.ping messages 🧠.

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.)

mbus.ping lets a new entity 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's interested in 🎯.

9.4. mbus.quit

Syntax:

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.

The mbus.quit message can be multicast, or sent reliably via unicast to a single Mbus entity or a group of entities 📬.

9.5. mbus.waiting

Syntax:

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. It's kinda like 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. That's similar to a semaphore's V() operation ✨.

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) 🔁.

If an application wants to indicate that it's 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 📦.

9.6. mbus.go

Syntax:

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's 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 🧁.

The mbus.go message MUST be sent reliably via unicast to the Mbus entity to unblock 💖.

10. Constants 💖

okay bestie, these are the timer and counter values you SHOULD use in your implementation so everything stays in sync ✨ the table is right here:

+-------------------+------------------------+--------------+
|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                      |     -        |
+-------------------+------------------------+--------------+

and these are the other values the doc uses 🧚

   T_r=100ms

   N_r=3

   T_c=70ms

   T_k=((N_r)*(N_r+1)/2)*T_r

11. Mbus Security 🔐

11.1. Security Model

so the goal here is to stop random disturbances from messages sent by applications belonging to other users 🙈 the way we do that is message authentication (see Section 11.3). every message needs a digest that gets calculated from a shared secret key value, and receivers MUST check that the sender is in the same Mbus security domain by recalculating the digest and comparing it to the one they got. messages MUST only be processed further if both values are equal. and to allow different Mbus sessions at the same scope to run at once, and to make up for buggy host local multicast implementations, message authentication MUST be provided by conforming implementations 💅

privacy is a whole vibe too 🦋 you can get it by optionally using symmetric encryption (see Section 11.2). each message MAY be encrypted with an extra shared secret key and a symmetric encryption algorithm. encryption is OPTIONAL for applications, so it's totally allowed to set up an Mbus domain without it. BUT conforming implementations MUST provide the possibility to use message encryption (see below) 🌸

the algorithms and parameters (the keys, etc.) live in an Mbus configuration object that every Mbus entity in a session can access. to get interoperability, conforming implementations SHOULD use the values from that Mbus configuration. Section 12 lists the mandatory and optional parameters and how to store them on different platforms. alternative ways of configuring Mbus protocol entities MAY be used ONLY in cases where none of the options in Section 12 works 👑

the algorithms and procedures for encryption and authentication are in the sections below ✨

11.2. Encryption

encryption is OPTIONAL, which just means an Mbus MAY be configured not to use encryption 🍓

implementations can pick between different encryption algorithms. every conforming implementation MUST provide the AES [18] algorithm. on top of that, the following algorithms SHOULD be supported: DES [16], 3DES (triple DES) [16] and IDEA [20] 💜

for algorithms that need the data padded to certain boundaries, octets with a value of 0 SHOULD be used as the padding characters 🫶

the length of the encryption keys depends on the encryption algorithm you're using right now. so the configured encryption key MUST NOT be shorter than the native key length for that 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], which ends up as 12 Base64-encoded characters. IDEA uses 128-bit keys (24 Base64-encoded characters). AES can use 128-bit, 192-bit or 256-bit keys, but for Mbus encryption using AES, only 128-bit keys (24 Base64-encoded characters) MUST be used 💀

11.3. Message Authentication

for authentication, hashed message authentication codes (HMACs) as described in RFC 2104 [5] are used 🌈 implementations can choose from a bunch of digest algorithms. for Mbus authentication, the HMAC algorithm MUST be applied like this:

the keyed hash value gets calculated with the HMAC algorithm from RFC 2104 [5]. the specific hash algorithm and the secret hash key MUST be obtained from the Mbus configuration (see Section 12). the keyed hash values (see RFC 2104 [5]) MUST be truncated to 96 bits (12 octets). then the resulting 12 octets MUST be Base64-encoded, which gives you 16 Base64-encoded characters (see RFC 1521 [7]).

either MD5 [15] or SHA-1 [17] SHOULD be used for message authentication codes (MACs). an implementation MAY provide MD5, but SHA-1 MUST be implemented 🎀

the length of the hash keys depends on the hashing algorithm you pick. so the configured hash key MUST NOT be shorter than the native key length for the algorithm you're using right now 🧚

11.4. Procedures for Senders and Receivers

the algorithms that MUST be provided by implementations are AES and SHA-1 💖

see Section 12 for the notation used for Base64-strings ✨

a sender MUST apply these operations to a message it's about to send:

  1. if encryption is enabled, the message MUST be encrypted with 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 isn't enabled, the message stays as it is.
  2. next, a message authentication code (MAC) gets calculated for the (encrypted) message with the configured HMAC algorithm and the configured hash key.
  3. the MAC MUST then be converted to Base64 encoding, which gives 16 Base64 characters as specified in Section 11.3.
  4. at last, the sender MUST build the final message by putting the (encrypted) message after the Base64-encoded MAC and a CRLF. here's the ABNF for the final message:
   final_msg = MsgDigest CRLF encr_msg

   MsgDigest = base64

   encr_msg  = *OCTET

a receiver MUST apply these operations to a message it has received:

  1. split the Base64-encoded MAC from the (encrypted) message and decode the MAC.
  2. recalculate the MAC for the message with the configured HMAC algorithm and the configured hash key.
  3. compare the original MAC with the recalculated MAC. if they differ, the message MUST be discarded without further processing 🙅‍♀️
  4. if encryption is enabled, the message MUST be decrypted with the configured algorithm and the configured encryption key. trailing octets with a value of 0 MUST be deleted. if the message doesn't start with the string "mbus/", the message MUST be discarded without further processing 💅

12. Mbus Configuration 🎀

an implementation MUST be configurable with these parameters:

  • Configuration version: the version number of the given configuration entity. version numbers let implementations check whether they can process the entries of a given configuration entity. version numbers are integer values. the version number for the version specified here is 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 parameters above are mandatory and MUST be present in every Mbus configuration entity 💖

the following parameters are optional. when they are present they MUST be honored. when they aren't present, implementations SHOULD fall back to the predefined default values (as defined in Transport (Section 6)):

  • Address: the non-standard multicast address to use for message transport. 🦋
  • Use of Broadcast: it can be specified whether broadcast should be used. if broadcast has been configured, implementations SHOULD use the network broadcast address (as specified in Section 6.1.3) instead of the standard multicast address. 📡
  • Port Number: the non-standard UDP port number to use for message transport. 🌸

two separate 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 🪟

the syntax of the values for each parameter entry stays the same for both configuration facilities. the following defines a set of ABNF (see RFC 2234 [13]) productions that get reused later for the configuration file syntax and registry entries 🧩

   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 ")"

   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")"

algo-id is one of the character strings listed above. for algo-id=="NOENCR", the other fields are ignored. the delimiting commas MUST always be present though 🫶

a Base64 string is made of the characters defined in the Base64 char-set (see RFC 1521 [7]), including all possible padding characters. that means the length of a Base64 string is always a multiple of 4 ✨

the scope parameter configures an IP-Multicast scope and may be set to either "HOSTLOCAL" or "LINKLOCAL". implementations SHOULD choose an appropriate IP-Multicast scope based on this value and build an effective IP address using the specifications in Section 6.1 🌈

broadcast is configured by putting the value "BROADCAST" in the address field. if broadcast has been configured, implementations SHOULD use the network broadcast address for the IP version in use instead of the standard multicast address 📣

the version_number parameter specifies a version number for the configuration entity being used 🔢

12.1. File based parameter storage 🎀

okay so the Mbus config file lives at .mbus in your home directory 🏠 and if you've got an environment variable called MBUS set, implementations SHOULD treat its value as the fully qualified file name for the config file instead 💖 bestie, the file permissions MUST be locked down so other users can't read or write it 🔒 the file MUST already exist before a conference gets started, and its contents MUST be UTF-8 encoded and MUST follow this syntax ✨

mbus-file     =    mbus-topic LF *(entry LF)

mbus-topic    =    "[MBUS]"

entry         =     1*(version_info / hashkey_info
                       / encryptionkey_info / scope_info
                       / port_info / address_info)

version_info  =    "CONFIG_VERSION=" version_number

hashkey_info  =    "HASHKEY=" key_value

encrkey_info  =    "ENCRYPTIONKEY=" key_value

scope_info    =    "SCOPE=" scope

port_info     =    "PORT=" port

address_info  =    "ADDRESS=" address

the entries you can use are CONFIG_VERSION, HASHKEY, ENCRYPTIONKEY, SCOPE, PORT and ADDRESS 🌈 CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory, so they MUST show up in every single Mbus config file 🫶 the order of the entries doesn't matter at all, so do you 💅

here's a cute example config file 🦋

[MBUS]
CONFIG_VERSION=1
HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy)
ENCRYPTIONKEY=(DES,MTIzMTU2MQ==)
SCOPE=HOSTLOCAL
ADDRESS=224.255.222.239
PORT=47000

12.2. Registry-based parameter storage 🌸

for systems that don't have a home directory as a place for config files (hello, Windows 9x, NT, 2000 and XP 👀), the suggested database for config settings is the registry, and implementations SHOULD use it 💜 the Mbus registry entries live under this hierarchy 🗂️

HKEY_CURRENT_USER\Software\Mbus

these are the entries in that hierarchy, lined up nice and neat 💅

+---------------+--------+----------------+
|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 key values in the registry MUST use the exact same syntax as the file based config facility 🔥

13. Security Considerations 🔐

okay bestie, serious moment incoming 🥺 the Mbus security mechanisms are all specified in Section 11.1 🛡️

it should be noted that the Mbus transport spec defines a mandatory baseline set of algorithms that every implementation has to support 🤝 that baseline is there to give you reasonable security by requiring algorithms and key lengths that were considered cryptographically strong enough at the time of writing ✨

BUT (and this is a big but 🙈) you're allowed to use cryptographically weaker algorithms for efficiency, like HMAC-MD5 instead of HMAC-SHA1 💀 encryption can also be turned off completely if privacy is handled some other way or just isn't a big deal for your application 🍓

so users of the Mbus should be aware of which security configuration they picked, and check whether it meets the security demands of their application 👑 since every implementation MUST provide the cryptographically strong algorithm, it should always be possible to set up an Mbus so that communication with authentication and privacy is ensured 🦋

also, application developers should watch out for buggy IP implementations that don't conform to RFC 1122 [2] and send datagrams with TTL values of zero 😭 that means Mbus messages can end up on the local network link even when a user picked host local scope in their Mbus configuration 🙃 when you're using administratively scoped multicast, users can't always count on boundary routers being configured correctly 🚧 in those cases, the use of encryption SHOULD be considered if privacy is desired 🔒

14. IANA Considerations 🧚

the IANA 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 💖

the registered Mbus UDP port number is 47000 🎀

15. References 📚

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[2] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.

[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

[4] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.

[5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.

[6] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.

[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.

[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.

[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.

[11] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.

[12] Balenson, D., "Privacy Enhancement for Internet Electronic Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, February 1993.

[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[14] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.

[15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.

[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.

[17] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995.

[18] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March 1999.

[19] IANA, "Internet Multicast Addresses", URL http://www.iana.org/assignments/multicast-addresses, May 2001.

[20] Schneier, B., "Applied Cryptography", Edition 2, Publisher John Wiley & Sons, Inc., status: non-normative, 1996.

Appendix A. About References 💅

okay so the reference list has both normative and non-normative refs in it 🤓 each non-normative reference is marked "status: non-normative" ✨ every unmarked reference is normative, so that's how you can tell them apart 🫶

Appendix B. Limitations and Future Work 🌧️

the Mbus is a light-weight local coordination mechanism and it's deliberately NOT built for bigger scope coordination 🙅 it's expected to be used on a single node or, at most, on a single network link 🧸

so yeah, the Mbus protocol doesn't have the features it would need to be used over the global Internet 😭

No congestion control 🚫: there aren't any mechanisms for congestion control. It's a general problem for multicast protocols. Mbus allows un-acknowledged messages that are sent unreliably (think event notifications going from one entity to another). Since negative acknowledgements aren't defined, the sender has no way to realize it's flooding another entity or congesting a low bandwidth network segment 💀
Retransmission timers ⏱️: the reliability mechanism (the retransmission timers) is designed for effective, responsive message transport on local links. It isn't suited to coping with the larger delays that could come from router queues and things like that 🙈

some experiments are currently underway to test bridges between different distributed Mbus domains without changing the basic protocol semantics 🌉 since those bridges should be orthogonal to the basic Mbus protocol definitions, and the experiments are still a work in progress, this spec doesn't mention the concept at all 🚧

Authors' Addresses 🖋️

Joerg Ott
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen  28359
Germany

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

EMail: csp@isi.edu
Dirk Kutscher
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen  28359
Germany

Phone: +49.421.218-7595
Fax:   +49.421.218-7000
EMail: dku@tzi.uni-bremen.de

Copyright (C) The Internet Society (2002). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

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. 💖

📦 where this page comes from