draft-ietf-mmusic-mbus-transport-04.txt   draft-ietf-mmusic-mbus-transport-05.txt 
Network Working Group Ott Network Working Group Ott
Internet-Draft TZI, Universitaet Bremen Internet-Draft TZI, Universitaet Bremen
Expires: August 8, 2001 Perkins Expires: November 7, 2001 Perkins
USC Information Sciences Institute USC Information Sciences Institute
Kutscher Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
February 7, 2001 May 9, 2001
A Message Bus for Local Coordination A Message Bus for Local Coordination
draft-ietf-mmusic-mbus-transport-04.txt draft-ietf-mmusic-mbus-transport-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of Internet-Draft Shadow Directories, see The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/1id-abstracts.html
This Internet-Draft will expire on August 8, 2001. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 7, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved. Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract Abstract
The local Message Bus (Mbus) is a simple message-oriented The local Message Bus (Mbus) is a simple message-oriented
coordination infrastructure for group communication within groups of coordination infrastructure for group communication within groups of
co-located application entities. The Message Bus comprises three co-located communication peers. The Mbus provides automatic location
logically distinct parts: a message transport infrastructure, a of communication peers, subject based addressing, reliable message
structured message hierarchy, and a general purpose addressing transfer and group communication. The protocol uses an IP multicast
scheme. This document specifies message addressing, transport, and group as a common communication channel between peers. The scope of
security procedures and defines the message syntax for the Mbus. It this group is strictly limited to link-local communication. This
does not define application oriented semantics and procedures for document specifies the Mbus protocol, i.e., message syntax,
using the message bus. addressing and transport mechanisms.
This document is a product of the Multiparty Multimedia Session This document is a product of the Multiparty Multimedia Session
Control (MMUSIC) working group of the Internet Engineering Task Control (MMUSIC) working group of the Internet Engineering Task
Force. Comments are solicited and should be addressed to the working Force. Comments are solicited and should be addressed to the working
group's mailing list at confctrl@isi.edu and/or the authors. group's mailing list at confctrl@isi.edu and/or the authors.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Application Scenarios . . . . . . . . . . . . . . . . . . . 4 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Mbus Overview . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Terminology for requirement specifications . . . . . . . . . 4 1.3 Purpose of this Document . . . . . . . . . . . . . . . . . . 5
2. General Outline . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Areas of Application . . . . . . . . . . . . . . . . . . . . 6
3. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 8 1.5 Terminology for requirement specifications . . . . . . . . . 7
4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 10 2. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 8
5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 11 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 10
5.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 12 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 12
6.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 13 5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 14
6.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 13 5.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 14
6.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 14
7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 14
7.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 16 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 17 6.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 17
7.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 17 6.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 18
7.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 18 6.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 18
7.1.4 Mbus Port Number . . . . . . . . . . . . . . . . . . . . . . 18 6.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 19
7.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 18 6.1.4 Mbus UDP Port Number . . . . . . . . . . . . . . . . . . . . 19
8. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 21 6.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 19
9. Awareness of other Entities . . . . . . . . . . . . . . . . 23 7. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1 Hello Message Transmission Interval . . . . . . . . . . . . 23 8. Awareness of other Entities . . . . . . . . . . . . . . . . 24
9.1.1 Calculating the Interval for Hello Messages . . . . . . . . 24 8.1 Hello Message Transmission Interval . . . . . . . . . . . . 24
9.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 25 8.1.1 Calculating the Interval for Hello Messages . . . . . . . . 25
9.1.3 Adjusting the Hello Message Interval when the Number of 8.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 26
Entities increases . . . . . . . . . . . . . . . . . . . . . 25 8.1.3 Adjusting the Hello Message Interval when the Number of
9.1.4 Adjusting the Hello Message Interval when the Number of Entities increases . . . . . . . . . . . . . . . . . . . . . 26
Entities decreases . . . . . . . . . . . . . . . . . . . . . 25 8.1.4 Adjusting the Hello Message Interval when the Number of
9.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 26 Entities decreases . . . . . . . . . . . . . . . . . . . . . 26
9.2 Calculating the Timeout for Hello Messages . . . . . . . . . 26 8.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 27
10. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.2 Calculating the Timeout for Mbus Entities . . . . . . . . . 27
10.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 28
10.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 28 9.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 29
11. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 31 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 31
12.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 31 11. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 32
12.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 31 11.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 32
12.3 Message Authentication . . . . . . . . . . . . . . . . . . . 32 11.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.4 Procedures for Senders and Receivers . . . . . . . . . . . . 32 11.3 Message Authentication . . . . . . . . . . . . . . . . . . . 33
13. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 34 11.4 Procedures for Senders and Receivers . . . . . . . . . . . . 33
13.1 File based parameter storage . . . . . . . . . . . . . . . . 36 12. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 35
13.2 Registry based parameter storage . . . . . . . . . . . . . . 37 12.1 File based parameter storage . . . . . . . . . . . . . . . . 37
14. Security Considerations . . . . . . . . . . . . . . . . . . 38 12.2 Registry based parameter storage . . . . . . . . . . . . . . 38
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39 13. Security Considerations . . . . . . . . . . . . . . . . . . 39
References . . . . . . . . . . . . . . . . . . . . . . . . . 40 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 References . . . . . . . . . . . . . . . . . . . . . . . . . 41
A. About References . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42
B. Limitations and Future Work . . . . . . . . . . . . . . . . 44 A. About References . . . . . . . . . . . . . . . . . . . . . . 44
Full Copyright Statement . . . . . . . . . . . . . . . . . . 45 B. Limitations and Future Work . . . . . . . . . . . . . . . . 45
Full Copyright Statement . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
1.1 Application Scenarios 1.1 Motivation
The implementation of multiparty multimedia conferencing systems is The implementation of multiparty multimedia conferencing systems is
one example where a simple coordination infrastructure can be one example where a simple coordination infrastructure can be
useful: In a variety of conferencing scenarios, a local useful: In a variety of conferencing scenarios, a local
communication channel can provide conference-related information communication channel can provide conference-related information
exchange between co-located but otherwise independent application exchange between co-located but otherwise independent application
entities, for example those taking part in application sessions that entities, for example those taking part in application sessions that
belong to the same conference. In loosely coupled conferences such a belong to the same conference. In loosely coupled conferences such a
mechanism allows for coordination of applications entities to e.g. mechanism allows for coordination of applications entities to e.g.
implement synchronization between media streams or to configure implement synchronization between media streams or to configure
entities without user interaction. It can also be used to implement entities without user interaction. It can also be used to implement
tightly coupled conferences enabling a conference controller to tightly coupled conferences enabling a conference controller to
enforce conference wide control within an end system. enforce conference wide control within an end system.
1.2 Purpose Conferencing systems, e.g., IP-telephones can be remote-controlled
or integrated into a group of application modules that reside on
Three components constitute the message bus: the low level message different host: For example, an IP-telephony call that is conducted
passing mechanisms, a command syntax and naming hierarchy, and the with a stand-alone IP-telephone can be extended to include media
addressing scheme. engine for other media types dynamically using the coordination
function of an appropriate coordination mechanism.
The purpose of this document is to define the characteristics of the
lower level Mbus message passing mechanism which is common to all
Mbus implementations. This includes the specification of
o the generic Mbus message format;
o the addressing concept for application entities (note that
concrete addressing schemes are to be defined by application
specific profiles);
o the transport mechanisms to be employed for conveying messages
between (co-located) application entities;
o the security concept to prevent misuse of the Message Bus (as
taking control of another user's conferencing environment);
o the details of the Mbus message syntax; and
o a set of mandatory application independent commands that are used
for bootstrapping Mbus sessions.
1.3 Terminology for requirement specifications
In this document, the key words "MUST", "MUST NOT", "REQUIRED", Other possible scenarios include the coordination of application
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", components that are distributed on different hosts in a network, for
and "OPTIONAL" are to be interpreted as described in RFC 2119[1] and example so-called Internet appliances.
indicate requirement levels for compliant Mbus implementations.
2. General Outline 1.2 Mbus Overview
Local coordination involves a widely varying number of entities: Local coordination involves a widely varying number of entities:
some messages (such as membership information, floor control some messages (such as membership information, floor control
notifications, dissemination of conference state changes, etc.) may notifications, dissemination of conference state changes, etc.) may
need to be destined for all local application entities. Messages may need to be sent to all local application entities. Messages may also
also be targeted at a certain application class (e.g. all be targeted at a certain application class (e.g. all whiteboards or
whiteboards or all audio tools) or agent type (e.g. all user all audio tools) or agent type (e.g. all user interfaces rather than
interfaces rather than all media engines). Or there may be any all media engines). Or there may be any (application- or message-
(application- or message- specific) subgrouping defining the specific) subgrouping defining the intended recipients, e.g.
intended recipients, e.g. messages related to media synchronization. messages related to media synchronization. Finally, there will be
Finally, there will be messages that are directed to a single messages that are directed at a single entity, for example, specific
entity, for example, specific configuration settings that a configuration settings that a conference controller sends to an
conference controller sends to a application entity or application entity or query-response exchanges between any local
query-response exchanges between any local server and its clients. server and its clients.
The Mbus concept as presented here satisfies these different The Mbus protocol as defined here satisfies these different
communication models by defining different message transport communication needs by defining different message transport
mechanisms (defined in Section 7) and by providing a flexible mechanisms (defined in Section 6) and by providing a flexible
addressing scheme (defined in Section 5). addressing scheme (defined in Section 4).
Furthermore, Mbus messages exchanged between application entities Furthermore, Mbus messages exchanged between application entities
may have different reliability requirements (which are typically may have different reliability requirements (which are typically
derived from their semantics). Some messages will have a rather derived from their semantics). Some messages will have a rather
informational character conveying ephemeral state information (which informational character conveying ephemeral state information (which
is refreshed/updated periodically), such as the volume meter level is refreshed/updated periodically), such as the volume meter level
of an audio receiver entity to be displayed by its user interface of an audio receiver entity to be displayed by its user interface
agent. Certain Mbus messages (such as queries for parameters or agent. Certain Mbus messages (such as queries for parameters or
queries to local servers) may require a response from the peer(s) queries to local servers) may require a response from the peer(s)
thereby providing an explicit acknowledgment at the semantic level thereby providing an explicit acknowledgment at the semantic level
on top of the Mbus. Other messages will modify the application or on top of the Mbus. Other messages will modify the application or
conference state and hence it is crucial that they do not get lost. conference state and hence it is crucial that they do not get lost.
The latter type of message has to be delivered reliably to the The latter type of message has to be delivered reliably to the
recipient, whereas message of the first type do not require recipient, whereas messages of the first type do not require
reliability mechanisms at the Mbus transport layer. For messages reliability mechanisms at the Mbus transport layer. For messages
confirmed at the application layer it is up to the discretion of the confirmed at the application layer it is up to the discretion of the
application whether or not to use a reliable transport underneath. application whether or not to use a reliable transport underneath.
In some cases, application entities will want to tailor the degree In some cases, application entities will want to tailor the degree
of reliability to their needs, others will want to rely on the of reliability to their needs, others will want to rely on the
underlying transport to ensure delivery of the messages -- and this underlying transport to ensure delivery of the messages -- and this
may be different for each Mbus message. The Mbus message passing may be different for each Mbus message. The Mbus message passing
mechanism specified in this document provides a maximum of mechanism specified in this document provides a maximum of
flexibility by providing reliable transmission achieved through flexibility by providing reliable transmission achieved through
transport-layer acknowledgments (in case of point-to-point transport-layer acknowledgments (in case of point-to-point
communications only) as well as unreliable message passing (for communications only) as well as unreliable message passing (for
unicast, local multicast, and local broadcast). We address this unicast, local multicast, and local broadcast). We address this
topic in Section 5. topic in Section 4.
Finally, accidental or malicious disturbance of Mbus communications Finally, accidental or malicious disturbance of Mbus communications
through messages originated by applications from other users needs through messages originated by applications from other users needs
to be prevented. Accidental reception of Mbus messages from other to be prevented. Accidental reception of Mbus messages from other
users may occur if either two users share the same host for users may occur if either two users share the same host for using
conferencing or are using end systems spread across the same network Mbus applications or are using Mbus applications that are spread
link: in either case, the used Mbus multicast address and the port across the same network link: in either case, the used Mbus
number may be identical leading to reception of the other party's multicast address and the port number may be identical leading to
Mbus messages in addition to a user's own ones. Malicious reception of the other party's Mbus messages in addition to a user's
disturbance may happen because of applications multicasting (e.g. at own ones. Malicious disturbance may happen because of applications
a global scope) or unicasting Mbus messages. To eliminate the multicasting (e.g. at a global scope) or unicasting Mbus messages.
possibility of receiving unwanted Mbus messages, the Mbus protocol To eliminate the possibility of receiving unwanted Mbus messages,
contains message digests for authentication. Furthermore, the Mbus the Mbus protocol contains message digests for authentication.
allows for encryption to ensure privacy and thus enable using the Furthermore, the Mbus allows for encryption to ensure privacy and
Mbus for local key distribution and other functions potentially thus enable using the Mbus for local key distribution and other
sensitive to eavesdropping. This document defines the framework for functions potentially sensitive to eavesdropping. This document
configuring Mbus applications with regard to security parameters in defines the framework for configuring Mbus applications with regard
Section 13. to security parameters in Section 12.
3. Common Formal Syntax Rules 1.3 Purpose of this Document
Three components constitute the message bus: the low level message
passing mechanisms, a command syntax and naming hierarchy, and the
addressing scheme.
The purpose of this document is to define the protocol mechanisms of
the lower level Mbus message passing mechanism which is common to
all Mbus implementations. This includes the specification of
o the generic Mbus message format;
o the addressing concept for application entities (note that
concrete addressing schemes are to be defined by application
specific profiles);
o the transport mechanisms to be employed for conveying messages
between (co-located) application entities;
o the security concept to prevent misuse of the Message Bus (as
taking control of another user's conferencing environment);
o the details of the Mbus message syntax; and
o a set of mandatory application independent commands that are used
for bootstrapping Mbus sessions.
1.4 Areas of Application
The Mbus prototol can be deployed in many different application
areas, including but not limited to:
Local conference control: In the Mbone community a model has arisen
whereby a set of loosely coupled tools are used to participate in
a conference. A typical scenario is that audio, video and shared
workspace functionality is provided by three separate tools
(although some combined tools exist). This maps well onto the
underlying RTP [7] (as well as other) media streams, which are
also transmitted separately. Given such an architecture, it is
useful to be able to perform some coordination of the separate
media tools. For example, it may be desirable to communicate
playout-point information between audio and video tools, in order
to implement lip-synchronisation, to arbitrate the use of shared
resources (such as input devices), etc.
A refinement of this architecture relies on the presence of a
number of media engines which perform protocol functions as well
as capturing and playout of media. In addition, one (or more)
(separate) user interface agents exist that interact with and
control their media engine(s). Such an approach allows
flexibility in the user-interface design and implementation, but
obviously requires some means by which the various involved
agents may communicate with one another. This is particularly
desirable to enable a coherent response to a user's
conference-related actions (such as joining or leaving a
conference).
Although current practice in the Mbone community is to work with
a loosely coupled conference control model, situations arise
where this is not appropriate and a more tightly coupled
wide-area conference control protocol must be employed (e.g. for
IP telephony). In such cases, it is highly desirable to be able
to re-use the existing tools (media engines) available for
loosely coupled conferences and integrate them with a system
component implementing the tight conference control model. One
appropriate means to achieve this integration is a communication
channel that allows a dedicated conference control entity to
"remotely" control the media engines in addition to or instead of
their respective user interfaces.
Control of device groups in a network: A group of devices that are
connected to a local network, e.g., home appliances in a home
network, require a local coordination mechanism. Minimizing
manual configuration and the the possibility to deploy group
communication will be useful in this application area as well.
Decentralized instant messaging and personal presence systems:
Another example for an useful application is a serverless instant
messaging and personal presence system where people within a
certain network scope can identify peers, obtain presence
information and send instant messages (to individual or group
recipients). Secure communication (authentication and
condidentiality) are important requirements for such an
application.
1.5 Terminology for requirement specifications
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119[1] and
indicate requirement levels for compliant Mbus implementations.
2. Common Formal Syntax Rules
This section contains some definitions of common ABNF [12] syntax This section contains some definitions of common ABNF [12] syntax
elements that are later referenced by other definitions in this elements that are later referenced by other definitions in this
document: document:
base64 = base64_terminal / base64 = base64_terminal /
( 1*(4base64_CHAR) [base64_terminal] ) ( 1*(4base64_CHAR) [base64_terminal] )
base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
;; Case-sensitive ;; Case-sensitive
base64_terminal = (2base64_char "==") / (3base64_char "=") base64_terminal = (2base64_char "==") / (3base64_char "=")
UPALPHA = %x41-5A ;; Uppercase: A-Z UPALPHA = %x41-5A ;; Uppercase: A-Z
LOALPHA = %x61-7A ;; Lowercase: a-z LOALPHA = %x61-7A ;; Lowercase: a-z
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
CHAR = %x01-7F CHAR = %x01-7E
; any 7-bit US-ASCII character, ; any 7-bit US-ASCII character,
excluding NUL excluding NUL and delete
OCTET = %x00-FF OCTET = %x00-FF
; 8 bits of data ; 8 bits of data
CR = %x0D CR = %x0D
; carriage return ; carriage return
CRLF = CR LF CRLF = CR LF
; Internet standard newline ; Internet standard newline
skipping to change at page 10, line 5 skipping to change at page 10, line 5
; linear white space (past newline) ; linear white space (past newline)
SP = %x20 SP = %x20
; space ; space
WSP = SP / HTAB WSP = SP / HTAB
; white space ; white space
Taken from RFC 2234 [12] and RFC 2554 [13]. Taken from RFC 2234 [12] and RFC 2554 [13].
4. Message Format 3. Message Format
A Mbus message comprises a header and a body. The header is used to A Mbus message comprises a header and a body. The header is used to
indicate how and where a message should be delivered, the body indicate how and where a message should be delivered, the body
provides information and commands to the destination entity. The provides information and commands to the destination entity. The
following information is included in the header: following information is included in the header:
A fixed ProtocolID field identifies the version of the message A fixed ProtocolID field identifies the version of the message
bus protocol used. The protocol defined in this document is bus protocol used. The protocol defined in this document is
"mbus/1.0" (case-sensitive). "mbus/1.0" (case-sensitive).
skipping to change at page 10, line 36 skipping to change at page 10, line 36
construction in milliseconds since 00:00:00, UTC, January 1, construction in milliseconds since 00:00:00, UTC, January 1,
1970. 1970.
A MessageType field indicates the kind of message being sent. The A MessageType field indicates the kind of message being sent. The
value "R" indicates that the message is to be transmitted value "R" indicates that the message is to be transmitted
reliably and MUST be acknowledged by the recipient, "U" indicates reliably and MUST be acknowledged by the recipient, "U" indicates
an unreliable message which MUST NOT be acknowledged. an unreliable message which MUST NOT be acknowledged.
The SrcAddr field identifies the sender of a message. This MUST The SrcAddr field identifies the sender of a message. This MUST
be a complete address, with all address elements specified. The be a complete address, with all address elements specified. The
addressing scheme is described in Section 5. addressing scheme is described in Section 4.
The DestAddr field identifies the intended recipient(s) of the The DestAddr field identifies the intended recipient(s) of the
message. This field MAY contain wildcards by omitting address message. This field MAY contain wildcards by omitting address
element and hence address any number (including zero) of elements and hence address any number (including zero) of
application entities. The addressing scheme is described in application entities. The addressing scheme is described in
Section 5. Section 4.
The AckList field comprises a list of SeqNums for which this The AckList field comprises a list of SeqNums for which this
message is an acknowledgment. See Section 8 for details. message is an acknowledgment. See Section 7 for details.
The header is followed by the message body which contains zero or The header is followed by the message body which contains zero or
more commands to be delivered to the destination entity. The syntax more commands to be delivered to the destination entity. The syntax
for a complete message is given in Section 6. for a complete message is given in Section 5.
If multiple commands are contained within the same Mbus message If multiple commands are contained within the same Mbus message
payload, they MUST to be delivered to the Mbus application in the payload, they MUST to be delivered to the Mbus application in the
same sequence in which they appear in the message payload. same sequence in which they appear in the message payload.
5. Addressing 4. Addressing
Each entity on the message has a unique Mbus address that is used to Each entity on the message has a unique Mbus address that is used to
identify the entity. Senders and receivers of messages are identify the entity. Senders and receivers of messages are
identified by their Mbus addresses. Mbus addresses are sequences of identified by their Mbus addresses. Mbus addresses are sequences of
address elements that are tag/value pairs. The tag and the value are address elements that are tag/value pairs. The tag and the value are
separated by a colon and tag/value pairs are separated by separated by a colon and tag/value pairs are separated by
whitespace, like this: whitespace, like this:
(tag:value tag:value ...) (tag:value tag:value ...)
The formal ABNF syntax definition for Mbus addresses and their The formal ABNF syntax definition for Mbus addresses and their
elements is as follows: elements is as follows:
mbus_address = "(" *address_element ")" mbus_address = "(" *address_element ")"
address_element = *WSP address_tag ":" address_value *WSP address_element = *WSP address_tag ":" address_value *WSP
address_tag = 1*32(ALPHA) address_tag = 1*32(ALPHA)
address_value = 1*64(%x21-7F) address_value = 1*64(%x21-7E)
; any 7-bit US-ASCII character ; any 7-bit US-ASCII character
; excluding white space ; excluding white space, delete
; and control characters ; and control characters
Note that this and other ABNF definitions in this document use the Note that this and other ABNF definitions in this document use the
core rules defined in Section 3. core rules defined in Section 2.
An address_tag MUST be unique for an Mbus address, i.e., it MUST
only occur once.
Each entity has a fixed sequence of address elements constituting Each entity has a fixed sequence of address elements constituting
its address and MUST only process messages sent to addresses that its address and MUST only process messages sent to addresses that
either match all elements or consist of a subset of its own address either match all elements or consist of a subset of its own address
elements. Each element value in this subset must match the elements. Each element in the target address must match the
correspoding value of the receiver's address element value. The corresponding element of the receiver's source address. The order of
order of address elements in an address sequence is not relevant. address elements in an address sequence is not relevant. Two address
For example, an entity with an address of: elements match if both, their keys and their values, are equivalent.
Equivalence for address element and address value strings means that
each octet in the one string has the same value as the corresponding
octet in the second string. For example, an entity with an address
of:
(conf:test media:audio module:engine app:rat id:4711-1@134.102.218.45) (conf:test media:audio module:engine app:rat id:4711-1@192.168.1.1)
will process messages sent to will process messages sent to
(media:audio module:engine) (media:audio module:engine)
and and
(module:engine) (module:engine)
but must ignore messages sent to but must ignore messages sent to
(conf:test media:audio module:engine app:rat id:123-4@134.102.218.45 foo:bar) (conf:test media:audio module:engine app:rat id:123-4@192.168.1.1 foo:bar)
and and
(foo:bar) (foo:bar)
A message that should be processed by all entities requires an empty A message that should be processed by all entities requires an empty
set of address elements. set of address elements.
5.1 Mandatory Address Elements 4.1 Mandatory Address Elements
Each Mbus entity MUST provide one mandatory address element that Each Mbus entity MUST provide one mandatory address element that
allows to identify the entity. The element name is "id" and the allows to identify the entity. The element name is "id" and the
value MUST be be composed of the following components: value MUST be be composed of the following components:
o The IP address of the interface that is used for sending messages o The IP address of the interface that is used for sending messages
to the Mbus. For IPv4 this the address in decimal dotted to the Mbus. For IPv4 this the address in decimal dotted
notation. For IPv6 the interface-ID-part of an address in textual notation. For IPv6 the interface-ID-part of an address in textual
representation as specified in RFC 2373[3] MUST be used. In this representation as specified in RFC 2373[3] MUST be used. In this
specification, this part is called the "host-ID". specification, this part is called the "host-ID".
o An identifier ("entity-ID") that is unique within the scope of a o An identifier ("entity-ID") that is unique within the scope of a
single host-ID. The entity comprises two parts. For systems where single host-ID. The entity comprises two parts. For systems where
the concept of a process ID is applicable it is RECOMMENDED this the concept of a process ID is applicable it is RECOMMENDED this
identifier be composed using a process-ID and a per-process identifier be composed using a process-ID and a per-process
disambiguator for different Mbus entities of a process. If a disambiguator for different Mbus entities of a process. If a
process ID is not available, this part of the entity-ID may be process ID is not available, this part of the entity-ID may be
randomly chosen (it is recommended that at least a 32 bit random randomly chosen (it is recommended that at least a 32 bit random
number is chosen). Both numbers are represented in decimal number is chosen). Both numbers are represented in decimal
textual form and MUST be separated by a '-' character. textual form and MUST be separated by a '-' (ASCII x2d)
character.
Note that the entity-ID cannot be the port number of the endpoint Note that the entity-ID cannot be the port number of the endpoint
used for sending messages to the Mbus because implementations MAY used for sending messages to the Mbus because implementations MAY
use the common Mbus port number for sending to and receiving from use the common Mbus port number for sending to and receiving from
the multicast group (as specified in Section 7). The total the multicast group (as specified in Section 6). The complete syntax
identifier has the following structure: definition for the entity identifier is as follows:
id-element = "id:" id-value id-element = "id:" id-value
id-value = entity-id "@" host-id id-value = entity-id "@" host-id
entity-id = 1*10DIGIT "-" 1*5DIGIT entity-id = 1*10DIGIT "-" 1*5DIGIT
host-id = (IPv4address / IPv6address) host-id = (IPv4address / IPv6address)
Please refer to [3] for productions of IPv4address and IPv6address. Please refer to [3] for productions of IPv4address and IPv6address.
An example for an id element: An example for an id element:
id:4711-99@134.102.218.45 id:4711-99@192.168.1.1
6. Message Syntax 5. Message Syntax
6.1 Message Encoding 5.1 Message Encoding
All messages MUST use the UTF-8 character encoding. Note that US All messages MUST use the UTF-8 character encoding. Note that US
ASCII is a subset of UTF-8 and requires no additional encoding, and ASCII is a subset of UTF-8 and requires no additional encoding, and
that a message encoded with UTF-8 will not contain zero bytes. that a message encoded with UTF-8 will not contain zero bytes.
Each Message MAY be encrypted using a secret key algorithm as Each Message MAY be encrypted using a secret key algorithm as
defined in Section 12. defined in Section 11.
6.2 Message Header 5.2 Message Header
The fields in the header are separated by white space characters, The fields in the header are separated by white space characters,
and followed by CRLF. The format of the header is as follows: and followed by CRLF. The format of the header is as follows:
msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP
MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList
The header fields are explained in Message Format (Section 4). Here The header fields are explained in Message Format (Section 3). Here
are the ABNF syntax definitions for the header fields: are the ABNF syntax definitions for the header fields:
SeqNum = 1*10DIGIT SeqNum = 1*10DIGIT
TimeStamp = 1*10DIGIT TimeStamp = 1*13DIGIT
MessageType = "R" / "U" MessageType = "R" / "U"
ScrAddr = mbus_address ScrAddr = mbus_address
DestAddr = mbus_address DestAddr = mbus_address
AckList = "(" *(1*DIGIT)) ")" AckList = "(" *(1*DIGIT)) ")"
See Section 5 for a definition of "mbus_address". See Section 4 for a definition of "mbus_address".
The syntax definition of a complete message is as follows: The syntax definition of a complete message is as follows:
mbus_message = msg_header *1(CRLF msg_payload) mbus_message = msg_header *1(CRLF msg_payload)
msg_payload = mbus_command *(CRLF mbus_command) msg_payload = mbus_command *(CRLF mbus_command)
The definition of production rules for Mbus command is given below. The definition of production rules for an Mbus command is given in
Section 5.3.
6.3 Command Syntax 5.3 Command Syntax
The header is followed by zero, or more, commands to be delivered to The header is followed by zero, or more, commands to be delivered to
the application(s) indicated by the DestAddr field. Each message the application(s) indicated by the DestAddr field. Each message
comprises a command followed by a list of zero, or more, parameters, comprises a command followed by a list of zero, or more parameters,
and is followed by a newline. and is followed by a newline.
command ( parameter parameter ... ) command ( parameter parameter ... )
Syntactically, the command name MUST be a `symbol' as defined in the Syntactically, the command name MUST be a `symbol' as defined in the
following table. The parameters MAY be any data type drawn from the following table. The parameters MAY be any data type drawn from the
following table: following table:
val = Integer / Float / String / List / Symbol / Data val = Integer / Float / String / List / Symbol / Data
Integer = *1"-" 1*DIGIT Integer = *1"-" 1*DIGIT
Float = *1"-" 1*DIGIT "." 1*DIGIT Float = *1"-" 1*DIGIT "." 1*DIGIT
String = DQUOTE *CHAR DQUOTE String = DQUOTE *CHAR DQUOTE
; see below for escape characters ; see below for escape characters
List = "(" *(val *(1*WSP val)) ")" List = "(" *WSP *(val *(1*WSP val)) *WSP ")"
Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" / ".") Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" / ".")
Data = "<" *base64 ">" Data = "<" *base64 ">"
Boolean values are encoded as an integer, with the value of zero Boolean values are encoded as an integer, with the value of zero
representing false, and non-zero representing true. representing false, and non-zero representing true.
String parameters in the payload MUST be enclosed in the double String parameters in the payload MUST be enclosed in the double
quote (") character. Within strings, the escape character is the quote (") character. Within strings, the escape character is the
skipping to change at page 14, line 44 skipping to change at page 15, line 45
+----------------+-----------+ +----------------+-----------+
|Escape Sequence | Meaning | |Escape Sequence | Meaning |
+----------------+-----------+ +----------------+-----------+
| \\ | \ | | \\ | \ |
| \" | " | | \" | " |
| \n | newline | | \n | newline |
+----------------+-----------+ +----------------+-----------+
List parameters do not have to be homogeneous lists, i.e. they can List parameters do not have to be homogeneous lists, i.e. they can
contain parameters of varying types. contain parameters of different types.
Opaque data is represented as Base64-encoded (see RFC1521[6]) Opaque data is represented as Base64-encoded (see RFC1521[6])
character strings surrounded by "< " and "> " character strings surrounded by "< " and "> "
The ABNF syntax definition for Mbus commands is as follows: The ABNF syntax definition for Mbus commands is as follows:
mbus_command = command_name arglist mbus_command = command_name arglist
command_name = ALPHA *(ALPHA / DIGIT / "_" / ".") command_name = Symbol
arglist = "(" *(*WSP parameter *WSP) ")"
parameter = Integer / Float / String / List arglist = List
Symbol / Data
Command names SHOULD be constructed using hierarchical names to Command names SHOULD be constructed using hierarchical names to
group conceptually related commands under a common hierarchy. The group conceptually related commands under a common hierarchy. The
delimiter between names in the hierarchy is "." (dot). Application delimiter between names in the hierarchy is "." (dot). Application
profiles MUST NOT define commands starting with "mbus.". profiles MUST NOT define commands starting with "mbus.".
The Mbus addressing scheme defined in Section 5 provides for The Mbus addressing scheme defined in Section 4 provides for
specifying incomplete addresses by omitting certain elements of an specifying incomplete addresses by omitting certain elements of an
address element list, enabling entities to send commands to a group address element list, enabling entities to send commands to a group
of Mbus entities. Therefore all command names SHOULD be unambiguous of Mbus entities. Therefore all command names SHOULD be unambiguous
in a way that it is possible to interpret or ignore them without in a way that it is possible to interpret or ignore them without
considering the message's address. considering the message's address.
A set of commands within a certain hierarchy that MUST be understood A set of commands within a certain hierarchy that MUST be understood
by every entity is defined in Messages (Section 10). by every entity is defined in Messages (Section 9).
7. Transport 6. Transport
All messages are transmitted as UDP messages, with two possible All messages are transmitted as UDP messages, with two possible
alternatives: alternatives:
1. Local multicast/broadcast: 1. Local multicast/broadcast:
This transport class MUST be used for all messages that are not This transport class MUST be used for all messages that are not
sent to a fully qualified target address. It MAY also be used sent to a fully qualified target address. It MAY also be used
for messages that are sent to a fully qualified target address. for messages that are sent to a fully qualified target address.
It MUST be provided by conforming implementations. See Section It MUST be provided by conforming implementations. See Section
7.1 for details. 6.1 for details.
2. Directed unicast: 2. Directed unicast:
This transport class MAY be used for messages that are sent to a This transport class MAY be used for messages that are sent to a
fully qualified destination address. It is OPTIONAL and does not fully qualified destination address. It is OPTIONAL and does not
have to be provided by conforming implementations. have to be provided by conforming implementations.
Messages are transmitted in UDP datagrams, a maximum message size of Messages are transmitted in UDP datagrams, a maximum message size of
64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications 64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications
using a non host-local scope do not exceed a message size of the using a non host-local scope do not exceed a message size of the
network's MTU. network link MTU.
Note that "unicast", "multicast" and "broadcast" mean IP-Unicast, Note that "unicast", "multicast" and "broadcast" mean IP Unicast, IP
IP-Multicast and IP-Broadcast respectively. It is possible to send Multicast and IP Broadcast respectively. It is possible to send an
an Mbus message that is addressed to a single entity using Mbus message that is addressed to a single entity using IP
IP-multicast. This specification deals with both Mbus over UDP/IPv4 Multicast.
and Mbus over UDP/IPv6.
7.1 Local Multicast/Broadcast This specification deals with 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 In general, the Mbus uses multicast with a limited scope for message
transport. Two different Mbus multicast scopes are defined: transport. Two different Mbus multicast scopes are defined:
1. host-local 1. host-local
2. link-local 2. link-local
Participants of an Mbus session have to know the multicast address Participants of an Mbus session have to know the multicast address
in advance -- it cannot be negotiated during the session since it is in advance -- it cannot be negotiated during the session since it is
already needed for any communication between the participants. I can already needed for initial communication between the participants
also not be allocated prior to an Mbus session because there would during the bootstrapping phase. It also cannot be allocated prior to
be no mechanism to announce the allocated address to all potential an Mbus session because there would be no mechanism to announce the
Mbus participants. Therefore the multicast address cannot be allocated address to all potential Mbus participants. Therefore, the
allocated dynamically, e.g. using multicast address allocation multicast address cannot be allocated dynamically, e.g. using
protocols, but has to be assigned statically. This document defines multicast address allocation protocols, but has to be assigned
the use of statically assigned addresses and also provides a statically. This document defines the use of statically assigned
specification of how an Mbus session can be configured to use addresses and also provides a specification of how an Mbus session
non-standard addresses (see Section 13). can be configured to use non-standard, unassigned addresses (see
Section 12).
An Mbus session can be configured to use either one of the mentioned An Mbus session can be configured to use either one of the mentioned
scopes. The following sections specify the use of multicast scopes. The following sections specify the use of multicast
addresses for IPv4 and IPv6. addresses for IPv4 and IPv6.
7.1.1 Mbus multicast groups for IPv4 6.1.1 Mbus multicast groups for IPv4
For IPv4, there are two address ranges for "local scope" multicast: For IPv4, there are two potential address ranges for "local scope"
multicast that could be considered for the Mbus multicast address:
The IPv4 Local Scope -- 239.255.0.0/16 239.255.0.0/16 is the minimal The IPv4 Local Scope -- 239.255.0.0/16 239.255.0.0/16 is the minimal
enclosing scope for administratively scoped multicast (as defined enclosing scope for administratively scoped multicast (as defined
by RFC 2365[10]) and not further divisible -- its exact extent is by RFC 2365[10]) and not further divisible -- its exact extent is
site dependent. Allocating a statically assigned address in this site dependent. Allocating a statically assigned address in this
scope would require to allocate a scope relative multicast scope would require to allocate a scope relative multicast
address (the high order /24 in every scoped region is reserved address (the high order /24 in every scoped region is reserved
for relative assignments), because the main address space is to for relative assignments), because the main address space is to
be assigned dynamically, e.g. by using address allocation be assigned dynamically, e.g. by using address allocation
protocols. protocols.
The IPv4 statically assigned link-local scope -- 224.0.0.0/24 The IPv4 statically assigned link-local scope -- 224.0.0.0/24
224.0.0.0/24 is the address range for statically assigned 224.0.0.0/24 is the address range for statically assigned
multicast address for link-local multicast. Multicast routers multicast address for link-local multicast. Multicast routers
should not forward any multicast datagram with destination should not forward any multicast datagram with destination
addresses in this range, regardless of its TTL. addresses in this range, regardless of its TTL.
Because of the unexact extent of 239.255.0.0/16 scopes and the fact Because of the inexact extent of 239.255.0.0/16 scopes and the fact
that the only way to allocate a static address is the use of an that the only way to allocate a static address is the use of an
assigned scope relative address the Mbus uses an multicast address assigned scope relative address the Mbus uses a multicast address
from the statically assigned link-local scope (224.0.0.0/24). from the statically assigned link-local scope (224.0.0.0/24).
Host-local Mbus scope in an IPv4 environment MUST be implemented by Host-local Mbus scope in an IPv4 environment MUST be implemented by
using an IPv4 link-local address and an IP-Multicast-TTL of zero. using an IPv4 link-local address and an IP-Multicast-TTL of zero.
Link-local Mbus scope in an IPv4 environment MUST be implemented by Link-local Mbus scope in an IPv4 environment MUST be implemented by
using an IPv4 link-ocal Scope address and an IP-Multicast-TTL using an IPv4 link-local Scope address and an IP-Multicast-TTL
greater than zero. greater than zero. A TTL value of 1 SHOULD be used in order to make
sure that the link-local scope is not exceeded, e.g., in cases where
administratively scoped multicast does not work correctly.
The IPv4 link-local multicast address has yet to be assigned (see The IPv4 link-local multicast address has yet to be assigned (see
Section 15). Section 14).
7.1.2 Mbus multicast groups for IPv6 6.1.2 Mbus multicast groups for IPv6
IPv6 has different address ranges for different multicast scopes and IPv6 has different address ranges for different multicast scopes and
distinguishes node local and link local scopes, that are implemented distinguishes node local and link local scopes, that are implemented
as a set of address prefixes for the different address ranges (RFC as a set of address prefixes for the different address ranges (RFC
2373[18]). The link-local prefix is FF02, the node-local prefix is 2373[18]). The link-local prefix is FF02, the node-local prefix is
FF01. A permanently assigned multicast address will be used for Mbus FF01. A permanently assigned multicast address will be used for Mbus
multicast communication, i.e. an address that is independent of the multicast communication, i.e. an address that is independent of the
scope value and that can be used for all scopes. Implementations for scope value and that can be used for all scopes. Implementations for
IPv6 MUST use the scope independent address and the appropriate IPv6 MUST use the scope independent address and the appropriate
prefix for the selected scope. For host-local Mbus communication the prefix for the selected scope. For host-local Mbus communication the
IPv6 node-local scope prefix MUST be used, for link-local Mbus IPv6 node-local scope prefix MUST be used, for link-local Mbus
communication the IPv6 link-local scope prefix MUST be used. communication the IPv6 link-local scope prefix MUST be used.
The permanent IPv6 multicast addresses has yet to be assigned (see The permanent IPv6 multicast addresses has yet to be assigned (see
Section 15). Section 14).
If a single application system is distributed across several If a single application system is distributed across several
co-located hosts, link local scope SHOULD be used for multicasting co-located hosts, link local scope SHOULD be used for multicasting
Mbus messages that potentially have recipients on the other hosts. Mbus messages that potentially have recipients on the other hosts.
The Mbus protocol is not intended (and hence deliberately not The Mbus protocol is not intended (and hence deliberately not
designed) for communication between hosts not on the same link. See designed) for communication between hosts not on the same link. See
Section 13 for specifications of Mbus configuration mechanisms. Section 12 for specifications of Mbus configuration mechanisms.
7.1.3 Use of Broadcast 6.1.3 Use of Broadcast
In situations where multicast is not available, broadcast MAY be In situations where multicast is not available, broadcast MAY be
used instead. In these cases an IP broadcast address for the used instead. In these cases an IP broadcast address for the
connected network SHOULD be used for sending. The node-local connected network SHOULD be used for sending. The node-local
broadcast address for IPv6 is FF01:0:0:0:0:0:0:1, the link-local broadcast address for IPv6 is FF01:0:0:0:0:0:0:1, the link-local
broadcast address for IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the broadcast address for IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the
generic broadcast address (for link-local broadcast) is generic broadcast address (for link-local broadcast) is
255.255.255.255. It is RECOMMENDED that IPv4-implementations use the 255.255.255.255. It is RECOMMENDED that IPv4-implementations use the
generic broadcast address and a TTL of zero for host-local generic broadcast address and a TTL of zero for host-local
broadcast. broadcast.
Broadcast MUST NOT be used in situations where multicast is Broadcast MUST NOT be used in situations where multicast is
available and supported by all systems participating in an Mbus available and supported by all systems participating in an Mbus
session. session.
See Section 13 for specifications of how to configure the use of See Section 12 for specifications of how to configure the use of
broadcast. broadcast.
7.1.4 Mbus Port Number 6.1.4 Mbus UDP Port Number
There will also be a fixed, registered port number that all Mbus The registered Mbus UDP port number is 47000.
entities MUST use. Until the address and port number are assigned
the values given in Section 15 SHOULD be used.
7.2 Directed Unicast 6.2 Directed Unicast
Directed unicast (via UDP) to the port of a specific application is Directed unicast (via UDP) to the port of a specific application is
an alternative transport class. Directed unicast is an OPTIONAL an alternative transport class. Directed unicast is an OPTIONAL
optimization and MAY be used by Mbus implementations for delivering optimization and MAY be used by Mbus implementations for delivering
messages addressed at a single application entity only -- the messages addressed to a single application entity only -- the
address of which the Mbus implementation has learned from other address of which the Mbus implementation has learned from other
message exchanges before. Note that the DestAddr field of such message exchanges before. Note that the DestAddr field of such
messages MUST still be filled in properly. Every Mbus entity SHOULD messages MUST be filled in properly nevertheless. Every Mbus entity
use a unique endpoint address for every message it sends to the Mbus SHOULD use a unique endpoint address for every message it sends to
multicast group or to individual receiving entities. A unique the Mbus multicast group or to individual receiving entities. A
endpoint address is a tuple consisting of the entity's IP address unique endpoint address is a tuple consisting of the entity's IP
and a port number, where the port number is different from the address and a UDP source port number, where the port number is
standard Mbus port number (yet to be assigned, see Section 15). different from the standard Mbus port number.
Messages MUST only be sent via unicast if the Mbus target address is Messages MUST only be sent via unicast if the Mbus target address is
unique and if the sending entity can verify that the receiving unique and if the sending entity can verify that the receiving
entity uses a unique endpoint address. The latter can be verified by entity uses a unique endpoint address. The latter can be verified by
considering the last message received from that entity. (Note that considering the last message received from that entity. (Note that
several Mbus entities, say within the same process, may share a several Mbus entities, say within the same process, may share a
common transport address; in this case, the contents of the common transport address; in this case, the contents of the
destination address field is used to further dispatch the message. destination address field is used to further dispatch the message.
Given the definition of "unique endpoint address" above the use of a Given the definition of "unique endpoint address" above the use of a
shared endpoint address and a dispatcher still allows other Mbus shared endpoint address and a dispatcher still allows other Mbus
skipping to change at page 19, line 39 skipping to change at page 20, line 44
iterate through the set of all iterate through the set of all
currently known Mbus addresses { currently known Mbus addresses {
let ti=the address in each iteration; let ti=the address in each iteration;
count the addresses for which count the addresses for which
the predicate isSubsetOf(ta,ti) yields true; the predicate isSubsetOf(ta,ti) yields true;
} }
If the count of matching addresses is exactly 1 the address is If the count of matching addresses is exactly 1 the address is
unique. The following algorithm can be used for the predicate unique. The following algorithm can be used for the predicate
isSubsetOf, that checks whether the second message matches the isSubsetOf, that checks whether the second message matches the
first according to the rules specified in Section 5. (A match first according to the rules specified in Section 4. (A match
means that a receiving entity that uses the second Mbus address means that a receiving entity that uses the second Mbus address
must also process received messages with the first address as a must also process received messages with the first address as a
target address.) target address.)
isSubsetOf(addr a1,a2) yields true, iff isSubsetOf(addr a1,a2) yields true, iff
every address element of a1 is contained every address element of a1 is contained
in a2's address element list in a2's address element list
An address element is contained in an address element list if the An address element is contained in an address element list if the
list contains an element that is equal to the first address list contains an element that is equal to the first address
element. An address element is considered equal to another element. An address element is considered equal to another
address element if it provides the same values for both of the address element if it provides the same values for both of the
two address element fields (key and value). two address element fields (key and value).
8. Reliability 7. Reliability
While most messages are expected to be sent using unreliable While most messages are expected to be sent using unreliable
transport, it may be necessary to deliver some messages reliably. transport, it may be necessary to deliver some messages reliably.
Reliability can be selected on a per message basis by means of the Reliability can be selected on a per message basis by means of the
MessageType field. Reliable delivery is supported for messages with MessageType field. Reliable delivery is supported for messages with
a single recipient only; i.e., all components of the DestAddr field a single recipient only; i.e., all components of the DestAddr field
have to be specified. An entity can thus only send reliable messages have to be specified. An entity can thus only send reliable messages
to known addresses, i.e. it can only send reliable messages to to known addresses, i.e. it can only send reliable messages to
entities that have announced their existence on the Mbus (e.g. by entities that have announced their existence on the Mbus (e.g. by
means of mbus.hello() messages (Section 10.1)). A sending entity means of mbus.hello() messages (Section 9.1)). A sending entity MUST
MUST NOT send a message reliably if the target address is not NOT send a message reliably if the target address is not unique.
unique. (See Transport (Section 7) for the specification of an (See Transport (Section 6) for the specification of an algorithm to
algorithm to determine whether an address is unique.) A receiving determine whether an address is unique.) A receiving entity MUST
entity MUST only process and acknowledge a reliable message if the only process and acknowledge a reliable message if the destination
destination address exactly matches its own source address (the address exactly matches its own source address (the destination
destination address MUST NOT be a subset of the source address). address MUST NOT be a subset of the source address).
Disallowing reliable message delivery for messages sent to multi- Disallowing reliable message delivery for messages sent to multi-
ple destinations is motivated by simplicity of the implementation as ple destinations is motivated by simplicity of the implementation as
well as the protocol. Although ACK implosions are not really an well as the protocol. The desired effect can be achieved by
issue and losses are exptected to be rare, achieving reliability for application layers by sending individual reliable messages to each
such messages would require full knowledge of the membership for fully qualified destination address, if the membership information
each subgroup which is deemed too much effort. The desired effect for the Mbus session is available.
can be achieved by application layers by sending individual reliable
messages to each fully qualified destination address, if the
membership information for the Mbus session is available.
Each message is tagged with a message sequence number. If the Each message is tagged with a message sequence number. If the
MessageType is "R", the sender expects an acknowledgment from the MessageType is "R", the sender expects an acknowledgment from the
recipient within a short period of time. If the acknowledgment is recipient within a short period of time. If the acknowledgment is
not received within this interval, the sender SHOULD retransmit the not received within this interval, the sender MUST retransmit the
message (with the same message sequence number), increase the message (with the same message sequence number), increase the
timeout, and restart the timer. Messages MUST be retransmitted a timeout, and restart the timer. Messages MUST be retransmitted a
small number of times (see below) before the transmission or the small number of times (see below) before the transmission or the
recipient is considered to have failed. If the message is not recipient is considered to have failed. If the message is not
delivered successfully, the sending application is notified. In this delivered successfully, the sending application is notified. In this
case, it is up to this application to determine the specific actions case, it is up to this application to determine the specific actions
(if any) to be taken. (if any) to be taken.
Reliable messages are acknowledged by adding their SeqNum to the Reliable messages MUST be acknowledged by adding their SeqNum to the
AckList field of a message sent to the originator of the reliable AckList field of a message sent to the originator of the reliable
message. Multiple acknowledgments MAY be sent in a single message. message. This message MUST be sent directly, i.e., using a fully
It is possible to either piggy-back the AckList onto another message qualified Mbus target address. Multiple acknowledgments MAY be sent
sent to the same destination, or to send a dedicated acknowledgment in a single message. Implementations MAY either piggy-back the
message, with no commands in the message payload part. AckList onto another message sent to the same destination, or MAY
send a dedicated acknowledgment message, with no commands in the
message payload part.
The precise procedures are as follows: The precise procedures are as follows:
Sender: A sender A of a reliable message M to receiver B SHOULD Sender: A sender A of a reliable message M to receiver B MUST
transmit the message via IP-multicast or via IP-unicast, keep a transmit the message either via IP-multicast or via IP-unicast,
copy of M, initialize a retransmission counter N to '1', and keep a copy of M, initialize a retransmission counter N to '1',
start a retransmission timer T (initialized to T_r). If an and start a retransmission timer T (initialized to T_r). If an
acknowledgment is received from B, timer T MUST be cancelled and acknowledgment is received from B, timer T MUST be cancelled and
the copy of M is discarded. If T expires, the message M SHOULD be the copy of M is discarded. If T expires, the message M MUST be
retransmitted, the counter N SHOULD be incremented by one, and retransmitted, the counter N MUST be incremented by one, and the
the timer SHOULD be restarted (set to N*T_r). If N exceeds the timer MUST be restarted (set to N*T_r). If N exceeds the
retransmission threshold N_r, the transmission is assumed to have retransmission threshold N_r, the transmission is assumed to have
failed, further retransmission attempts MUST NOT be undertaken, failed, further retransmission attempts MUST NOT be undertaken,
the copy of M SHOULD be discarded, and the sending application the copy of M MUST be discarded, and the sending application
SHOULD be notified. SHOULD be notified.
Receiver: A receiver B of a reliable message from a sender A SHOULD Receiver: A receiver B of a reliable message from a sender A MUST
acknowledge reception of the message within a time period T_c < acknowledge reception of the message within a time period T_c <
T_r. This MAY be done by means of a dedicated acknowledgment T_r. This MAY be done by means of a dedicated acknowledgment
message or by piggy-backing the acknowledgment on another message message or by piggy-backing the acknowledgment on another message
addressed only to A. addressed only to A.
Receiver optimization: In a simple implementation, B may choose to Receiver optimization: In a simple implementation, B may choose to
immediately send a dedicated acknowledgment message. However, for immediately send a dedicated acknowledgment message. However, for
efficiency, it could add the SeqNum of the received message to a efficiency, it could add the SeqNum of the received message to a
sender-specific list of acknowledgments; if the added SeqNum is sender-specific list of acknowledgments; if the added SeqNum is
the first acknowledgment in the list, B SHOULD start an the first acknowledgment in the list, B SHOULD start an
skipping to change at page 23, line 5 skipping to change at page 24, line 5
SHOULD be used by implementations: SHOULD be used by implementations:
T_r=100ms T_r=100ms
N_r=3 N_r=3
T_c=70ms T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r T_k=((N_r)*(N_r+1)/2)*T_r
9. Awareness of other Entities 8. Awareness of other Entities
Before Mbus entities can communicate with one another, they need to Before Mbus entities can communicate with one another, they need to
mutually find out about their existence. After this bootstrap mutually find out about their existence. After this bootstrap
procedure that each Mbus entity goes through all other entities procedure that each Mbus entity goes through all other entities
listening to the same Mbus know about the newcomer and the newcomer listening to the same Mbus know about the newcomer and the newcomer
has learned about all the other entities. Furthermore entities need has learned about all the other entities. Furthermore, entities need
to be able to to notice the failure (or leaving) of other entities. to be able to to notice the failure (or leaving) of other entities.
Any Mbus entity MUST announce its presence (on the Mbus) after Any Mbus entity MUST announce its presence (on the Mbus) after
starting up. This is to be done repeatedly throughout its lifetime starting up. This is to be done repeatedly throughout its lifetime
to address the issues of startup sequence: Entities should always to address the issues of startup sequence: Entities should always
become aware of other entities independent of the order of starting. become aware of other entities independent of the order of starting.
Each Mbus entity MUST maintain the number of Mbus session members Each Mbus entity MUST maintain the number of Mbus session members
and continously update this number according to any observed and continously update this number according to any observed
changes. The mechanisms of how the existence and the leaving of changes. The mechanisms of how the existence and the leaving of
other entities can be detected are dedicated Mbus messages for other entities can be detected are dedicated Mbus messages for
entity awareness: mbus.hello (Section 10.1) and mbus.bye (Section entity awareness: mbus.hello (Section 9.1) and mbus.bye (Section
10.2). Each Mbus protocol implementation MUST periodically send 9.2). Each Mbus protocol implementation MUST periodically send
mbus.hello messages that are used by other entities to monitor the mbus.hello messages that are used by other entities to monitor the
existence of that entity. If an entity has not received mbus.hello existence of that entity. If an entity has not received mbus.hello
messages for a certain time (see Section 9.2) from an entity the messages for a certain time (see Section 8.2) from an entity the
respective entity is considered to have left the Mbus and MUST be respective entity is considered to have left the Mbus and MUST be
excluded from the set of currently known entities. Upon the excluded from the set of currently known entities. Upon the
reception of a mbus.bye messages the respective entity is considered reception of a mbus.bye message the respective entity is considered
to have left the Mbus as well and MUST be excluded from the set of to have left the Mbus as well and MUST be excluded from the set of
currently known entities immediately. currently known entities immediately.
Each Mbus entity MUST send hello messages after startup to the Mbus. Each Mbus entity MUST send hello messages after startup to the Mbus.
After transmission of the hello message, it shall start a timer After transmission of the hello message, it should start a timer
after the expiration of which the next hello message is to be after the expiration of which the next hello message is to be
transmitted. Transmission of hello messages MUST NOT be stopped transmitted. Transmission of hello messages MUST NOT be stopped
unless the entity detaches from the Mbus. The interval for sending unless the entity detaches from the Mbus. The interval for sending
hello messages is depending on the current number of entities in an hello messages is depending on the current number of entities in an
Mbus group and can thus change dynamically in order to avoid Mbus group and can thus change dynamically in order to avoid
congestion due to many entities sending hello messages at a constant congestion due to many entities sending hello messages at a constant
high rate. high rate.
Section 9.1 specifies the calculation of hello message intervals Section 8.1 specifies the calculation of hello message intervals
that MUST be used by protocol implementations. Using the values that that MUST be used by protocol implementations. Using the values that
are calculated for obtaining the current hello message timer, the are calculated for obtaining the current hello message timer, the
timeout for received hello messages is calculated in Section 9.2. timeout for received hello messages is calculated in Section 8.2.
Section 10 specifies the command synopsis for the corresponding Mbus Section 9 specifies the command synopsis for the corresponding Mbus
messages. messages.
9.1 Hello Message Transmission Interval 8.1 Hello Message Transmission Interval
Since Mbus sessions may vary in size concerning the number of Since Mbus sessions may vary in size concerning the number of
entities care must be taken to allow the Mbus protocol to scale well entities care must be taken to allow the Mbus protocol to
over different numbers of entities automatically. The average rate automatically scale over different numbers of entities. The average
at which hello messages are received would increase linearly to the rate at which hello messages are received would increase linearly to
number of entities in a session if the sending interval was set to a the number of entities in a session if the sending interval was set
fixed value. Given a interval of 1 second this would mean that an to a fixed value. Given a interval of 1 second this would mean that
entity taking part in an Mbus session with n entities would receive an entity taking part in an Mbus session with n entities would
n hello messages per second. Assuming all entities resided on one receive n hello messages per second. Assuming all entities resided
host this would lead to n*n messages that have to be processed per on one host this would lead to n*n messages that have to be
second -- which is obviously not a viable solution for larger processed per second -- which is obviously not a viable solution for
groups. It is therefore necessary to deploy dynamically adapted larger groups. It is therefore necessary to deploy dynamically
hello message intervals taking varying numbers of entities into adapted hello message intervals taking varying numbers of entities
account. In the following we specify an algorithm that MUST be used into account. In the following, we specify an algorithm that MUST be
by implementations to calculate the interval for hello messages used by implementations to calculate the interval for hello messages
considering the observed number of Mbus entities. considering the observed number of Mbus entities.
The algorithm features the following characteristics: The algorithm features the following characteristics:
o The number of hello messages that are received by a single entity o The number of hello messages that are received by a single entity
in a certain time unit remains approximately constant as the in a certain time unit remains approximately constant as the
number of entities changes. number of entities changes.
o The effective interval that is used by a specific Mbus entity is o The effective interval that is used by a specific Mbus entity is
randomized in order to avoid unintentional synchronization of randomized in order to avoid unintentional synchronization of
hello messages within an Mbus session. The first hello message of hello messages within an Mbus session. The first hello message of
an entity is also delayed by a certain random amount of time. an entity is also delayed by a certain random amount of time.
o A timer reconsideration mechanism is deployed in order to adapt o A timer reconsideration mechanism is deployed in order to adapt
the interval more appropriately in situations where a rapid the interval more appropriately in situations where a rapid
change of the number of entities is observed. This is useful when change of the number of entities is observed. This is useful when
an entity joins an Mbus sessions and is still learning of the an entity joins an Mbus session and is still learning of the
existence of other entities or when a larger number of entities existence of other entities or when a larger number of entities
leaves the Mbus at once. leaves the Mbus at once.
9.1.1 Calculating the Interval for Hello Messages 8.1.1 Calculating the Interval for Hello Messages
The following names for values are used in the calculation specified The following names for values are used in the calculation specified
below (all time values in milliseconds): below (all time values in milliseconds):
hello_p: The last time a hello message has been sent by a Mbus hello_p: The last time a hello message has been sent by a Mbus
entity. entity.
hello_now: The current time hello_now: The current time
hello_d: The deterministic calculated interval between hello hello_d: The deterministic calculated interval between hello
skipping to change at page 25, line 17 skipping to change at page 26, line 17
last recomputed. last recomputed.
entities: The number of currently known entities. entities: The number of currently known entities.
The interval between hello messages MUST be calculated as follows: The interval between hello messages MUST be calculated as follows:
The number of currently known entities is multiplied by The number of currently known entities is multiplied by
c_hello_factor, yielding the interval between hello messages in c_hello_factor, yielding the interval between hello messages in
milliseconds. This is the deterministic calculated interval, milliseconds. This is the deterministic calculated interval,
denominated hello_d. The minimum value for hello_d is c_hello_min. denominated hello_d. The minimum value for hello_d is c_hello_min.
Thus hello_d=max(c_hello_min,c_hello_factor * entities). Section 9 Thus hello_d=max(c_hello_min,c_hello_factor * entities). Section 8
provides a specification of how to obtain the number of currently provides a specification of how to obtain the number of currently
known entities. Section 11 provides values for the constants known entities. Section 10 provides values for the constants
c_hello_factor and c_hello_min. c_hello_factor and c_hello_min.
The effective interval hello_e that is to be used by individual The effective interval hello_e that is to be used by individual
entities is calculated by multiplying hello_d with a randomly chosen entities is calculated by multiplying hello_d with a randomly chosen
number between c_hello_dither_min and c_hello_dither_max (see number between c_hello_dither_min and c_hello_dither_max (see
Section 11). Section 10).
hello_n, the time for the next hello message in milliseconds is set hello_n, the time for the next hello message in milliseconds is set
to hello_e + hello_now. to hello_e + hello_now.
9.1.2 Initialization of Values 8.1.2 Initialization of Values
Upon joining a session a protocol implementation sets hello_p, Upon joining an Mbus session a protocol implementation sets hello_p,
hello_now to 0 and entities, entities_p to 1 (the current Mbus hello_now to 0 and entities, entities_p to 1 (the current Mbus
entity itself) and then calculates the time for the next hello entity itself) and then calculates the time for the next hello
message as specified in Section 9.1.1. The next hello message is message as specified in Section 8.1.1. The next hello message is
scheduled for transmission at hello_n. scheduled for transmission at hello_n.
9.1.3 Adjusting the Hello Message Interval when the Number of Entities 8.1.3 Adjusting the Hello Message Interval when the Number of Entities
increases increases
When the existence of a new entity is observed by a protocol When the existence of a new entity is observed by a protocol
implementation the number of currently known entities is updated. No implementation the number of currently known entities is updated. No
further action concerning the calculation of the hello message further action concerning the calculation of the hello message
interval is required. The reconsideration of the timer interval interval is required. The reconsideration of the timer interval
takes place when the current timer for the next hello message takes place when the current timer for the next hello message
expires (see Section 9.1.5). expires (see Section 8.1.5).
9.1.4 Adjusting the Hello Message Interval when the Number of Entities 8.1.4 Adjusting the Hello Message Interval when the Number of Entities
decreases decreases
Upon realizing that an entity has left the Mbus the number of Upon realizing that an entity has left the Mbus the number of
currently known entities is updated and the following algorithm currently known entities is updated and the following algorithm
should be used to reconsider the timer interval for hello messages: should be used to reconsider the timer interval for hello messages:
1. The value for hello_n is updated by setting hello_n to 1. The value for hello_n is updated by setting hello_n to
hello_now + (entities/entities_p)*(hello_n - hello_now) hello_now + (entities/entities_p)*(hello_n - hello_now)
2. The value for hello_p is updated by setting hello_p to 2. The value for hello_p is updated by setting hello_p to
hello_now - (entities/entities_p)*(hello_now - hello_p) hello_now - (entities/entities_p)*(hello_now - hello_p)
3. The currently active timer for the next hello messages is 3. The currently active timer for the next hello messages is
cancelled and a new timer is started for hello_n. cancelled and a new timer is started for hello_n.
4. entities_p is set to entities. 4. entities_p is set to entities.
9.1.5 Expiration of hello timers 8.1.5 Expiration of hello timers
When the hello message timer expires, the protocol implementation When the hello message timer expires, the protocol implementation
MUST perform the following operations: MUST perform the following operations:
The hello interval hello_e is computed as specified in Section The hello interval hello_e is computed as specified in Section
9.1.1. 8.1.1.
If If
1. hello_e + hello_p is less than or equal to hello_now, a hello 1. hello_e + hello_p is less than or equal to hello_now, a hello
message is transmitted. hello_p is set to hello_now, hello_e message is transmitted. hello_p is set to hello_now, hello_e
is calculated again as specified in Section 9.1.1 and hello_n is calculated again as specified in Section 8.1.1 and hello_n
is set to hello_e + hello_now. is set to hello_e + hello_now.
2. else if hello_e + hello_p is greater than hello_now, hello_n 2. else if hello_e + hello_p is greater than hello_now, hello_n
is set to hello_e + hello_p. A new timer for the next hello 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 message is started to expire at hello_n. No hello message is
transmitted. transmitted.
entities_p is set to entities. entities_p is set to entities.
9.2 Calculating the Timeout for Hello Messages 8.2 Calculating the Timeout for Mbus Entities
Whenever an Mbus entity has not heard for a time span of Whenever an Mbus entity has not heard for a time span of
c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from another c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from another
Mbus entity it may consider this entity to have failed (or have quit Mbus entity it may consider this entity to have failed (or have quit
silently). The number of the currently known entities MUST be silently). The number of the currently known entities MUST be
updated accordingly. Note that no need for any further action is updated accordingly. See Section 8.1.4 for details. Note that no
necessarily implied from this observation. need for any further action is necessarily implied from this
observation.
Section 9.1.1 specifies how to obtain hello_d. Section 11 defines 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. values for the constants c_hello_dead and c_hello_dither_max.
10. Messages 9. Messages
This section defines some basic application independent messages This section defines some basic application independent messages
that MUST be understood by all implementations. This specification that MUST be understood by all implementations. This specification
does not contain application specific messages which are to be does not contain application specific messages which are to be
defined outside of the basic Mbus protocol specification. defined outside of the basic Mbus protocol specification.
An Mbus entity should be able to indicate that it is waiting for a 9.1 mbus.hello
certain event to happen (similar to a P() operation on a semaphore
but without creating external state somewhere). In conjunction with
this, an Mbus entity should be capable of indicating to another
entity that this condition is now satisfied (similar to a
semaphore's V() operation).
An appropriate commend set to implement the aforementioned concepts
is presented in the following sections.
10.1 mbus.hello
Syntax: Syntax:
mbus.hello(parameters...) mbus.hello(parameters...)
Parameters: see below Parameters: see below
HELLO messages MUST be sent unreliably to all Mbus entities. mbus.hello messages MUST be sent unreliably to all Mbus entities.
Each Mbus entity learns about other Mbus entities by observing their Each Mbus entity learns about other Mbus entities by observing their
HELLO messages and tracking the sender address of each message and mbus.hello messages and tracking the sender address of each message
can thus calculate the current number of entities. and can thus calculate the current number of entities.
HELLO messages MUST be sent periodically in dynamically calculated mbus.hello messages MUST be sent periodically in dynamically
intervals as specified in Section 9. calculated intervals as specified in Section 8.
Upon startup the first HELLO message MUST be sent after a delay Upon startup the first mbus.hello message MUST be sent after a delay
hello_delay, where hello_delay be a randomly chosen number between 0 hello_delay, where hello_delay be a randomly chosen number between 0
and c_hello_min (see Section 11). and c_hello_min (see Section 10).
10.2 mbus.bye 9.2 mbus.bye
Syntax: Syntax:
Parameters: - none - Parameters: - none -
An Mbus entity that is about to terminate (or "detach" from the An Mbus entity that is about to terminate (or "detach" from the
Mbus) SHOULD announce this by transmitting a BYE message. Mbus) SHOULD announce this by transmitting an mbus.bye message.
The BYE message MUST be sent unreliably to all entities. The mbus.bye message MUST be sent unreliably to all entities.
10.3 mbus.ping 9.3 mbus.ping
Syntax: Syntax:
Parameters: - none - Parameters: - none -
mbus.ping can be used to solicit other entities to signal their mbus.ping can be used to solicit other entities to signal their
existence by replying with a mbus.hello message. Each protocol existence by replying with a mbus.hello message. Each protocol
implementation MUST understand mbus.ping and reply with a mbus.hello implementation MUST understand mbus.ping and reply with an
message. The reply hello message MUST be delayed for hello_delay mbus.hello message. The reply hello message MUST be delayed for
milliseconds, where hello_delay be a randomly chosen number between hello_delay milliseconds, where hello_delay be a randomly chosen
0 and c_hello_min (see Section 11). number between 0 and c_hello_min (see Section 10).
As specified in Section 10.1 hello messages MUST be sent unreliably 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 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 messages. An entity that replies to mbus.ping with mbus.hello SHOULD
stop any outstanding timers for hello messages after sending the stop any outstanding timers for hello messages after sending the
hello message and schedule a new timer event for the subsequent hello message and schedule a new timer event for the subsequent
hello message. (Note that using the variables and the algorithms of hello message. (Note that using the variables and the algorithms of
Section 9.1.1 this can be achieved by setting hello_p to hello_now.) 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 entities mbus.ping allows a new entity to quickly check for other entities
without having to wait for the regular individual hello messages. By without having to wait for the regular individual hello messages. By
specifying a target address the new entity can restrict the specifying a target address the new entity can restrict the
solicitation for hello messages to a subset of entities it is solicitation for hello messages to a subset of entities it is
interested in. interested in.
10.4 mbus.quit 9.4 mbus.quit
Syntax: Syntax:
mbus.quit() mbus.quit()
Parameters: - none - Parameters: - none -
The QUIT message is used to request other entities to terminate The mbus.quit message is used to request other entities to terminate
themselves (and detach from the Mbus). Whether this request is themselves (and detach from the Mbus). Whether this request is
honoured by receiving entities or not is up to the discretion of the honoured by receiving entities or not is application specific and
application. not defined in this document.
The QUIT message can be multicast or sent reliably via unicast to a The mbus.quit message can be multicast or sent reliably via unicast
single Mbus entity or a group of entities. to a single Mbus entity or a group of entities.
10.5 mbus.waiting 9.5 mbus.waiting
Syntax: Syntax:
mbus.waiting(condition) mbus.waiting(condition)
Parameters: Parameters:
symbol condition symbol condition
The condition parameter is used to indicate that the entity The condition parameter is used to indicate that the entity
transmitting this message is waiting for a particular event to transmitting this message is waiting for a particular event to
occur. occur.
The WAITING messages may be broadcast to all Mbus entities, An Mbus entity should be able to indicate that it is waiting for a
certain event to happen (similar to a P() operation on a semaphore
but without creating external state somewhere). In conjunction with
this, an Mbus entity should be capable of indicating to another
entity that this condition is now satisfied (similar to a
semaphore's V() operation).
The mbus.waiting message may be broadcast to all Mbus entities,
multicast to an arbitrary subgroup, or unicast to a particular peer. multicast to an arbitrary subgroup, or unicast to a particular peer.
Transmission of the WAITING message MUST be unreliable and hence has Transmission of the mbus.waiting message MUST be unreliable and
to be repeated at an application-defined interval (until the hence has to be repeated at an application-defined interval (until
condition is satisfied). the condition is satisfied).
If an application wants to indicate that it is waiting for several If an application wants to indicate that it is waiting for several
conditions to be met, several WAITING messages are sent (possibly conditions to be met, several mbus.waiting messages are sent
included in the same Mbus payload). Note that HELLO and WAITING (possibly included in the same Mbus payload). Note that mbus.hello
messages may also be transmitted in a single Mbus payload. and mbus.waiting messages may also be transmitted in a single Mbus
payload.
10.6 mbus.go 9.6 mbus.go
Syntax: Syntax:
mbus.go(condition) mbus.go(condition)
Parameters: Parameters:
symbol condition symbol condition
This parameter specifies which condition is met. This parameter specifies which condition is met.
The GO message is sent by an Mbus entity to "unblock" another Mbus The mbus.go message is sent by an Mbus entity to "unblock" another
entity -- the latter of which has indicated that it is waiting for a Mbus entity -- which has indicated that it is waiting for a certain
certain condition to be met. Only a single condition can be condition to be met. Only a single condition can be specified per
specified per GO message. If several conditions are satisfied mbus.go message. If several conditions are satisfied simultaneously
simultaneously multiple GO messages MAY be combined in a single Mbus multiple mbus.go messages MAY be combined in a single Mbus payload.
payload.
The GO message MUST be sent reliably via unicast to the Mbus entity The mbus.go message MUST be sent reliably via unicast to the Mbus
to unblock. entity to unblock.
11. Constants 10. Constants
The following values for timers and counters mentioned in this The following values for timers and counters mentioned in this
document SHOULD be used by implementations: document SHOULD be used by implementations:
+-------------------+------------------------+--------------+ +-------------------+------------------------+--------------+
|Timer / Counter | Value | Unit | |Timer / Counter | Value | Unit |
+-------------------+------------------------+--------------+ +-------------------+------------------------+--------------+
|c_hello_factor | 200 | - | |c_hello_factor | 200 | - |
|c_hello_min | 1000 | milliseconds | |c_hello_min | 1000 | milliseconds |
|c_hello_dither_min | 0.9 | - | |c_hello_dither_min | 0.9 | - |
|c_hello_dither_max | 1.1 | - | |c_hello_dither_max | 1.1 | - |
|c_hello_dead | 5 | - | |c_hello_dead | 5 | - |
+-------------------+------------------------+--------------+ +-------------------+------------------------+--------------+
12. Mbus Security T_r=100ms
12.1 Security Model N_r=3
T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r
11. Mbus Security
11.1 Security Model
In order to prevent accidental or malicious disturbance of Mbus In order to prevent accidental or malicious disturbance of Mbus
communications through messages originated by applications from communications through messages originated by applications from
other users, message authentication is deployed (Section 12.3). For other users, message authentication is deployed (Section 11.3). For
each message a digest is calculated based on the value of a shared each message, a digest is calculated based on the value of a shared
secret key value. Receivers of messages can check if the sender secret key value. Receivers of messages can check if the sender
belongs to the same Mbus security domain by re-calculating the belongs to the same Mbus security domain by re-calculating the
digest and comparing it to the received value. Only if both values digest and comparing it to the received value. The messages must
are equal the messages must be processed further. In order to allow only be processed further if both values are equal. In order to
different simultaneous Mbus sessions at a given scope and to allow different simultaneous Mbus sessions at a given scope and to
compensate defective implementations of host local multicast message compensate defective implementations of host local multicast,
authentication MUST be provided by conforming implementations. message authentication MUST be provided by conforming
implementations.
Privacy of Mbus message transport can be achieved by optionally Privacy of Mbus message transport can be achieved by optionally
using symmetric encryption methods (Section 12.2). Each message can using symmetric encryption methods (Section 11.2). Each message can
be encrypted using an additional shared secret key and a symmetric be encrypted using an additional shared secret key and a symmetric
encryption algorithm. Encryption is OPTIONAL for applications, i.e. encryption algorithm. Encryption is OPTIONAL for applications, i.e.
it is allowed to configure an Mbus domain not to use encryption. But it is allowed to configure an Mbus domain not to use encryption. But
conforming implementations MUST provide the possibility to use conforming implementations MUST provide the possibility to use
message encryption (see below). message encryption (see below).
Message authentication and encryption can be parameterized by Message authentication and encryption can be parameterized by
certain values, e.g. by the algorithms to apply or by the keys to certain values, e.g. by the algorithms to apply or by the keys to
use. These parameters (amongst others) are defined in an Mbus use. These parameters (amongst others) are defined in an Mbus
configuration entity that is accessible to all Mbus entities that configuration object that is accessible by all Mbus entities that
participate in an Mbus session. In order to achieve interoperability participate in an Mbus session. In order to achieve interoperability
conforming implementations SHOULD consider the given Mbus conforming implementations SHOULD consider the given Mbus
configuration entity. Section 13 defines the mandatory and optional configuration. Section 12 defines the mandatory and optional
parameters as well as storage procedures for different platforms. parameters as well as storage procedures for different platforms.
Only in cases where none of the options for configuration entities Only in cases where none of the options for configuration entities
mentioned in Section 13 is applicable alternative methods of mentioned in Section 12 is applicable alternative methods of
configuring Mbus protocol entities MAY be deployed. configuring Mbus protocol entities MAY be deployed.
The algorithms and procedures for applying encryption and The algorithms and procedures for applying encryption and
authentication techniques are specified in the following sections. authentication techniques are specified in the following sections.
12.2 Encryption 11.2 Encryption
Encryption of messages is OPTIONAL, that means, an Mbus MAY be Encryption of messages is OPTIONAL, that means, an Mbus MAY be
configured not to use encryption. configured not to use encryption.
Implementations can choose between different encryption algorithms. Implementations can choose between different encryption algorithms.
Either AES [17], DES [15], 3DES (triple DES) [15] or IDEA [21] Either AES [17], DES [15], 3DES (triple DES) [15] or IDEA [21]
SHOULD be used for encryption. Implementations MUST at least provide SHOULD be used for encryption. Implementations MUST at least provide
AES and it is RECOMMENDED that they support the other algorithms as AES and it is RECOMMENDED that they support the other algorithms as
well. well.
For algorithms requiring en/decryption data to be padded to certain For algorithms requiring en/decryption data to be padded to certain
boundaries octets with a value of 0 SHOULD be used for padding boundaries octets with a value of 0 SHOULD be used for padding
characters. The padding characters MUST be appended after characters.
calculating the message digest when encoding and MUST be erased
before recalculating the message digest when decoding.
The length of the encryption keys is determined by the currently The length of the encryption keys is determined by the currently
used encryption algorithm. This means, the configured encryption key used encryption algorithm. This means, the configured encryption key
MUST NOT be shorter than the native key length for the currently MUST NOT be shorter than the native key length for the currently
configured algorithm. configured algorithm.
DES implementations MUST use the DES Cipher Block Chaining (CBC) DES implementations MUST use the DES Cipher Block Chaining (CBC)
mode. DES keys (56 bits) MUST be encoded as 8 octets as described in mode. DES keys (56 bits) MUST be encoded as 8 octets as described in
RFC1423[11], resulting in 12 Base64-encoded characters. IDEA uses RFC1423[11], resulting in 12 Base64-encoded characters. IDEA uses
128-bit keys (24 Base64-encoded characters). AES can use either 128-bit keys (24 Base64-encoded characters). AES can use either
128-bit, 192-bit or 256-bit keys. For Mbus encryption only 128-bit 128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES only
keys (24 Base64-encoded characters) MUST be used. 128-bit keys (24 Base64-encoded characters) MUST be used.
12.3 Message Authentication 11.3 Message Authentication
For authentication of messages, hashed message authentication codes For authentication of messages, hashed message authentication codes
(HMACs) as described in RFC2104[4] are deployed. In general, (HMACs) as described in RFC2104[4] are deployed. In general,
implementations can choose between a number of digest algorithms. implementations can choose between a number of digest algorithms.
For Mbus authentication, the HMAC algorithm MUST be applied in the For Mbus authentication, the HMAC algorithm MUST be applied in the
following way: following way:
The keyed hash value is calculated using the HMAC algorithm The keyed hash value is calculated using the HMAC algorithm
specified in RFC2104[4]. The concrete hash algorithm and the specified in RFC2104[4]. The concrete hash algorithm and the
secret hash key MUST be obtained from the Mbus configuration (see secret hash key MUST be obtained from the Mbus configuration (see
Section 13). Section 12).
The keyed hash values (see RFC2104[4]) MUST be truncated to 96 The keyed hash values (see RFC2104[4]) MUST be truncated to 96
bits (12 octets). bits (12 octets).
Subsequently, the resulting 12 octets MUST be Base64-encoded, Subsequently, the resulting 12 octets MUST be Base64-encoded,
resulting in 16 Base64-encoded characters (see RFC1521[6]). resulting in 16 Base64-encoded characters (see RFC1521[6]).
Either MD5 [14] or SHA-1 [16] SHOULD be used for message Either MD5 [14] or SHA-1 [16] SHOULD be used for message
authentication codes (MACs). An implementation MAY provide MD5, authentication codes (MACs). An implementation MAY provide MD5,
whereas SHA-1 MUST be implemented. whereas SHA-1 MUST be implemented.
The length of the hash keys is determined by the selected hashing The length of the hash keys is determined by the selected hashing
algorithm. This means, the configured hash key MUST NOT be shorter algorithm. This means, the configured hash key MUST NOT be shorter
than the native key length for the currently configured algorithm. than the native key length for the currently configured algorithm.
12.4 Procedures for Senders and Receivers 11.4 Procedures for Senders and Receivers
The mandatory subset of algorithms that MUST be provided by The mandatory subset of algorithms that MUST be provided by
implementations is AES and SHA-1. implementations is AES and SHA-1.
See Section 13 for a specification of notations for Base64-strings. See Section 12 for a specification of notations for Base64-strings.
A sender MUST apply the following operations to a message that is to A sender MUST apply the following operations to a message that is to
be sent: be sent:
1. If encryption is enabled, the message MUST be encrypted using 1. If encryption is enabled, the message MUST be encrypted using
the configured algorithm and the configured encryption key. the configured algorithm and the configured encryption key.
Padding (adding extra-characters) for block-ciphers MUST be Padding (adding extra-characters) for block-ciphers MUST be
applied as specified in Section 12.2. If encryption is not applied as specified in Section 11.2. If encryption is not
enabled, the message is left unchanged. enabled, the message is left unchanged.
2. Subsequently, a message authentication code (MAC) for the 2. Subsequently, a message authentication code (MAC) for the
encrypted message MUST be calculated using the configured encrypted message MUST be calculated using the configured
HMAC-algorithm and the configured hash key. HMAC-algorithm and the configured hash key.
3. The MAC MUST then be converted to Base64 encoding, resulting in 3. The MAC MUST then be converted to Base64 encoding, resulting in
12 Base64-charcters as specified in Section 12.3. 12 Base64-charcters as specified in Section 11.3.
4. At last, the sender MUST construct the final message by placing 4. At last, the sender MUST construct the final message by placing
the encrypted message after the base64-encoded MAC and a CRLF. the encrypted message after the base64-encoded MAC and a CRLF.
The ABNF definition for the final message is as follows: The ABNF definition for the final message is as follows:
final_msg = MsgDigest CRLF encr_msg final_msg = MsgDigest CRLF encr_msg
MsgDigest = base64 MsgDigest = base64
encr_msg = *OCTET encr_msg = *OCTET
A receiver MUST apply the following operations to a message that it A receiver MUST apply the following operations to a message that it
has received: has received:
1. Separate the base64-encoded MAC from the encypted message and 1. Separate the base64-encoded MAC from the encypted message and
decode the MAC. decode the MAC.
2. Re-calculate the MAC for the message using the configured 2. Re-calculate the MAC for the message using the configured
HMAC-algorithm and the configured hash key. HMAC-algorithm and the configured hash key.
3. Compare the original MAC with re-calculated MAC. If they differ, 3. Compare the original MAC with re-calculated MAC. If they differ,
the message MUST NOT be decrypted and parsed further. the message MUST NOT be decrypted and parsed further.
4. If encryption is enabled, the message MUST be decrypted using 4. If encryption is enabled, the message MUST be decrypted using
the confiured algorithm and the configured encryption key. the confiured algorithm and the configured encryption key.
Trailing octets with a value of 0 MUST be deleted. Trailing octets with a value of 0 MUST be deleted.
13. Mbus Configuration 12. Mbus Configuration
An implementation MUST be configurable by the following parameters: An implementation MUST be configurable by the following parameters:
Configuration version Configuration version
The version number of the given configuration entity. Version The version number of the given configuration entity. Version
numbers allow implementations to check if they can process the numbers allow implementations to check if they can process the
entries of a given configuration entity. Version number are entries of a given configuration entity. Version number are
integer values. The version number for the version specified integer values. The version number for the version specified
here is 1. here is 1.
skipping to change at page 34, line 35 skipping to change at page 35, line 35
Scope Scope
The multicast scope to be used for sent messages. The multicast scope to be used for sent messages.
The upper parameters are mandatory and MUST be present in every Mbus The upper parameters are mandatory and MUST be present in every Mbus
configuration entity. configuration entity.
The following parameters are optional. When they are present they The following parameters are optional. When they are present they
MUST be honoured but when they are not present implementations MUST be honoured but when they are not present implementations
SHOULD fall back to the predefined default values (as defined in SHOULD fall back to the predefined default values (as defined in
Transport (Section 7)): Transport (Section 6)):
Address Address
The non-standard multicast address to use for message The non-standard multicast address to use for message
transport. transport.
Use of Broadcast Use of Broadcast
It can be specified whether broadcast should be used. If It can be specified whether broadcast should be used. If
broadcast has been configured implementations SHOULD use the broadcast has been configured implementations SHOULD use the
network broadcast address (as specified in Section 7.1.3) network broadcast address (as specified in Section 6.1.3)
instead of the standard multicast address. instead of the standard multicast address.
Port Number Port Number
The non-standard port number to use for message transport. The non-standard UDP port number to use for message transport.
Two distinct facilities for parameter storage are considered: For Two distinct facilities for parameter storage are considered: For
Unix-like systems a configuration file SHOULD be used and for Unix-like systems a per-user configuration file SHOULD be used and
Windows-95/98/NT/2000 systems a set of registry entries is defined for Windows-95/98/NT/2000 systems a set of registry entries is
that SHOULD be used. For other systems it is RECOMMENDED that the defined that SHOULD be used. For other systems it is RECOMMENDED
file-based configuration mechanism is used. that the file-based configuration mechanism is used.
The syntax of the values for the respective parameter entries The syntax of the values for the respective parameter entries
remains the same for both configuration facilities. The following remains the same for both configuration facilities. The following
defines a set of ABNF (see RFC2234[12]) productions that are later defines a set of ABNF (see RFC2234[12]) productions that are later
referenced for the definitions for the configuration file syntax and re-used for the definitions for the configuration file syntax and
registry entries: registry entries:
algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" / algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
"HMAC-MD5-96" / "HMAC-SHA1-96" "HMAC-MD5-96" / "HMAC-SHA1-96"
scope = "HOSTLOCAL" / "LINKLOCAL" scope = "HOSTLOCAL" / "LINKLOCAL"
key = base64 key = base64
version_number = 1*10DIGIT version_number = 1*10DIGIT
skipping to change at page 35, line 47 skipping to change at page 36, line 47
commas MUST always be present though. commas MUST always be present though.
A Base64 string consists of the characters defined in the Base64 A Base64 string consists of the characters defined in the Base64
char-set (see RFC1521[6]) including all eventual padding characters, char-set (see RFC1521[6]) including all eventual padding characters,
i.e. the length of a Base64-string is always a multiple of 4. i.e. the length of a Base64-string is always a multiple of 4.
The scope parameter is used to configure an IP-Multicast scope and The scope parameter is used to configure an IP-Multicast scope and
may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations
SHOULD choose an appropriate IP-Multicast scope depending on the SHOULD choose an appropriate IP-Multicast scope depending on the
value of this parameter and construct an effective IP-Address value of this parameter and construct an effective IP-Address
considering the specifications of Section 7.1. considering the specifications of Section 6.1.
The use of broadcast is configured by providing the value The use of broadcast is configured by providing the value
"BROADCAST" for the address field. If broadcast has been configured, "BROADCAST" for the address field. If broadcast has been configured,
implementations SHOULD use the network broadcast address for the implementations SHOULD use the network broadcast address for the
used IP version instead of the standard multicast address. used IP version instead of the standard multicast address.
The version_number parameter specifies a version number for the used The version_number parameter specifies a version number for the used
configuration entity. configuration entity.
13.1 File based parameter storage 12.1 File based parameter storage
The file name for an Mbus configuration file is ".mbus" in the The file name for an Mbus configuration file is ".mbus" in the
user's home-directory. If an environment variable called MBUS is user's home-directory. If an environment variable called MBUS is
defined implementations SHOULD interpret the value of this variable defined implementations SHOULD interpret the value of this variable
as a fully qualified file name that is to be used for the as a fully qualified file name that is to be used for the
configuration file. Implementations MUST ensure that this file has configuration file. Implementations MUST ensure that this file has
appropriate file permissions that prevent other users to read or appropriate file permissions that prevent other users to read or
write it. The file MUST exist before a conference is initiated. Its write it. The file MUST exist before a conference is initiated. Its
contents MUST be UTF-8 encoded and MUST be structured as follows: contents MUST be UTF-8 encoded and MUST comply to the following
syntax definition:
mbus-file = mbus-topic LF *(entry LF) mbus-file = mbus-topic LF *(entry LF)
mbus-topic = "[MBUS]" mbus-topic = "[MBUS]"
entry = 1*(version_info / hashkey_info entry = 1*(version_info / hashkey_info
/ encryptionkey_info / scope_info / encryptionkey_info / scope_info
/ port_info / address_info) / port_info / address_info)
version_info = "CONFIG_VERSION=" version_number version_info = "CONFIG_VERSION=" version_number
skipping to change at page 37, line 13 skipping to change at page 38, line 13
An example Mbus configuration file: An example Mbus configuration file:
[MBUS] [MBUS]
CONFIG_VERSION=1 CONFIG_VERSION=1
HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy) HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy)
ENCRYPTIONKEY=(DES,MTIzMTU2MQ==) ENCRYPTIONKEY=(DES,MTIzMTU2MQ==)
SCOPE=HOSTLOCAL SCOPE=HOSTLOCAL
ADDRESS=224.255.222.239 ADDRESS=224.255.222.239
PORT=47000 PORT=47000
13.2 Registry based parameter storage 12.2 Registry based parameter storage
For systems lacking the concept of a user's home-directory as a For systems lacking the concept of a user's home-directory as a
place for configuration files the suggested database for place for configuration files the suggested database for
configuration settings (e.g. the Windows9x-, Windows NT-, Windows configuration settings (e.g. the Windows9x-, Windows NT-, Windows
2000-registry) SHOULD be used. The hierarchy for Mbus related 2000-registry) SHOULD be used. The hierarchy for Mbus related
registry entries is as follows: registry entries is as follows:
HKEY_CURRENT_USER\Software\Mbone Applications\Mbus HKEY_CURRENT_USER\Software\Mbus
The entries in this hierarchy section are: The entries in this hierarchy section are:
+---------------+--------+----------------+ +---------------+--------+----------------+
|Name | Type | ABNF production| |Name | Type | ABNF production|
+---------------+--------+----------------| +---------------+--------+----------------|
|CONFIG_VERSION | DWORD | version_number | |CONFIG_VERSION | DWORD | version_number |
|HASHKEY | String | key_value | |HASHKEY | String | key_value |
|ENCRYPTIONKEY | String | key_value | |ENCRYPTIONKEY | String | key_value |
|SCOPE | String | scope | |SCOPE | String | scope |
|ADDRESS | String | address | |ADDRESS | String | address |
|PORT | DWORD | port | |PORT | DWORD | port |
+---------------+--------+----------------+ +---------------+--------+----------------+
The same syntax for key values as for the file based configuration The same syntax for key values as for the file based configuration
facility MUST be used. facility MUST be used.
14. Security Considerations 13. Security Considerations
The Mbus security mechanisms are specified in Section 12.1. The Mbus security mechanisms are specified in Section 11.1.
It should be noted that the Mbus transport specification defines a It should be noted that the Mbus transport specification defines a
mandatory baseline set of algorithms that have to be supported by mandatory baseline set of algorithms that have to be supported by
implementations. This baseline set is intended to provide reasonable implementations. This baseline set is intended to provide reasonable
security by mandating algorithms and key lengths that are currently security by mandating algorithms and key lengths that are currently
considered to be cryptographically strong enough. considered to be cryptographically strong enough.
However, in order to allow for efficiency it is allowable to use However, in order to allow for efficiency it is allowable to use
cryptographically weaker algorithms, for example HMAC-MD5 instead of cryptographically weaker algorithms, for example HMAC-MD5 instead of
HMAC-SHA1. Furthermore, encryption can be turned off completely if HMAC-SHA1. Furthermore, encryption can be turned off completely if
skipping to change at page 39, line 5 skipping to change at page 40, line 5
In any way, application developers should be aware of incorrect IP In any way, application developers should be aware of incorrect IP
implementations that do not conform to RFC 1122[2] and do send implementations that do not conform to RFC 1122[2] and do send
datagrams with TTL values of zero, resulting in Mbus messages sent datagrams with TTL values of zero, resulting in Mbus messages sent
to the local network link although a user might have selected host to the local network link although a user might have selected host
local scope in the Mbus configuration. When using of local scope in the Mbus configuration. When using of
administratively scoped multicast users cannot always assume the administratively scoped multicast users cannot always assume the
presence of correctly configured boundary routers. In these cases presence of correctly configured boundary routers. In these cases
the use of encryption SHOULD be considered if privacy is desired. the use of encryption SHOULD be considered if privacy is desired.
15. IANA Considerations 14. IANA Considerations
The IANA is requested to assign a link-local IPv4 multicast address The IANA is requested to assign a link-local IPv4 multicast address
from the address space 224.0.0.0/24, an IPv6 permanent multicast from the address space 224.0.0.0/24 and an IPv6 permanent multicast
address and a port number. For the time being the tentative IPv4 address. For the time being the tentative IPv4 multicast address
multicast address 239.255.255.247 and the port number 47000 239.255.255.247 SHOULD be used.
(decimal) SHOULD be used.
The registered Mbus UDP port number is 47000.
References References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997. Levels", RFC 2119, BCP 14, March 1997.
[2] Braden, R., "Requirements for Internet Hosts -- Communication [2] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC 1122, October 1989. Layers", RFC 1122, October 1989.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
 End of changes. 176 change blocks. 
392 lines changed or deleted 481 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/