As per Relevance of the word information, we have this rfc below:
Network Working Group J.
Request for Comments: 3259 TZI, Universitaet
Category: Informational C.
USC Information Sciences
D.
TZI, Universitaet
April 2002
A Message Bus for Local
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
The local Message Bus (Mbus) is a light-weight message-
coordination protocol for group communication between
components. The Mbus provides automatic location of
peers, subject based addressing, reliable message transfer
different types of communication schemes. The protocol is layered
top of IP multicast and is specified for IPv4 and IPv6. The
multicast scope is limited to link-local multicast. This
specifies the Mbus protocol, i.e., message syntax, addressing
transport mechanisms
Table of
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
Ott, et. al. Informational [Page 1]
RFC 3259 A Message Bus for Local Coordination April 2002
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
Entities increases . . . . . . . . . . . . . . . . . . . . . 23
8.1.4 Adjusting the Hello Message Interval when the Number
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
Ott, et. al. Informational [Page 2]
RFC 3259 A Message Bus for Local Coordination April 2002
1.
The implementation of multiparty multimedia conferencing systems
one example where a simple coordination infrastructure can be useful
In a variety of conferencing scenarios, a local communication
can provide conference-related information exchange between co
located but otherwise independent application entities, for
those taking part in application sessions that belong to the
conference. In loosely coupled conferences such a mechanism
for coordination of application entities, e.g., to
synchronization between media streams or to configure
without user interaction. It can also be used to implement
coupled conferences enabling a conference controller to
conference wide control within an end system
Conferencing systems such as IP telephones can also be viewed
components of a distributed system and can thus be integrated into
group of application modules: For example, an IP telephony call
is conducted with a stand-alone IP telephone can be
extended to include media engines for other media types using
coordination function of an appropriate coordination mechanism
Different individual conferencing components can thus be combined
build a coherent multimedia conferencing system for a user
Other possible scenarios include the coordination of
components that are distributed on different hosts in a network,
example, so-called Internet appliances
1.1 Mbus
Local coordination of application components requires a number
different interaction models: some messages (such as
information, floor control notifications, dissemination of
state changes, etc.) may need to be sent to all local
entities. Messages may also be targeted at a certain
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
any (application- or message-specific) subgrouping defining
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
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
communication needs by defining different message
mechanisms (defined in Section 6) and by providing a
addressing scheme (defined in Section 4).
Ott, et. al. Informational [Page 3]
RFC 3259 A Message Bus for Local Coordination April 2002
Furthermore, Mbus messages exchanged between application entities
have different reliability requirements (which are typically
from their semantics). Some messages will have a rather
character conveying ephemeral state information (which
refreshed/updated periodically), such as the volume meter level of
audio receiver entity to be displayed by its user interface agent
Certain Mbus messages (such as queries for parameters or queries
local servers) may require a response from the peer(s),
providing an explicit acknowledgment at the semantic level on top
the Mbus. Other messages will modify the application or
state and hence it is crucial that they do not get lost. The
type of message has to be delivered reliably to the recipient
whereas messages of the first type do not require
mechanisms at the Mbus transport layer. For messages confirmed
the application layer it is up to the discretion of the
whether or not to use a reliable transport underneath
In some cases, application entities will want to tailor the degree
reliability to their needs, others will want to rely on
underlying transport to ensure delivery of the messages -- and
may be different for each Mbus message. The Mbus message
mechanism specified in this document provides a maximum
flexibility by providing reliable transmission achieved
transport-layer acknowledgments (in case of point-to-
communications only) as well as unreliable message passing (
unicast, local multicast, and local broadcast). We address
topic in Section 4.
Finally, accidental or malicious disturbance of Mbus
through messages originated by applications from other users needs
be prevented. Accidental reception of Mbus messages from other
may occur if either two users share the same host for using
applications or if they are using Mbus applications that are
across the same network link: in either case, the used Mbus
address and the port number may be identical leading to reception
the other party's Mbus messages in addition to the user's own ones
Malicious disturbance may happen because of applications
(e.g., at a global scope) or unicasting Mbus messages. To
the possibility of processing unwanted Mbus messages, the
protocol contains message digests for authentication. Furthermore
the Mbus allows for encryption to ensure privacy and thus
using the Mbus for local key distribution and other
potentially sensitive to eavesdropping. This document defines
framework for configuring Mbus applications with regard to
parameters in Section 12.
Ott, et. al. Informational [Page 4]
RFC 3259 A Message Bus for Local Coordination April 2002
1.2 Purpose of this
Three components constitute the message bus: the low level
passing mechanisms, a command syntax and naming hierarchy, and
addressing scheme
The purpose of this document is to define the protocol mechanisms
the lower level Mbus message passing mechanism which is common to
Mbus implementations. This includes the specification
o the generic Mbus message format
o the addressing concept for application entities (note
concrete addressing schemes are to be defined by application
specific profiles);
o the transport mechanisms to be employed for conveying
between (co-located) application entities
o the security concept to prevent misuse of the Message Bus (such
taking control of another user's conferencing environment);
o the details of the Mbus message syntax;
o a set of mandatory application independent commands that are
for bootstrapping Mbus sessions
1.3 Areas of
The Mbus protocol can be deployed in many different
areas, including but not limited to
Local conference control: In the Mbone community a model has
whereby a set of loosely coupled tools are used to participate
a conference. A typical scenario is that audio, video, and
workspace functionality is provided by three separate
(although some combined tools exist). This maps well onto
underlying RTP [8] (as well as other) media streams, which
also transmitted separately. Given such an architecture, it
useful to be able to perform some coordination of the
media tools. For example, it may be desirable to
playout-point information between audio and video tools, in
to implement lip-synchronization, to arbitrate the use of
resources (such as input devices), etc
A refinement of this architecture relies on the presence of
number of media engines which perform protocol functions as
as capturing and playout of media. In addition, one (or more
Ott, et. al. Informational [Page 5]
RFC 3259 A Message Bus for Local Coordination April 2002
(separate) user interface agents exist that interact with
control their media engine(s). Such an approach
flexibility in the user-interface design and implementation,
obviously requires some means by which the various involved
may communicate with one another. This is particularly
to enable a coherent response to a user's conference-
actions (such as joining or leaving a conference).
Although current practice in the Mbone community is to work with
loosely coupled conference control model, situations arise
this is not appropriate and a more tightly coupled wide-
conference control protocol must be employed. In such cases,
is highly desirable to be able to re-use the existing tools (
engines) available for loosely coupled conferences and
them with a system component implementing the tight
control model. One appropriate means to achieve this
is a communication channel that allows a dedicated
control entity to "remotely" control the media engines in
to or instead of their respective user interfaces
Control of device groups in a network: A group of devices that
connected to a local network, e.g., home appliances in a
network, require a local coordination mechanism.
manual configuration and the the possibility to deploy
communication will be useful in this application area as well
1.4 Terminology for requirement
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]
indicate requirement levels for compliant Mbus implementations
2. Common Formal Syntax
This section contains definitions of common ABNF [13] syntax
that are later referenced by other definitions in this document
base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] )
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-
base64_terminal = (2base64_char "==") / (3base64_char "=")
UPALPHA = %x41-5A ;; Uppercase: A-
Ott, et. al. Informational [Page 6]
RFC 3259 A Message Bus for Local Coordination April 2002
LOALPHA = %x61-7A ;; Lowercase: a-
ALPHA = %x41-5A / %x61-7A ; A-Z / a-
CHAR = %x01-7
; any 7-bit US-ASCII character
excluding NUL and
OCTET = %x00-
; 8 bits of
CR = %x0
; carriage
CRLF = CR
; Internet standard
DIGIT = %x30-39
; 0-9
DQUOTE = %x22
; " (Double Quote
HTAB = %x09
; horizontal
LF = %x0
;
LWSP = *(WSP / CRLF WSP
; linear white space (past newline
SP = %x20
;
WSP = SP /
; white
Taken from RFC 2234 [13] and RFC 2554 [14].
3. Message
An Mbus message comprises a header and a body. The header is used
indicate how and where a message should be delivered and the
provides information and commands to the destination entity.
following pieces of information are included in the header
Ott, et. al. Informational [Page 7]
RFC 3259 A Message Bus for Local Coordination April 2002
A fixed ProtocolID field identifies the version of the message
protocol used. The protocol defined in this document
"mbus/1.0" (case-sensitive).
A sequence number (SeqNum) is contained in each message.
first message sent by a source SHOULD set SeqNum to zero, and
MUST increment by one for each message sent by that source.
single sequence number is used for all messages from a source
irrespective of the intended recipients and the reliability
selected. The value range of a sequence number is (0,4294967295).
An implementation MUST re-set its sequence number to 0
reaching 4294967295. Implementations MUST take into account
the SeqNum of other entities may wrap-around
SeqNums are decimal numbers in ASCII representation
The TimeStamp field is also contained in each message and
contain a decimal number representing the time of the
construction in milliseconds since 00:00:00, UTC, January 1, 1970.
A MessageType field indicates the kind of message being sent.
value "R" indicates that the message is to be transmitted
and MUST be acknowledged by the recipient, "U" indicates
unreliable message which MUST NOT be acknowledged
The SrcAddr field identifies the sender of a message. This
be a complete address, with all address elements specified.
addressing scheme is described in Section 4.
The DestAddr field identifies the intended recipient(s) of
message. This field MAY be wildcarded by omitting
elements and hence address any number (including zero)
application entities. The addressing scheme is described
Section 4.
The AckList field comprises a list of SeqNums for which
message is an acknowledgment. See Section 7 for details
The header is followed by the message body which contains zero
more commands to be delivered to the destination entity. The
for a complete message is given in Section 5.
If multiple commands are contained within the same Mbus
payload, they MUST to be delivered to the Mbus application in
same sequence in which they appear in the message payload
Ott, et. al. Informational [Page 8]
RFC 3259 A Message Bus for Local Coordination April 2002
4.
Each entity in the message has a unique Mbus address that is used
identify the entity. Mbus addresses are sequences of
elements that are tag/value pairs. The tag and the value
separated by a colon and tag/value pairs are separated by whitespace
like this
(tag:value tag:value ...)
The formal ABNF syntax definition for Mbus addresses and
elements is as follows
mbus_address = "(" *WSP *1address_list *WSP ")"
address_list = address_
/ address_element 1*WSP address_
address_element = address_tag ":" address_
address_tag = 1*32(ALPHA
address_value = 1*64(%x21-27 / %x2A-7E
; any 7-bit US-ASCII
; excluding white space, delete
; control characters, "(" and ")"
Note that this and other ABNF definitions in this document use
non-terminal symbols defined in Section 2.
An address_tag MUST be unique within an Mbus address, i.e., it
only occur once
Each entity has a fixed sequence of address elements constituting
address and MUST only process messages sent to addresses that
match all elements or consist of a subset of its own
elements. The order of address elements in an address sequence
not relevant. Two address elements match if both their tags
their values are equivalent. Equivalence for address element
address value strings means that each octet in the one string has
same value as the corresponding octet in the second string.
example, an entity with an address of
(conf:test media:audio module:engine app:rat id:4711-1@192.168.1.1)
will process messages sent
(media:audio module:engine
Ott, et. al. Informational [Page 9]
RFC 3259 A Message Bus for Local Coordination April 2002
(module:engine
but must ignore messages sent
(conf:test media:audio module:engine app:rat id:123-4@192.168.1.1
foo:bar
(foo:bar
A message that should be processed by all entities requires an
set of address elements
4.1 Mandatory Address
Each Mbus entity MUST provide one mandatory address element
allows it to identify the entity. The element tag is "id" and
value MUST be be composed of the following components
o The IP address of the interface that is used for sending
to the Mbus. For IPv4 this is the address in dotted
notation. For IPv6 the interface-ID-part of the node's link-
address in textual representation as specified in RFC 2373 [3]
MUST be used
In this specification, this part is called the "host-ID".
o An identifier ("entity-ID") that is unique within the scope of
single host-ID. The entity comprises two parts. For
where the concept of a process ID is applicable it is
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
be randomly chosen (it is recommended that at least a 32
random number is chosen). Both numbers are represented in
textual form and MUST be separated by a '-' (ASCII x2d) character
Note that the entity-ID cannot be the port number of the
used for sending messages to the Mbus because implementations MAY
the common Mbus port number for sending to and receiving from
multicast group (as specified in Section 6).
The complete syntax definition for the entity identifier is
follows
Ott, et. al. Informational [Page 10]
RFC 3259 A Message Bus for Local Coordination April 2002
id-element = "id:" id-
id-value = entity-id "@" host-
entity-id = 1*10DIGIT "-" 1*5
host-id = (IPv4address / IPv6address
Please refer to [3] for the productions of IPv4address and IPv6address
An example for an id element
id:4711-99@192.168.1.1
5. Message
5.1 Message
All messages MUST use the UTF-8 character encoding. Note that
ASCII is a subset of UTF-8 and requires no additional encoding,
that a message encoded with UTF-8 will not contain zero bytes
Each Message MAY be encrypted using a secret key algorithm
defined in Section 11.
5.2 Message
The fields in the header are separated by white space characters
and followed by CRLF. The format of the header is as follows
msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*
MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP
The header fields are explained in Message Format (Section 3).
are the ABNF syntax definitions for the header fields
SeqNum = 1*10DIGIT ; numeric range 0 - 2^32-1
TimeStamp = 1*13
MessageType = "R" / "U
ScrAddr = mbus_
DestAddr = mbus_
Ott, et. al. Informational [Page 11]
RFC 3259 A Message Bus for Local Coordination April 2002
AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")"
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
Section 5.3.
5.3 Command
The header is followed by zero, one, or more, commands to
delivered to the Mbus entities indicated by the DestAddr field.
command consists of a command name that is followed by a list
zero, or more parameters and is terminated by a newline
command ( parameter parameter ... )
Syntactically, the command name MUST be a `symbol' as defined in
following table. The parameters MAY be any data type drawn from
following table
val = Integer / Float / String / List /
Symbol /
Integer = *1"-" 1*
Float = *1"-" 1*DIGIT "." 1*
String = DQUOTE *CHAR
; see below for escape
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
representing false, and non-zero representing true
Ott, et. al. Informational [Page 12]
RFC 3259 A Message Bus for Local Coordination April 2002
String parameters in the payload MUST be enclosed in the double
(") character. Within strings, the escape character is the
(\), and the following escape sequences are defined
+----------------+-----------+
|Escape Sequence | Meaning |
+----------------+-----------+
| \\ | \ |
| \" | " |
| \n | newline |
+----------------+-----------+
List parameters do not have to be homogeneous lists, i.e., they
contain parameters of different types
Opaque data is represented as Base64-encoded (see RFC 1521 [7])
character strings surrounded by "< " and "> "
The ABNF syntax definition for Mbus commands is as follows
mbus_command = command_name
command_name =
arglist =
Command names SHOULD be constructed hierarchically to
conceptually related commands under a common hierarchy.
delimiter between names in the hierarchy MUST be "." (dot).
Application profiles MUST NOT define commands starting with "mbus.".
The Mbus addressing scheme defined in Section 4 allows
incomplete addresses by omitting certain elements of an
element list, enabling entities to send commands to a group of
entities. Therefore, all command names SHOULD be unambiguous in
way that it is possible to interpret or ignore them
considering the message's address
A set of commands within a certain hierarchy that MUST be
by every entity is defined in Section 9.
6.
All messages are transmitted as UDP messages, with two
alternatives
Ott, et. al. Informational [Page 13]
RFC 3259 A Message Bus for Local Coordination April 2002
1. Local multicast/broadcast
This transport class MUST be used for all messages that are
sent to a fully qualified target address. It MAY also be used
messages that are sent to a fully qualified target address.
MUST be provided by conforming implementations. See Section 6.1
for details
2. Directed unicast
This transport class MAY be used for messages that are sent to
fully qualified destination address. It is OPTIONAL and does
have to be provided by conforming implementations
A fully qualified target address is an Mbus address of an
Mbus entity in an Mbus session. An implementation can identify
Mbus address as fully qualified by maintaining a list of
entities within an Mbus session. Each known entity has its
unique, fully qualified Mbus address
Messages are transmitted in UDP datagrams, a maximum message size
64 KBytes MUST NOT be exceeded. It is RECOMMENDED that
using a non host-local scope do not exceed a message size of the
MTU
Note that "unicast", "multicast" and "broadcast" mean IP Unicast,
Multicast and IP Broadcast respectively. It is possible to send
Mbus message that is addressed to a single entity using IP Multicast
This specification deals with both Mbus over UDP/IPv4 and Mbus
UDP/IPv6.
6.1 Local Multicast/
In general, the Mbus uses multicast with a limited scope for
transport. Two different Mbus multicast scopes are defined,
of which can be configured to be used with an Mbus session
1. host-
2. link-
Participants of an Mbus session have to know the multicast address
advance -- it cannot be negotiated during the session since it
already needed for initial communication between the Mbus
during the bootstrapping phase. It also cannot be allocated prior
an Mbus session because there would be no mechanism to announce
allocated address to all potential Mbus entities. Therefore,
multicast address has to be assigned statically. This
defines the use of statically assigned addresses and also provides
Ott, et. al. Informational [Page 14]
RFC 3259 A Message Bus for Local Coordination April 2002
specification of how an Mbus session can be configured to use non
standard, unassigned addresses (see Section 12).
The following sections specify the use of multicast addresses
IPv4 and IPv6.
6.1.1 Mbus multicast groups for IPv
For IPv4, a statically assigned, scope-relative multicast address
defined by RFC 2365 [11] is used. The offset for the scope
address for Mbus is 8 (MBUS,
http://www.iana.org/assignments/multicast-addresses [19]).
Different scopes are defined by RFC 2365 [11]. The IPv4 Local
(239.255.0.0/16) is the minimal enclosing scope for
scoped multicast (as defined by RFC 2365 [11]) and not
divisible -- its exact extent is site dependent
For the IPv4 Local Scope, applying the rules of RFC 2365 [11]
using the assigned offset of 8, the Mbus multicast address
therefore 239.255.255.247.
For IPv4, the different defined Mbus scopes (host-local and link
local) are to be realized as follows
host-local multicast: Unless configured otherwise, the
scope-relative Mbus address in the Local Scope (239.255.255.247
of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be
with a TTL of 0.
link-local multicast: Unless configured otherwise, the
scope-relative Mbus address in the Local Scope (239.255.255.247
of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be
with a TTL of 1.
6.1.2 Mbus multicast groups for IPv
IPv6 has different address ranges for different multicast scopes
distinguishes node local and link local scopes, that are
as a set of address prefixes for the different address ranges (
2373 [3]). The link-local prefix is FF02, the node-local prefix
FF01. A permanently assigned multicast address will be used for
multicast communication, i.e., an address that is independent of
scope value and that can be used for all scopes. Implementations
IPv6 MUST use the scope-independent address and the
prefix for the selected scope. For host-local Mbus communication
IPv6 node-local scope prefix MUST be used, for link-local
communication the IPv6 link-local scope prefix MUST be used
Ott, et. al. Informational [Page 15]
RFC 3259 A Message Bus for Local Coordination April 2002
The permanent IPv6 multicast address for Mbus/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 FF0
indicates that the scope is not fixed because this is an all
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
be used. See RFC 2375 [4] for IPv6 multicast address assignments
If a single application system is distributed across several co
located hosts, link local scope SHOULD be used for multicasting
messages that potentially have recipients on the other hosts.
Mbus protocol is not intended (and hence deliberately not designed
for communication between hosts not on the same link. See Section 12
for specifications of Mbus configuration mechanisms
6.1.3 Use of
In situations where multicast is not available, broadcast MAY be
instead. In these cases an IP broadcast address for the
network SHOULD be used for sending. The node-local broadcast
for IPv6 is FF01:0:0:0:0:0:0:1, the link-local broadcast address
IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the generic broadcast
(for link-local broadcast) is 255.255.255.255. It is
that IPv4-implementations use the generic broadcast address and a
of zero for host-local broadcast
Broadcast MUST NOT be used in situations where multicast is
and supported by all systems participating in an Mbus session
See Section 12 for configuring the use of broadcast
6.1.4 Mbus UDP Port
The registered Mbus UDP port number is 47000.
6.2 Directed
Directed unicast (via UDP) to the port of a specific application
an alternative transport class to multicast. Directed unicast is
OPTIONAL optimization and MAY be used by Mbus implementations
delivering messages addressed to a single application entity only --
the address of which the Mbus implementation has learned from
message exchanges before. Note that the DestAddr field of
messages MUST be filled in properly nevertheless. Every Mbus
SHOULD use a single unique endpoint address for sending messages
the Mbus multicast group or to individual receiving entities.
Ott, et. al. Informational [Page 16]
RFC 3259 A Message Bus for Local Coordination April 2002
unique endpoint address is a tuple consisting of the entity's
address and a UDP source port number, where the port number
different from the standard Mbus port number
Messages MUST only be sent via unicast if the Mbus target address
unique and if the sending entity can verify that the receiving
uses a unique endpoint address. The latter can be verified
considering the last message received from that entity
Note that several Mbus entities, say within the same process,
share a common transport address; in this case, the contents
the destination address field is used to further dispatch
message. Given the definition of "unique endpoint address" above
the use of a shared endpoint address and a dispatcher still
other Mbus entities to send unicast messages to one of
entities that share the endpoint address. So this can
considered an implementation detail
Messages with an empty target address list MUST always be sent to
Mbus entities (via multicast if available).
The following algorithm can be used by sending entities to
whether an Mbus address is unique considering the current set of
entities
let ta=the target address
iterate through the set of
currently known Mbus addresses {
let ti=the address in each iteration
count the addresses for
the predicate isSubsetOf(ta,ti) yields true
}
If the count of matching addresses is exactly 1 the address
unique. The following algorithm can be used for the
isSubsetOf, that checks whether the second message matches
first according to the rules specified in Section 4. (A
means that a receiving entity that uses the second Mbus
must also process received messages with the first address as
target address.)
isSubsetOf(addr a1,a2) yields true,
every address element of a1 is
in a2's address element list
Ott, et. al. Informational [Page 17]
RFC 3259 A Message Bus for Local Coordination April 2002
An address element a1 is contained in an address element list
the list contains an element that is equal to a1. An
element is considered equal to another address element if it
the same values for both of the two address element fields (
and value).
7.
While most messages are expected to be sent using
transport, it may be necessary to deliver some messages reliably
Reliability can be selected on a per message basis by means of
MessageType field. Reliable delivery is supported for messages
a single recipient only; i.e., to a fully qualified Mbus address.
entity can thus only send reliable messages to known addresses, i.e.,
it can only send reliable messages to entities that have
their existence on the Mbus (e.g., by means of mbus.hello()
as defined in Section 9.1). A sending entity MUST NOT send a
reliably if the target address is not unique. (See Section 6 for
specification of an algorithm to determine whether an address
unique.) A receiving entity MUST only process and acknowledge
reliable message if the destination address exactly matches its
source address (the destination address MUST NOT be a subset of
source address).
Disallowing reliable message delivery for messages sent to
destinations is motivated by simplicity of the implementation as
as the protocol. The desired effect can be achieved at
application layer by sending individual reliable messages to
fully qualified destination address, if the membership
for the Mbus session is available
Each message is tagged with a message sequence number. If
MessageType is "R", the sender expects an acknowledgment from
recipient within a short period of time. If the acknowledgment
not received within this interval, the sender MUST retransmit
message (with the same message sequence number), increase
timeout, and restart the timer. Messages MUST be retransmitted
small number of times (see below) before the transmission or
recipient are considered to have failed. If the message is
delivered successfully, the sending application is notified. In
case, it is up to the application to determine the specific
(if any) to be taken
Ott, et. al. Informational [Page 18]
RFC 3259 A Message Bus for Local Coordination April 2002
Reliable messages MUST be acknowledged by adding their SeqNum to
AckList field of a message sent to the originator of the
message. This message MUST be sent to a fully qualified Mbus
address. Multiple acknowledgments MAY be sent in a single message
Implementations MAY either piggy-back the AckList onto
message sent to the same destination, or MAY send a
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
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
acknowledgment is received from B, timer T MUST be cancelled
the copy of M is discarded. If T expires, the message M MUST
retransmitted, the counter N MUST be incremented by one, and
timer MUST be restarted (set to N*T_r). If N exceeds
retransmission threshold N_r, the transmission is assumed to
failed, further retransmission attempts MUST NOT be undertaken
the copy of M MUST be discarded, and the sending
SHOULD be notified
Receiver: A receiver B of a reliable message from a sender A
acknowledge reception of the message within a time period T_c <
T_r. This MAY be done by means of a dedicated
message or by piggy-backing the acknowledgment on another
addressed only to A
Receiver optimization: In a simple implementation, B may choose
immediately send a dedicated acknowledgment message. However,
efficiency, it could add the SeqNum of the received message to
sender-specific list of acknowledgments; if the added SeqNum
the first acknowledgment in the list, B SHOULD start
acknowledgment timer TA (initialized to T_c). When the
expires, B SHOULD create a dedicated acknowledgment message
send it to A. If B is to transmit another Mbus message
only to A, it should piggy-back the acknowledgments onto
message and cancel TA. In either case, B should store a copy
the acknowledgment list as a single entry in the per-sender
list, keep this entry for a period T_k, and empty
acknowledgment list. In case any of the messages kept in an
of the copy list is received again from A, the
acknowledgment list stored in this entry is scheduled for (re-)
transmission following the above rules
Ott, et. al. Informational [Page 19]
RFC 3259 A Message Bus for Local Coordination April 2002
Constants and Algorithms: The following constants and
SHOULD be used by implementations
T_r=100
N_r=3
T_c=70
T_k=((N_r)*(N_r+1)/2)*T_
8. Awareness of other
Before Mbus entities can communicate with one another, they need
mutually find out about their existence. After this
procedure that each Mbus entity goes through all other
listening to the same Mbus know about the newcomer and the
has learned about all the other entities. Furthermore, entities
to be able to to notice the failure (or leaving) of other entities
Any Mbus entity MUST announce its presence (on the Mbus)
starting up. This is to be done repeatedly throughout its
to address the issues of startup sequence: Entities should
become aware of other entities independent of the order of starting
Each Mbus entity MUST maintain the number of Mbus session members
continuously update this number according to any observed changes
The mechanisms of how the existence and the leaving of other
can be detected are dedicated Mbus messages for entity awareness
mbus.hello (Section 9.1) and mbus.bye (Section 9.2). Each
protocol implementation MUST periodically send mbus.hello
that are used by other entities to monitor the existence of
entity. If an entity has not received mbus.hello messages for
certain time (see Section 8.2) from an entity, the respective
is considered to have left the Mbus and MUST be excluded from the
of currently known entities. Upon the reception of a mbus.
message the respective entity is considered to have left the Mbus
well and MUST be excluded from the set of currently known
immediately
Each Mbus entity MUST send hello messages to the Mbus after startup
After transmission of the hello message, it MUST start a timer
the expiration of which the next hello message is to be transmitted
Transmission of hello messages MUST NOT be stopped unless the
detaches from the Mbus. The interval for sending hello messages
dependent on the current number of entities in an Mbus group and
thus change dynamically in order to avoid congestion due to
entities sending hello messages at a constant high rate
Ott, et. al. Informational [Page 20]
RFC 3259 A Message Bus for Local Coordination April 2002
Section 8.1 specifies the calculation of hello message intervals
MUST be used by protocol implementations. Using the values that
calculated for obtaining the current hello message timer, the
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
Since the number of entities in an Mbus session may vary, care
be taken to allow the Mbus protocol to automatically scale over
wide range of group sizes. The average rate at which hello
are received would increase linearly to the number of entities in
session if the sending interval was set to a fixed value. Given
interval of 1 second this would mean that an entity taking part in
Mbus session with n entities would receive n hello messages
second. Assuming all entities resided on one host, this would
to n*n messages that have to be processed per second -- which
obviously not a viable solution for larger groups. It is
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
calculate the interval for hello messages considering the
number of Mbus entities
The algorithm features the following characteristics
o The number of hello messages that are received by a single
in a certain time unit remains approximately constant as
number of entities changes
o The effective interval that is used by a specific Mbus entity
randomized in order to avoid unintentional synchronization
hello messages within an Mbus session. The first hello message
an entity is also delayed by a certain random amount of time
o A timer reconsideration mechanism is deployed in order to
the interval more appropriately in situations where a rapid
of the number of entities is observed. This is useful when
entity joins an Mbus session and is still learning of
existence of other entities or when a larger number of
leaves the Mbus at once
Ott, et. al. Informational [Page 21]
RFC 3259 A Message Bus for Local Coordination April 2002
8.1.1 Calculating the Interval for Hello
The following variable names are used in the calculation
below (all time values in milliseconds):
hello_p: The last time a hello message has been sent by a
entity
hello_now: The current
hello_d: The deterministic calculated interval between
messages
hello_e: The effective (randomized) interval between hello messages
hello_n: The time for the next scheduled transmission of a
message
entities_p: The numbers of entities at the time hello_n has been
recomputed
entities: The number of currently known entities
The interval between hello messages MUST be calculated as follows
The number of currently known entities is multiplied
c_hello_factor, yielding the interval between hello messages
milliseconds. This is the deterministic calculated interval,
hello_d. The minimum value for hello_d is c_hello_min which
hello_d = max(c_hello_min,c_hello_factor * entities * 1ms).
Section 8 provides a specification of how to obtain the number
currently known entities. Section 10 provides values for
constants c_hello_factor and c_hello_min
The effective interval hello_e that is to be used by
entities is calculated by multiplying hello_d with a randomly
number between c_hello_dither_min and c_hello_dither_max as follows
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
between 0 and 1. See also Section 10.
hello_n, the time for the next hello message in milliseconds is
to hello_e + hello_now
Ott, et. al. Informational [Page 22]
RFC 3259 A Message Bus for Local Coordination April 2002
8.1.2 Initialization of
Upon joining an Mbus session a protocol implementation
hello_p=0, hello_now=0 and entities=1, entities_p=1 (the Mbus
itself) and then calculates the time for the next hello message
specified in Section 8.1.1. The next hello message is scheduled
transmission at hello_n
8.1.3 Adjusting the Hello Message Interval when the Number of
When the existence of a new entity is observed by a
implementation the number of currently known entities is updated.
further action concerning the calculation of the hello
interval is required. The reconsideration of the timer
takes place when the current timer for the next hello message
(see Section 8.1.5).
8.1.4 Adjusting the Hello Message Interval when the Number of
Upon realizing that an entity has left the Mbus the number
currently known entities is updated and the following
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
cancelled and a new timer is started for hello_n
4. entities_p is set to entities
8.1.5 Expiration of hello
When the hello message timer expires, the protocol
MUST perform the following operations
The hello interval hello_e is computed as specified in
8.1.1.
1. IF hello_e + hello_p <= hello_now THEN a hello message
transmitted. hello_p is set to hello_now, hello_e
calculated again as specified in Section 8.1.1 and hello_n
set to hello_e + hello_now
Ott, et. al. Informational [Page 23]
RFC 3259 A Message Bus for Local Coordination April 2002
2. ELSE IF hello_e + hello_p > hello_now THEN hello_n is set
hello_e + hello_p. A new timer for the next hello message
started to expire at hello_n. No hello message is transmitted
entities_p is set to entities
8.2 Calculating the Timeout for Mbus
Whenever an Mbus entity has not heard for a time span
c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from
Mbus entity it may consider this entity to have failed (or have
silently). The number of the currently known entities MUST
updated accordingly. See Section 8.1.4 for details. Note that
need for any further action is necessarily implied from
observation
Section 8.1.1 specifies how to obtain hello_d. Section 10
values for the constants c_hello_dead and c_hello_dither_max
9.
This section defines some basic application-independent messages
MUST be understood by all implementations; these messages
required for proper operation of the Mbus. This specification
not contain application-specific messages. These are to be
outside of the basic Mbus protocol specification in separate
profiles
9.1 mbus.
Syntax
mbus.hello()
Parameters: - none -
mbus.hello messages MUST be sent unreliably to all Mbus entities
Each Mbus entity learns about other Mbus entities by observing
mbus.hello messages and tracking the sender address of each
and can thus calculate the current number of entities
mbus.hello messages MUST be sent periodically in
calculated intervals as specified in Section 8.
Upon startup the first mbus.hello message MUST be sent after a
hello_delay, where hello_delay be a randomly chosen number between 0
and c_hello_min (see Section 10).
Ott, et. al. Informational [Page 24]
RFC 3259 A Message Bus for Local Coordination April 2002
9.2 mbus.
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.
mbus.bye message MUST be sent unreliably to all entities
9.3 mbus.
Syntax: mbus.ping()
Parameters: - none -
mbus.ping can be used to solicit other entities to signal
existence by replying with an mbus.hello message. Each
implementation MUST understand mbus.ping and reply with an mbus.
message. The reply hello message MUST be delayed for hello_
milliseconds, where hello_delay be a randomly chosen number between 0
and c_hello_min (see Section 10). Several mbus.ping messages MAY
answered by a single mbus.hello: if one or more further mbus.
messages are received while the entity is waiting hello_delay
units before transmitting the mbus.hello message, no extra mbus.
message need be scheduled for those additional mbus.ping messages
As specified in Section 9.1 hello messages MUST be sent unreliably
all Mbus entities. This is also the case for replies to
messages. An entity that replies to mbus.ping with mbus.hello
stop any outstanding timers for hello messages after sending
hello message and schedule a new timer event for the subsequent
message. (Note that using the variables and the algorithms
Section 8.1.1 this can be achieved by setting hello_p to hello_now.)
mbus.ping allows a new entity to quickly check for other
without having to wait for the regular individual hello messages.
specifying a target address the new entity can restrict
solicitation for hello messages to a subset of entities it
interested in
Ott, et. al. Informational [Page 25]
RFC 3259 A Message Bus for Local Coordination April 2002
9.4 mbus.
Syntax
mbus.quit()
Parameters: - none -
The mbus.quit message is used to request other entities to
themselves (and detach from the Mbus). Whether this request
honoured by receiving entities or not is application specific
not defined in this document
The mbus.quit message can be multicast or sent reliably via
to a single Mbus entity or a group of entities
9.5 mbus.
Syntax
mbus.waiting(condition
Parameters
symbol
The condition parameter is used to indicate that the
transmitting this message is waiting for a particular event
occur
An Mbus entity SHOULD be able to indicate that it is waiting for
certain event to happen (similar to a P() operation on a
but without creating external state somewhere else). In
with this, an Mbus entity SHOULD be capable of indicating to
entity that this condition is now satisfied (similar to a semaphore'
V() operation).
The mbus.waiting message MAY be broadcast to all Mbus entities,
be multicast to an arbitrary subgroup, or MAY be unicast to
particular peer. Transmission of the mbus.waiting message MUST
unreliable and hence MUST be repeated at an application-
interval (until the condition is satisfied).
If an application wants to indicate that it is waiting for
conditions to be met, several mbus.waiting messages are
(possibly included in the same Mbus payload). Note that mbus.
and mbus.waiting messages may also be transmitted in a single
payload
Ott, et. al. Informational [Page 26]
RFC 3259 A Message Bus for Local Coordination April 2002
9.6 mbus.
Syntax
mbus.go(condition
Parameters
symbol
This parameter specifies which condition is met
The mbus.go message is sent by an Mbus entity to "unblock"
Mbus entity -- which has indicated that it is waiting for a
condition to be met. Only a single condition can be specified
mbus.go message. If several conditions are satisfied
multiple mbus.go messages MAY be combined in a single Mbus payload
The mbus.go message MUST be sent reliably via unicast to the
entity to unblock
10.
The following values for timers and counters mentioned in
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=100
N_r=3
T_c=70
T_k=((N_r)*(N_r+1)/2)*T_
Ott, et. al. Informational [Page 27]
RFC 3259 A Message Bus for Local Coordination April 2002
11. Mbus
11.1 Security
In order to prevent accidental or malicious disturbance of
communications through messages originated by applications from
users, message authentication is deployed (Section 11.3). For
message, a digest MUST be calculated based on the value of a
secret key value. Receivers of messages MUST check if the
belongs to the same Mbus security domain by re-calculating the
and comparing it to the received value. The messages MUST only
processed further if both values are equal. In order to
different simultaneous Mbus sessions at a given scope and
compensate defective implementations of host local multicast,
authentication MUST be provided by conforming implementations
Privacy of Mbus message transport can be achieved by optionally
symmetric encryption methods (Section 11.2). Each message MAY
encrypted using an additional shared secret key and a
encryption algorithm. Encryption is OPTIONAL for applications, i.e.,
it is allowed to configure an Mbus domain not to use encryption.
conforming implementations MUST provide the possibility to
message encryption (see below).
Message authentication and encryption can be parameterized:
algorithms to apply, the keys to use, etc. These and
parameters are defined in an Mbus configuration object that
accessible by all Mbus entities that participate in an Mbus session
In order to achieve interoperability conforming
SHOULD use the values provided by such an Mbus configuration
Section 12 defines the mandatory and optional parameters as well
storage procedures for different platforms. Only in cases where
of the options mentioned in Section 12 is applicable
methods of configuring Mbus protocol entities MAY be deployed
The algorithms and procedures for applying encryption
authentication techniques are specified in the following sections
11.2
Encryption of messages is OPTIONAL, that means, an Mbus MAY
configured not to use encryption
Ott, et. al. Informational [Page 28]
RFC 3259 A Message Bus for Local Coordination April 2002
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].
For algorithms requiring en/decryption data to be padded to
boundaries octets with a value of 0 SHOULD be used for
characters
The length of the encryption keys is determined by the currently
encryption algorithm. This means, the configured encryption key
NOT be shorter than the native key length for the
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
RFC 1423 [12], resulting in 12 Base64-encoded characters. IDEA
128-bit keys (24 Base64-encoded characters). AES can use
128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES
128-bit keys (24 Base64-encoded characters) MUST be used
11.3 Message
For authentication of messages, hashed message authentication
(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
following way
The keyed hash value is calculated using the HMAC
specified in RFC 2104 [5]. The specific hash algorithm and
secret hash key MUST be obtained from the Mbus configuration (
Section 12).
The keyed hash values (see RFC 2104 [5]) MUST be truncated to 96
bits (12 octets).
Subsequently, 