draft-ietf-mmusic-mbus-transport-00.txt   draft-ietf-mmusic-mbus-transport-01.txt 
Network Working Group Ott
Internet-Draft TZI, Universitaet Bremen
Expires: July 3, 2000 Perkins
University College London
Kutscher
TZI, Universitaet Bremen
January 3, 2000
INTERNET-DRAFT J. Ott/C. Perkins/D. Kutscher A Message Bus for Local Coordination
Expires: February 1999 Universitaet Bremen/UCL/Universitaet Bremen draft-ietf-mmusic-mbus-transport-01.txt
August 1998
A Message Bus for Conferencing Systems Status of this Memo
draft-ietf-mmusic-mbus-transport-00.txt
Status of this memo This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
This document is an Internet-Draft. Internet-Drafts are working Internet-Drafts are working documents of the Internet Engineering
documents of the Internet Engineering Task Force (IETF), its areas, Task Force (IETF), its areas, and its working groups. Note that
and its working groups. Note that other groups may also distribute other groups may also distribute working documents as
working documents as Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
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 learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
ftp.isi.edu (US West Coast).
Distribution of this document is unlimited. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 3, 2000.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
In a variety of scenarios, a local communication channel is desirable In a variety of conferencing scenarios, a local communication
for conference-related information exchange between co-located but channel is desirable for conference-related information exchange
otherwise independent application entities, for example those taking between co- located but otherwise independent application entities,
part in application sessions that belong to the same conference. for example those taking part in application sessions that belong to
Such a mechanism allows for coordination of applications entities to the same conference. In loosely coupled conferences such a
e.g. implement synchronization between media streams or realize mechanism allows for coordination of applications entities to e.g.
tightly coupled conferences. The local conference Message Bus (Mbus) implement synchronization between media streams or to configure
provides a means to achieve the necessary amount of coordination entities without user interaction. It can also be used to implement
between co-located conferencing applications for virtually any type tightly coupled conferences enabling a conference controller to
of conference. The Message Bus comprises two logically distinct enforce conference wide control within a end system.
parts: a message transport and addressing infrastructure and a set of
common as well as media tool specific messages. This documents deals
with message addressing, transport, and security issues and defines
the message syntax for the Mbus. It does not define application
oriented semantics and procedures for using the message bus. The
common procedures for Mbus operation as well as the common set of
application/media specific messages are introduced in a companion
Internet draft[9].
This document is intended for discussion in the Multiparty Multimedia The local Message Bus (Mbus) provides a means to achieve the
Session Control (MMUSIC) working group of the Internet Engineering necessary amount of coordination between co-located conferencing
Task Force. Comments are solicited and should be addressed to the applications for virtually any type of conference as postulated in a
working group's mailing list at confctrl@isi.edu and/or the authors. a companion requirement document[11]. The Message Bus comprises two
logically distinct parts: a message transport infrastructure and a
set of common as well as protocol/ media/tool-specific messages
along with a conference-specific addressing scheme. This document
deals with message addressing, transport, and security issues and
defines the message syntax for the Mbus. It does not define
application oriented semantics and procedures for using the message
bus. Application specific command sets and procedures for
applications using the Mbus are expected to be defined in follow-up
documents.
1. Introduction This document is intended for discussion in the Multiparty
Multimedia Session Control (MMUSIC) working group of the Internet
Engineering Task Force. Comments are solicited and should be
addressed to the working group's mailing list at confctrl@isi.edu
and/or the authors.
1.1. Background Table of Contents
In the Mbone community a model has arisen whereby a set of loosely 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
coupled tools are used to participate in a conference. A typical 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 4
scenario is that audio, video and shared workspace functionality is 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 4
provided by three separate tools (although some combined tools 1.3 Terminology for requirement specifications . . . . . . . . . 4
exist). This maps well onto the underlying RTP [5] (as well as 2. General Outline . . . . . . . . . . . . . . . . . . . . . . 5
other) media streams, which are also transmitted separately. Given 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7
such an architecture, it is useful to be able to perform some 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9
coordination of the separate media tools. For example, it may be 4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 10
desirable to communicate playout-point information between audio and 5. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 11
video tools, in order to implement lip-synchronisation, to arbitrate 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13
the use of shared resources (such as input devices), etc. 7. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 15
7.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 15
7.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 15
7.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 15
8. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.4 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 19
8.5 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Timer and Counters . . . . . . . . . . . . . . . . . . . . . 21
10. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 22
10.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 Message Authentication . . . . . . . . . . . . . . . . . . . 22
10.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 24
11.1 File based parameter storage . . . . . . . . . . . . . . . . 25
11.2 Registry based parameter storage . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . 28
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29
References . . . . . . . . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
A. Mbus Addresses for Conferencing . . . . . . . . . . . . . . 32
Full Copyright Statement . . . . . . . . . . . . . . . . . . 34
A refinement of this architecture relies on the presence of a number 1. Introduction
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).
Although current practice in the Mbone community is to work with a 1.1 Background
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.
The Message Bus defined in this and a companion document provides a The requirement specification as defined in the requirements
suitable means for local communication that serves all of the above draft[11] provides a set of scenario descriptions for the usage of a
purposes. local coordination infrastructure. The Message Bus defined in this
and a companion document provides a suitable means for local
communication that serves all of the purposes mentioned in the
requirement document.
1.2. Purpose 1.2 Purpose
Two components constitute the Message Bus: the (lower level) message Two components constitute the Message Bus: the (lower level) message
passing mechanisms and the (higher level) messages and their passing mechanisms and the (higher level) messages and their
semantics. semantics along with their addressing scheme.
The purpose of this document is to define the characteristics of the The purpose of this document is to define the characteristics of the
basic Mbus message passing mechanism which is common to all Mbus lower level Mbus message passing mechanism which is common to all
implementations. This includes the specification of Mbus implementations. This includes the specification of
o the generic Mbus message format; o the generic Mbus message format;
o the addressing concept for application entities; o the addressing concept for application entities (note that
addressing details are defined by the application environment);
o the transport mechanisms to be employed for conveying messages o the transport mechanisms to be employed for conveying messages
between (co-located) application entities; between (co-located) application entities;
o the security concept to prevent misuse of the Message Bus (as o the security concept to prevent misuse of the Message Bus (as
taking control of another user's conferencing environment); and taking control of another user's conferencing environment);
o the details of the Mbus message syntax. o the details of the Mbus message syntax; and
1.3. Terminology for requirement specifications 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", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and and "OPTIONAL" are to be interpreted as described in RFC 2119[1] and
indicate requirement levels for compliant Mbus implementations. indicate requirement levels for compliant Mbus implementations.
1.4. Definition of terms 2. General Outline
o Conference
The relationship between a set of human beings that are
communicating together. In this document, the term is used for
both tightly and loosely coupled [4] computer based conferences.
o Participant
A (typically human) being that takes part in a conference.
o Member
The system, including all software and hardware components, that
is used in a teleconference to represent a single participant.
o End system
A host or a set of locally interconnected hosts[1] that is used
_________________________
[1] In this document, we use the term ``end system'' as a syn-
onym for ``host'' in the simplest case. We do not want to ex-
clude, however, that the local system that serves one participant
may be composed of several ``hosts'' in the Internet sense.
as an interface to a teleconference by a single participant. The Mbus is supposed to operate in a variety of scenarios as
The end system runs all the required conferencing software (e.g. outlined in the companion requirement document[11]. From these
media agents, session directory, and a controlling entity). End scenarios, the following (minimum) requirements are derived that
system and software together constitute a member in each of the have to be met by the Mbus design to provide a suitable local
conferences a user participates in. communication infrastructure.
o Conference controller Local coordination involves a widely varying number of entities:
some messages (such as membership information, floor control
notifications, dissemination conference state changes, etc.) may
need to be destined for all local application entities. Messages may
also be targeted at a certain application class (e.g. all
whiteboards or all audio tools) or agent type (e.g. all user
interfaces rather than all media engines). Or there may be any
(application- or message- specific) subgrouping defining the
intended recipients, e.g. messages related to media synchronization.
Finally, there will be messages that are directed to a single
entity, for example, specific configuration settings that a
conference controller sends to a application entity or
query-response exchanges between any local server and its clients.
A dedicated application running on an end system that implements The Mbus concept as presented here satisfies these different
a horizontal conference control protocol through which it communication models by defining different message transport
interacts with conference controllers on other end systems to mechanisms (defined in Section 6) and by providing a flexible
implement (typically tight) conference control mechanisms and addressing scheme (defined in Section 4).
conference policies. The conference controller constitutes the
electronic representation of its (human) user and her actions
with respect to conference(s) as a whole (rather than with
respect to individual media sessions).
o UCI Furthermore, Mbus messages exchanged between application entities
may have different reliability requirements (which are typically
derived from their semantics). Some messages will have a rather
informational character conveying ephemeral state information (which
is refreshed/updated periodically), such as the volume meter level
of an audio receiver entity to be displayed by its user interface
agent. Certain Mbus messages (such as queries for parameters or
queries to local servers) may require a response from the peer(s)
thereby providing an explicit acknowledgment at the semantic level
on top of the Mbus. Other messages will modify the application or
conference state and hence it is crucial that they do not get lost.
The latter type of message has to be delivered reliably to the
recipient, whereas message of the first type do not require
reliability mechanisms at the Mbus transport layer. For messages
confirmed at the application layer it is up to the discretion of the
application whether or not to use a reliable transport underneath.
A universal communication identifier of a person. This may be In some cases, application entities will want to tailor the degree
the e-mail address of an individual (or some other globally of reliability to their needs, others will want to rely on the
unique identifier) that is part of the information to identify underlying transport to ensure delivery of the messages -- and this
her within a conference but can also be used to invite her via may be different for each Mbus message. The Mbus message passing
the Session Initiation Protocol (SIP) [6] protocol. mechanism described in this paper provides a maximum of flexibility
by providing reliable transmission achieved through transport-layer
acknowledgments (in case of point-to-point communications only) as
well as unreliable message passing (for unicast, local multicast,
and local broadcast). We address this topic in Section 4.
o Presence Finally, accidental or malicious disturbance of Mbus communications
through messages originated by applications from other users needs
to be prevented. Accidental reception of Mbus messages from other
users may occur if either two users share the same workstation for
conferencing or are using end systems spread across the same
physical network: in either case, the Mbus multicast address and the
port number may match leading to reception of the other party's Mbus
messages in addition to a user's own ones. Malicious disturbance
may happen because of applications multicasting (e.g. at a global
scope) or unicasting Mbus messages (which could contain a
"conf.terminated" command). To eliminate the possibility of
receiving bogus Mbus messages, the Mbus protocol contains message
digests for authentication. Furthermore, the Mbus allows for
encryption to ensure privacy and thus enable using the Mbus for
local key distribution and other functions potentially sensitive to
eavesdropping. This document defines the framework for configuring
Mbus applications with regard to security parameters in Section 11.
A presence corresponds to a person (identified by a UCI) being 3. Message Format
``logged in'' at an end system and available for conferencing,
i.e. a presence may be identified by the pair of a user's UCI
and the respective end system's identification (such as a host
name). A presence of a user may appear in many conferences (see
below).
o Appearance 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
provides information and commands to the destination entity. The
following information is included in the header:
An instantiation of a user's presence actually participating The MsgDigest is a Base64-encoded (see RFC1521[5]) calculated
(i.e. appearing) in a conference is referred to as an hash value of the entire message (starting from the ProtocolID
appearance. There is a one-to-one correspondence between field) as described in Section 10 and Section 11.
appearances and members.
o Conference context A fixed ProtocolID field identifies the version of the message
bus protocol used. The protocol defined in this document is
"mbus/1.0" (case-sensitive).
All state information kept about a conference at each member of A sequence number (SeqNum) is contained in each message. The
this conference. first message sent by a source SHOULD have SeqNum equal to zero,
and it MUST increment by one for each message sent by that
source. A single sequence number is used for all messages from a
source, irrespective of the intended recipients and the
reliability mode selected. SeqNums are decimal numbers in ASCII
representation.
o Application session (AS), Session The TimeStamp field is also contained in each message and SHOULD
contain a decimal number representing the time at message
construction in seconds since 00:00:00, UTC, January 1, 1970.
The set of media agents/applications that act as peers to each A MessageType field indicates the kind of message being sent.
other within a conference. For real-time data, this generally The value "R" indicates that the message is to be transmitted
will be an RTP session [5]; for other application protocols, reliably and MUST be acknowledged by the recipient, "U" indicates
other horizontal protocols may define their own type of session an unreliable message which MUST NOT be acknowledged.
concept. Possible synonyms are ``application group'' or ``media
agent group''.
o Application instance, application entity, media agent The SrcAddr field identifies the sender of a message. This MUST
be a complete address, with all address elements specified. The
addressing scheme is described in Section 4.
A program instance taking part in an application session for a The DestAddr field identifies the intended recipient(s) of the
conference participant. There can be more than one instance of message. This field MAY contain wildcards by omitting address
the same program in one session, there can also be more than one element and hence address any number (including zero) of
instance in different sessions. application entities. The addressing scheme is described in
Section 4.
2. Requirements and Concepts The AckList field comprises a list of SeqNums for which this
message is an acknowledgment. See Section 5 for details.
The Mbus is supposed to operate in a variety of scenarios as outlined The header is followed by the message body which contains one or
in the introduction. From these scenarios, the following (minimum) more commands to be delivered to the destination entity. The syntax
requirements are derived that have to be met by the Mbus design to for a complete message is given in Message syntax (Section 7).
provide a suitable local communication infrastructure.
Local coordination involves a widely varying number of entities: some If multiple commands are contained within the same Mbus message
messages may need to be destined for all local application entities, payload, they MUST to be delivered to the Mbus application in the
such as membership information, floor control notifications, same sequence in which they appear in the message payload.
dissemination conference state changes, etc. Messages may also be
targeted at a certain application class (e.g. all whiteboards or all
audio tools) or agent type (e.g. all user interfaces rather than all
media engines). Or there may be any (application- or message-
specific) subgrouping defining the intended recipients, e.g. messages
related to media synchronization. Finally there will be messages
that are directed to a single entity, for example, specific
configuration settings that a conference controller sends to a
application entity or query-response exchanges between any local
server and its clients.
The Mbus concept as presented here satisfies these different 4. Addressing
communication models by defining different message transport
mechanisms (defined in section 3.4) and by providing a flexible
addressing scheme (defined in section 3.2).
Furthermore, Mbus messages exchanged between application entities may Each entity on the message bus SHOULD respond to messages sent to
have different reliability requirements (which are typically derived one (or more) addresses. Addresses are sequences of address elements
from their semantics). Some messages will have a rather that are tag/value pairs. The tag and the value are separated by a
informational character conveying ephemeral state information (which colon and tag/value pairs are separated by whitespace, like this:
is refreshed/updated periodically), such as the volume meter level of
an audio receiver entity to be displayed by its user interface agent.
Certain Mbus messages (such as queries for parameters or queries to
local servers) may require a response from the peer(s) thereby
providing an explicit acknowledgment at the semantic level on top of
the Mbus. Other messages will modify the application or conference
state and hence it is crucial that they do not get lost. The latter
type of message has to be delivered reliably to the recipient,
whereas message of the first type do not require reliability
mechanisms at the Mbus transport layer. For messages confirmed at the
application layer it is up to the discretion of the application
whether or not to use a reliable transport underneath.
In some cases, application entities will want to tailor the degree of (tag:value tag:value ...)
reliability to their needs, others will want to rely on the
underlying transport to ensure delivery of the messages -- and this
may be different for each Mbus message. The Mbus message passing
mechanism described in this paper provides a maximum of flexibility
by providing reliable transmission achieved through transport-layer
acknowledgments (in case of point-to-point communications only) as
well as unreliable message passing (for unicast, local multicast, and
local broadcast). We address this topic in section 3.2.
Finally, accidental or malicious disturbance of Mbus communications The formal ABNF syntax definition for Mbus addresses and their
through messages originated by applications from other users needs to elements is as follows:
be prevented. Accidental reception of Mbus messages from other users
may occur if either two users share the same workstation for
conferencing or are using end systems spread across the same physical
network: in either case, the Mbus multicast address and the port
numbers may match leading to reception of the other party's Mbus
messages in addition to a user's own ones. Malicious disturbance may
happen because of applications multicasting (e.g. at a global scope)
or unicasting Mbus messages (which could contain a "TERMINATE
CONFERENCE" command). To eliminate the possibility of receiving
bogus Mbus messages, the Mbus protocol therefore contains message
digests for authentication. Furthermore, the Mbus allows for
encryption to ensure privacy and thus enable using the Mbus for local
key distribution and other functions potentially sensitive to
eavesdropping. This document defines the framework for configuring
Mbus applications with regard to security parameters in appendix C
(Mbus configuration).
3. Message Bus Specification mbus_address = "(" *address_element ")"
address_element = *WSP address_tag ":" address_value *WSP
address_tag = 1*32(ALPHA)
address_value = 1*64(%x21-7F)
; any 7-bit US-ASCII character
; excluding white space
; and control characters
3.1. Message Format Each entity has a fixed sequence of address elements constituting
its address and MUST only process messages sent to addresses that
either match all elements or consist of a subset of its own address
elements. Each element value in this subset must match the
correspoding value of the receiver's address element value. The
order of address elements in an address sequence is not relevant.
For example, an entity with an address of:
A conference coordination message comprises a header and a body. The (conf:test media:audio module:engine app:rat id:4711-1@134.102.218.45)
header is used to indicate how and where a message should be
delivered, the body provides information and commands to the
destination entity. The following information is included in the
header:
o The MsgDigest is a Base64-encoded[3] calculated hash value of will process messages sent to
the entire message (starting from the ProtocolID field) as
described in appendices A (Algorithms) and C (Mbus
configuration).
o A fixed ProtocolID field identifies the version of the message (media:audio module:engine)
bus protocol used. The protocol defined in this document is
``mbus/1.0''.
o A sequence number SeqNum is contained in each message. The first and
message sent by a source SHOULD have SeqNum equal to zero, and
it SHALL increment by one for each message sent by that source.
A single sequence is used for all message from a source,
irrespective of the intended recipients and the reliability mode
selected. SeqNums are decimal numbers in ASCII representation.
o The TimeStamp field is also contained in each message and SHALL (module:engine)
contain a decimal number representing the time at message
construction in seconds since 00:00:00, UTC, January 1, 1970.
o A MessageType field indicates the kind of message being sent. but must ignore messages sent to
The value ``R'' indicates that the message is to be transmitted
reliably and MUST be acknowledged by the recipient, ``U''
indicates an unreliable message which MUST NOT be acknowledged.
o The SrcAddr field identifies the sender of a message. This MUST (conf:test media:audio module:engine app:rat id:123-4@134.102.218.45 foo:bar)
be a full address, with no wildcards present. The addressing
scheme is described in section 3.2.
o The DestAddr field identifies the intended recipient(s) of the and
message. This field MAY contain wildcards and hence address any
number (including zero) of application entities. The addressing
scheme is described in section 3.2.
o The AckList field comprises a list of SeqNums for which this (foo:bar)
message is an acknowledgment. See section 3.3 for details.
The header is followed by the message body which contains one or more A message that should be processed by all entities requires an empty
messages to be delivered to the destination entity. The syntax for a set of address elements.
complete message is given in section ``syntax''.
3.2. Addressing 4.1 Mandatory Address Elements
Each entity on the message bus SHOULD respond to messages sent to one Each Mbus entity MUST provide one mandatory address element that
(or more) addresses. Addresses are quad-tuples written as: allows to identify the entity. The element name is "id" and the
(MediaType ModuleType AppName AppInstance) value MUST be be composed of the following components:
where one or more fields MAY be wildcarded (with `*') in some cases.
All fields in an address are case sensitive.
The MediaType element identifies the type of media processed by an o The IP address of the interface that is used for sending messages
application. Currently defined values are: to the Mbus. For IPv4 this the address in decimal dotted
notation. For IPv6 the interface-ID-part of an address in textual
representation as specified in [3] MUST be used. In this
specification, this part is called the "host-ID".
audio An RTP audio stream o An identifier ("entity-ID") that is unique within the scope of
video An RTP video stream single host-ID. The entity comprises two parts. For systems where
whiteboard A shared whiteboard the concept of a process ID is applicable it is RECOMMENDED this
editor A shared text editor identifier be composed using a process-ID and a per-process
sap A session announcement tool, using SAP disambiguator for different Mbus entities of a process. If a
sip A session invitation tool, using SIP process ID is not available, this part of the entity-ID may be
h323 An ITU-T H.323 conference controller randomly chosen (it is recommended that at least a 32 bit random
rtsp An RTSP session controller number is chosen). Both numbers are represented in decimal
control A local coordination entity textual form and MUST be separated by a '-' character.
Other values are likely to be defined at a later date. Note that the entity-ID cannot be the port number of the endpoint
used for sending messages to the Mbus because implementations MAY
use the common Mbus port number for sending to and receiving from
the multicast group (as specified in Section 6). The total
identifier has the following structure:
The ModuleType element defines a logical part of an application. The id-element = "id:" id-value
value `ui' denotes the user-interface of an application, and the id-value = entity-id "@" host-id
value `engine' defines a media/protocol engine, and `transcoder' entity-id = 1*10DIGIT "-" 1*5DIGIT
defines a media transcoder. Other values may be defined in future. host-id = (IPv4address / IPv6address)
The AppName element identifies the application being used (e.g.: rat, Please refer to [3] for productions of IPv4address and IPv6address.
vic, etc.).
The AppInstance element is used to distinguish several instances of An example for an id element:
the same application. This is a per-instance-unique identifier, which
is not necessarily an integer. Many Unix applications will use the
process-id (PID) number, although this is not a requirement. Note
that if an end system is spread across several hosts, the AppInstance
MUST NOT be the process-id, unless e.g.. the host name or its IP
address are included as well. The companion draft "The Message Bus:
Messages and Procedures"[9] defines a bootstrap procedure ensuring
that entities can track the abandoning and restarting of application
instances as long as unique AppInstance values are being used.
The following examples illustrate how to make use of the addresses: id:4711-99@134.102.218.45
(audio ui rat 124) The user interface of the rat application with instance-id 124 A set of the address elements that are to be used by conferencing
(workspace ui * *) The user interfaces of all workspace applications applications is specified in "Mbus Addresses for Conferencing"
(audio * * *) All audio applications (Appendix A).
(* * rat *) All instances of the rat application
3.3. Reliability 5. 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, without the use of wildcards.[2] have to be specified. An entity can thus only send reliable messages
_________________________ to known addresses, i.e. it can only send reliable messages to
[2] Disallowing reliable message delivery for messages sent to entities that have announced their existence on the Mbus (e.g. by
multiple destinations is motivated by simplicity of the implemen- means of mbus.hello() messages (Section 8.1)). A sending entity MUST
tation as well as the protocol. Although ACK implosions are not NOT send a message reliably if the target address is not unique.
really an issue and losses are rare, achieving reliability for (See Transport (Section 6) for the specification of an algorithm to
such messages would require full knowledge of the membership for determine whether an address is unique.) A receiving entity MUST
only process and acknowledge reliable message if the destination
address exactly matches its own source address (the destination
address MUST NOT be a subset of the source address).
Disallowing reliable message delivery for messages sent to multi-
ple destinations is motivated by simplicity of the implementation as
well as the protocol. Although ACK implosions are not really an
issue and losses are rare, achieving reliability for such messages
would require full knowledge of the membership for each subgroup
which is deemed too much effort.
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 SHALL retransmit the not received within this interval, the sender SHOULD 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 SHALL be retransmitted a timeout, and restart the timer. Messages MUST be retransmitted a
small number of times before the recipient is considered to have small number of times (see below) before the recipient is considered
failed. If the message is not delivered successfully, the sending to have failed. If the message is not delivered successfully, the
application is notified. In this case, it is up to this application sending application is notified. In this case, it is up to this
to determine the specific action(s) (if any) to be taken. application to determine the specific action(s) (if any) to be
taken.
Reliable messages are acknowledged by adding their SeqNum to the Reliable messages are 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. Multiple acknowledgments MAY be sent in a single message.
It is possible to either piggy-back the AckList onto another message It is possible to either piggy-back the AckList onto another message
sent to the same destination, or to send a dedicated acknowledgment sent to the same destination, or to send a dedicated acknowledgment
message, with no other commands. message, with no other commands.
The precise procedures are as follows: The precise procedures are as follows:
Sender: Sender: A sender A of a reliable message M to receiver B SHOULD
A sender A of a reliable message M to receiver B SHALL transmit transmit the message via multicast or via unicast, keep a copy of
the message via multicast or via unicast, keep a copy of M, M, initialize a retransmission counter N to '1', and start a
initialize a retransmission counter N to '1', and start a retransmission timer T (initialized to T_r). If an acknowledgment
retransmission timer T (initialized to T_r). If an is received from B, timer T MUST BE cancelled and the copy of M
acknowledgment is received from B, timer T MUST BE cancelled and is discarded. If T expires, the message M SHOULD BE
the copy of M is discarded. If T expires, the message M SHALL retransmitted, the counter N SHOULD BE incremented by one, and
BE retransmitted, the counter N SHALL BE incremented by one, and the timer SHOULD BE restarted (set to N*T_r). If N exceeds the
the timer SHALL 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 failed, further retransmission attempts MUST NOT be undertaken,
have failed, further retransmission attempts MUST NOT be the copy of M SHOULD BE discarded, and the sending application
undertaken, the copy of M SHALL BE discarded, and the sending SHOULD BE notified.
application SHALL BE notified.
Receiver:
A receiver B of a reliable message from a sender A SHALL
acknowledge receipt of the message within a time period T_c<T_r.
This MAY be done by means of a dedicated acknowledgment message
or by piggy-backing the acknowledgment on another message
addressed only to A.
Receiver optimizing: gathering and piggy-backing ACKs Receiver: A receiver B of a reliable message from a sender A SHOULD
In a simple implementation, B may choose to immediately send a acknowledge receipt of the message within a time period T_c <
dedicated acknowledgment message. However, for efficiency, it T_r. This MAY be done by means of a dedicated acknowledgment
could add the SeqNum of the received message to a sender- message or by piggy-backing the acknowledgment on another message
specific list of acknowledgments; if the added SeqNum is the addressed only to A.
first acknowledgment in the list, B shall start an
acknowledgment timer TA (initialized to T_c). When the timer
expires, B shall create a dedicated acknowledgment message and
send it to A. If B is to transmit another Mbus message
_________________________
each subgroup which is deemed too much effort.
addressed only to A, it should piggy-back the acknowledgments Receiver optimization: In a simple implementation, B may choose to
onto this message and cancel TA. In either case, B should store immediately send a dedicated acknowledgment message. However,
a copy of the acknowledgment list as a single entry in the per- for efficiency, it could add the SeqNum of the received message
sender copy list, keep this entry for a period T_k, and empty to a sender-specific list of acknowledgments; if the added SeqNum
the acknowledgment list. In case any of the messages kept in an is the first acknowledgment in the list, B SHOULD start an
entry of the copy list is received again from A, the entire acknowledgment timer TA (initialized to T_c). When the timer
acknowledgment list stored in this entry is scheduled for expires, B SHOULD create a dedicated acknowledgment message and
(re-)transmission following the above rules. send it to A. If B is to transmit another Mbus message addressed
only to A, it should piggy-back the acknowledgments onto this
message and cancel TA. In either case, B should store a copy of
the acknowledgment list as a single entry in the per- sender copy
list, keep this entry for a period T_k, and empty the
acknowledgment list. In case any of the messages kept in an
entry of the copy list is received again from A, the entire
acknowledgment list stored in this entry is scheduled for
(re-)transmission following the above rules.
Constants: Constants:
Suggested values are T_r=100ms, N_r=3, T_c=70ms,
T_k=((N_r)*(N_r+1)/2)*T_r.
3.4. Transport Suggested values are T_r=100ms, N_r=3, T_c=70ms,
T_k=((N_r)*(N_r+1)/2)*T_r.
All messages are transmitted as UDP messages with two ways of sending 6. Transport
messages being possible:
1) local multicast (host-local or link-local, see Appendix ``Mbus All messages are transmitted as UDP messages with two ways of
configuration'') to a fixed, yet to be assigned link-local sending messages being possible:
address of the administratively scoped multicast space as
described in RFC 2365 [8]. There is a base port for each
presence conducting conferences using the Mbus. This port SHALL
be used for communication between application entities not
associated with a particular conference. For each conference
that a person participates in, a dedicated port is used for
conference-specific communication. Messages of interest for all
conferences a presence is involved in SHALL be sent to the base
port. Messages intended for a specific conference (i.e.
messages relating to an appearance only) SHALL be sent to the
port of the respective conference. Message intended for several
but not all conferences SHALL be sent individually to the
specific ports of these conference (one by one). The concrete
port numbers are taken from a reserved set of ports from a
defined PORTBASE to PORTBASE+#ports. Appendix B (Port
Allocation) defines procedures for port allocation.
2) Directed unicast via UDP to the port of a specific application. 1. Local multicast (host-local or link-local, see Mbus
This still requires the DestAddr field to be filled in properly. configuration (Section 11)) to a fixed, yet to be assigned (see
Directed unicast is intended for use in situations where node Section 13) link-local address of the administratively scoped
local multicast is not available. It MAY also be used by Mbus multicast space as described in RFC 2365[10]. There will also be
implementations for delivering messages addressed at a single a fixed, registered port number that all Mbus entities MUST use.
application entity only -- the address of which the Mbus Until the address and port numer are assigned, 224.255.222.239
implementation has learned from other message exchanges before. is used as the multicast address and 47000 (decimal) as the port
number.
If a single multimedia conferencing endpoint is distributed across 2. Directed unicast (via UDP) to the port of a specific
several co-located hosts, link local scope SHALL be used for application. This still requires the DestAddr field to be filled
multicasting Mbus messages that potentially have recipients on the in properly. Directed unicast is intended for situations where
other hosts. The Mbus protocol is not intended (and hence node local multicast is not available. It MAY also be used by
deliberately not defined) for communication between hosts not on the Mbus implementations for delivering messages addressed at a
same link. single application entity only -- the address of which the Mbus
implementation has learned from other message exchanges before.
Every Mbus entity SHOULD use a unique endpoint address for every
message it sends to the Mbus multicast group or to individual
receiving entities. A unique endpoint address is a tuple
consisting of the entity's IP address and a port number, where
the port number is different from the standard Mbus port number
(yet to be assigned, see Section 13). When multicast is
available, messages MUST only be sent via unicast if the Mbus
target address is unique and if the sending entity can verify
that the receiving entity uses a unique endpoint address. The
latter can be verified by considering the last message received
from that entity. (Note that several Mbus entities, say within
the same process, may share a common transport address; in this
case, the contents of the destination address field is used to
further dispatch the message. Given the definition of "unique
endpoint address" above the use of a shared endpoint address and
a dispatcher still allows other Mbus entities to send unicast
messages to one of the entities that share the endpoint address.
So this can be considered an implementation detail.) When
multicast is not available messages can be sent via unicast but
all messages that do not contain a unique target address MUST be
sent to all known entities via unicast. Messages with an empty
target address list MUST always be sent to all Mbus entities
(via multicast if available).
The following algorithm can be used by sending entities to
determine whether a Mbus address is unique considering the
current set of Mbus entities:
Since messages are transmitted in UDP datagrams, a maximum size of 64 let ta=the target address;
KBytes MUST NOT be exceeded. It is RECOMMENDED that applications iterate through the set of all
currently known Mbus addresses {
let ti=the address in each iteration;
count the addresses for which
the predicate isSubsetOf(ta,ti) yields true;
}
If the count of matching addresses is exactly 1 the address
is unique. The following algorithm can be used for the
predicate isSubsetOf, that checks whether the second message
matches the first according to the rules specified in Section
4. (A match means that a receiving entity that uses the
second Mbus address must also process received messages with
the first address as a target address.
isSubsetOf(addr a1,a2) yields true, iff
every address element of a1 is contained
in a2's address element list
An address element is contained in an address element list if
the list contains an element that provides same values for
the two address element fields key and value.
If a single application system is distributed across several
co-located hosts, link local scope SHOULD be used for multicasting
Mbus messages that potentially have recipients on the other hosts.
The Mbus protocol is not intended (and hence deliberately not
designed) for communication between hosts not on the same link.
Since messages are transmitted in UDP datagrams, a maximum size of
64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications
using a non host-local scope do not exceed a message size of the using a non host-local scope do not exceed a message size of the
network's MTU. network's MTU.
3.5. Message Syntax 7. Message Syntax
3.5.1. Message Encoding 7.1 Message Encoding
All messages SHALL 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 defined Each Message MAY be encrypted using a secret key algorithm as
in appendix A (Algorithms). defined in Section 10.
3.5.2. Message Header 7.2 Message Header
A message starts with the header. The first field in the header is A message starts with the header. The first field in the header is
the message digest calculated using a keyed hash algorithm as the message digest calculated using a keyed hash algorithm as
described in appendix A followed by a newline character. The other described in Section 10 followed by a newline character. The other
fields in the header are separated by white space characters, and fields in the header are separated by white space characters, and
followed by a newline. The format of the header is as follows: followed by a newline. The format of the header is as follows:
<MsgDigest> msg_header = MsgDigest LF "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP
mbus/1.0 <SeqNum> <TimeStamp> <MessageType> <SrcAddr> <DestAddr> \ MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList
<AckList>
The header fields are defined in section 3.1. The header fields are explained in Message Format (Section 3). Here
are the ABNF syntax definitions for the header fields:
3.5.3. Command Syntax MsgDigest = base64
SeqNum = 1*DIGIT
TimeStamp = 1*DIGIT
MessageType = "R" / "U"
ScrAddr = mbus_address
DestAddr = mbus_address
AckList = "(" *(1*DIGIT)) ")"
The header is followed by zero, or more, messages to be delivered to The syntax definition of a complete message is as follows:
mbus_message = msg_header LF msg_payload
msg_payload = mbus_command *(LF mbus_command)
See Figure 19 for the definition a Mbus command.
7.3 Command Syntax
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
The command name MUST be a `symbol' as defined in the following following table. The parameters MAY be any data type drawn from the
table. The parameters MAY be any data type drawn from the following following table:
table:
+---------+--------------------+---------------------------------+ +---------+-------------------------+--------------------------------+
|DataType | Syntax | Description | |DataType | Syntax | Description |
+---------+--------------------+---------------------------------+ +---------+-------------------------+--------------------------------+
|Integer | "-"[0-9]+ | | |val | (Integer / Float / | |
|Float | "-"[0-9]+"."[0-9]+ | | | | String / List Symbol | a value can be of one of |
|String | """...""" | See below for escape characters | | | Data) | these types |
| | | | | | | |
|List | (DataType DataType | | |Integer | "-" 1*DIGIT | |
| | ...) | | |Float | "-" 1*DIGIT "." 1*DIGIT | |
|Symbol | [A-Za-z0-9_-.]+ | A predefined protocol value | |String | DQUOTE *CHAR DQUOTE | See below for escape characters|
|Data | "<"data">" | Opaque Data | | | | |
+---------+--------------------+---------------------------------+ |List | "(" *(val | |
| | *(WSP val)) ")" | |
| | | |
|Symbol | ALPHA *(ALPHA / DIGIT / | A predefined protocol value |
| | "_" / "-" / ".") | |
| | | |
|Data | "<" *base64 ">" | Opaque Data |
+---------+-------------------------+--------------------------------+
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 (as in the `C' representing false, and non-zero representing true (as in the `C'
programming language). programming language).
String parameters in the payload MUST be enclosed in the double quote String parameters in the payload MUST be enclosed in the double
('') character. Within strings, the escape character is the backslash quote ('') character. Within strings, the escape character is the
(\), and the following escape sequences are defined: backslash (\), and the following escape sequences are defined:
Opaque data is represented as Base64-encoded [3] character strings +----------------+-----------+
surrounded by "<" and ">" |Escape Sequence | Meaning |
+----------------+-----------+
| \\ | \ |
| \" | " |
| \n | newline |
+----------------+-----------+
+----------------+-----------+ List parameters do not have to be homogeneous lists, i.e. they can
|Escape Sequence | Meaning | contain parameters of varying types.
+----------------+-----------+
| \\ | \ |
| \'' | '' |
| \n | <newline> |
+----------------+-----------+
3.6. Messages Opaque data is represented as Base64-encoded (see RFC1521[5])
character strings surrounded by "< " and "> "
The specific messages applications will send using the Mbus are not The ABNF syntax definition for Mbus commands is as follows:
defined in this document. Currently a companion document[9] is
produced defining classes of messages which are of use in certain
application areas. Additional documents are expected to follow.
4. Author's Addresses mbus_command = command_name arglist
command_name = ALPHA *(ALPHA / DIGIT / "_" / ".")
arglist = "(" *(*WSP parameter *WSP) ")"
parameter = Integer / Float / String / List
Symbol / Data
l. Joerg Ott <jo@tzi.org> Universitaet Bremen, TZI, MZH 5180 Command names SHOULD be constructed using hierarchical names to
Bibliothekstr. 1 D-28359 Bremen Germany voice +49 421 201-7028 fax group conceptually related commands under a common hierarchy. The
+49 421 218-7000 delimiter between names in the hierarchy is "." (dot).
l. Colin Perkins <c.perkins@cs.ucl.ac.uk> Department of Computer The Mbus addressing scheme defined in Addressing (Section 4)
Science University College London Gower Street London WC1E 6BT United provides for specifying incomplete addresses by omitting certain
Kingdom elements of an address element list, enabling entities to send
l. Dirk Kutscher <dku@tzi.org> Universitaet Bremen, TZI, MZH 5160 commands to a group of Mbus entities. Therefore all command names
Bibliothekstr. 1 D-28359 Bremen Germany voice +49 421 218-7595 fax SHOULD be unambiguous in a way that it is possible to interpret or
+49 421 218-7000 ignore them without considering the message's address.
5. References A set of commands within a certain hierarchy that must be understood
by every entity is defined in Messages (Section 8).
[1] S. Bradner, ``Key words for use in RFCs to Indicate Requirement 8. Messages
Levels'' RFC 2119, March 1997
[2] H. Krawczyk, M. Bellare, R. Canetti, ``HMAC: Keyed-Hashing for The section defines some basic application independent messages that
Message Authentication'', RFC 2104, February 1997 MUST be understood by all implementations. This specification does
not contain application specific messages which are to be defined
outside of the basic Mbus protocol specification.
[3] N. Borenstein, N. Freed ``MIME (Multipurpose Internet Mail Before components of a distributed system can communicate with one
Extensions) Part One: Mechanisms for Specifying and Describing another using the Mbus, they need to mutually find out about their
the Format of Internet Message Bodies'', RFC 1521, September existence. After this bootstrap procedure that each Mbus entity
1993 goes through all other entities listening to the same Mbus know
about the newcomer and the newcomer has learned about all the other
entities. Furthermore entities need to be able to to notice the
failure (or leaving) of other entities.
[4] Mark Handley, Jon Crowcroft, Carsten Bormann, ``The Internet Any Mbus entity is supposed to announce its presence (on the Mbus)
Multimedia Conferencing Architecture,'' Internet Draft draft- after starting up. This is to be done repeatedly throughout its
ietf-mmusic-confarch-00.txt, Work in Progress, February 1996. lifetime to address the issues of startup sequence: Entities should
always become aware of other entities independent of the order of
starting.
[5] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, ``RTP: A Any Mbus entity should frequently indicate that it is still alive.
Transport Protocol for Real-Time Applications,'' RFC 1889, This mechanism may be combined with the aforementioned
January 1996. self-announcement.
[6] Mark Handley, Henning Schulzrinne, Eve Schooler, Jonathan An Mbus entity should be able to indicate that it is waiting for a
Rosennberg, ``SIP: Session Initiation Protocol'', Internet Draft certain event to happen (similar to a P() operation on a semaphore
draft-ietf-mmusic-sip-07.txt, Work in Progress, July 16, 1998 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).
[7] M. Handley, V. Jacobson, ``SDP: Session Description Protocol'', An appropriate commend set to implement the aforementioned concepts
RFC 2327, April 1998 is presented in the following sections.
[8] D. Meyer ``Administratively Scoped IP Multicast'', RFC 2365, 8.1 mbus.hello
July 1998
[9] J. Ott, C. Perkins, and D. Kutscher, ``The Message Bus: Messages Syntax:
and Procedures'', Internet Draft draft-ietf-mmusic-mbus- mbus.hello()
semantics-00.txt, Work in Progress, August 1998.
Appendix A: Algorithms Parameters: - none -
Message Authentication Each Mbus entity MUST send HELLO messages after startup to the
Either MD5 or SHA-1 SHALL be used for message authentication global Mbus channel. After transmission of the HELLO message, it
codes (MACs). An implementation MAY provide SHA-1, whereas MD5 shall start a timer after the expiration of which the next HELLO
MUST be implemented. To generate keyed hash values the algorithm message shall be transmitted. The timer shall be set to a random
described in [2] MUST be applied with hash values truncated to value t_hello <= t <= t_hello + t_dither to avoid synchronization of
80 bits. The resulting hash values SHALL be Base64 encoded (16 HELLO messages. Transmission of HELLO messages MUST NOT be stopped
characters). The HMAC algorithm works with both, MD5 and SHA-1. unless the entity detaches from the Mbus. Section 9 defines
concrete values for those parameters.
HMAC values, regardless of the algorithm, MUST therefore always HELLO messages MUST be sent unreliably to all Mbus entities.
consist of 16 Base64-encoded characters.
Hash keys SHALL have a length of 96 bit, that are 20 Each Mbus entity learns about other Mbus entities by observing their
Base64-encoded characters. HELLO messages and tracking the sender address of each message.
Encryption The HELLO message is also used to track the liveness of any Mbus
Either DES, 3DES (triple DES) or IDEA SHALL be used for entity. Whenever an Mbus entity has not heard for a time span of
encryption. Encryption MAY be neglected for applications, e.g. n_dead*(t_hello+t_dither) from another Mbus entity it may consider
in situations where license regulations, export or encryption this entity to have failed (or have quit silently). Note that no
laws would be offended otherwise. However, the implementation of need for any action is necessarily implied from this observation.
DES is RECOMMENDED as a baseline. DES implementations MUST use
the DES electronic codebook (ECB) mode. Chaining modes are not
appropriate due to (possible) unreliable message transport. For
algorithms requiring en/decryption data to be padded to certain
boundaries ASCII code 32 SHALL be used for padding characters.
IDEA uses 128-bit keys (24 Base64-encoded characters). DES SHALL
be used with 56-bit keys (12 Base64-encoded characters).
The mandatory subset of algorithms that MUST be provided by 8.2 mbus.bye
implementation is DES and MD5.
See appendix C for a specification of notations for Base64-strings. Syntax:
Appendix B: Port allocation Parameters: - none -
The reserved Mbus port numbers are in the range from PORTBASE to An Mbus entity that is about to terminate (or "detach" from the
PORTBASE+(n*(m+1)) (n=number of base ports, m=reasonable maximum Mbus) SHOULD announce this by transmitting a BYE message.
number of conferences per presence). The first n ports are reserved
for base ports. The set of conference specific ports starts at offset
n and has a cardinality of n*m.
Implementations SHALL use the presence-id (see below) to calculate a The BYE message MUST be sent unreliably to all receivers.
valid offset to the set of base port numbers for a person's presence.
Offsets to conference specific port numbers SHALL be obtained by
using the conference name. The conference name is a SDP session
name[7] and MUST be known in advance of port allocation.
Base port number calculation SHALL rely on the following algorithm: 8.3 mbus.quit
All UTF-8 octets of the session name are considered for building a
sum of their key codes. The offset to the base port number is the
result of the modulo division of the sum by n (number of base ports).
Offsets for per-conference port numbers SHALL be calculated Syntax:
analogously: The key codes of the presence-id's characters are summed mbus.quit()
up and the the offset is obtained by adding the result of modulo
dividing the sum by m (number of conference ports per presence). The
actual port number is obtained by adding the result to
PORTBASE+(n*(baseport offset+1)).
Example: Parameters: - none -
PORTBASE = 2000 The QUIT message is used to request other entities to terminate
nr of base ports n= 10 themselves (and detach from the Mbus). Whether this request is
nr of conference ports m= 6 honoured by receiving entities or not is up to the discretion of the
application.
session name= abc The QUIT message can be multicast or sent reliably via unicast to a
presence-id= a@b.org single Mbus entity or a group of entities.
baseport offset= (97+98+99) % 10 8.4 mbus.waiting
= 4
baseport = PORTBASE + 4
= 2004
conference port offset= (97+64+99+46+111+114+103) % 6 Syntax:
= 4 mbus.waiting(condition)
conference port= PORTBASE + (6* (baseport offset+1))
+ conference port offset
= 2034
Appendix C: Mbus configuration Parameters:
symbol condition
The condition parameter is used to indicate that the entity
transmitting this message is waiting for a particular event to
occur.
The WAITING messages may be broadcast to all Mbus entities,
multicast an arbitrary subgroup, or unicast to a particular peer.
Transmission of the WAITING message MUST be unreliable and hence has
to be repeated at an application-defined interval (until the
condition is satisfied).
If an application wants to indicate that it is waiting for several
conditions to be met, several WAITING messages are sent (possibly
included in the same Mbus payload). Note that HELLO and WAITING
messages may also be transmitted in a single Mbus payload.
8.5 mbus.go
Syntax:
mbus.go(condition)
Parameters:
symbol condition
This parameter specifies which condition is met.
The GO message is sent by an Mbus entity to "unblock" another Mbus
entity -- the latter of which has indicated that it is waiting for a
certain condition to be met. Only a single condition can be
specified per GO message. If several conditions are satisfied
simultaneously multiple GO messages MAY be combined in a single Mbus
payload.
The GO message MUST be sent reliably via unicast to the Mbus entity
to unblock.
9. Timer and Counters
The following values for timers and counters mentioned in this
document SHOULD be used by implementations:
+----------------+------------------+
|Timer / Counter | Value |
+----------------+------------------+
|t_hello | 1 second |
|t_dither | 100 milliseconds |
|n_dead | 5 |
+----------------+------------------+
As the Mbus is designed for a local system architecture it is not
considered necessary to provide dynamic adaptation of these timers
and counters to the number of Mbus entities.
10. Mbus Security
10.1 Security Model
In order to prevent accidental or malicious disturbance of Mbus
communications through messages originated by applications from
other users message authentication is deployed (Section 10.2). For
each message a digest is calculated based on the value of a shared
secret key value. Receivers of messages can check if the sender
belongs to the same Mbus security domain by re-calculating the
digest and comparing it to the received value. Only if both values
are equal the messages must be processed further. In order to allow
different simultaneous Mbus sessions at a given scope and to
compensate defective implementations of host local multicast ([18])
message authentication MUST be provided by conforming
implementations.
Privacy of Mbus message transport can be achieved by optionally
using symmetric encryption methods (Section 10.3). Each message can
be encrypted using an additional shared secret key and a symmetric
encryption algorithm. Encryption is OPTIONAL for applications, i.e.
it is allowed to configure an Mbus domain not to use encryption. But
conforming implementations MUST provide the possibility to use
message encryption (see below).
Message authentication and encryption can be parameterized by
certain values, e.g. by the algorithms to apply or by the keys to
use. These parameters (amongst others) are defined in an Mbus
configuration entity that is accessible to all Mbus entities that
participate in an Mbus session. In order to achieve interoperability
conforming implementations SHOULD consider the given Mbus
configuration entity. Section 11 defines the mandatory and optional
parameters as well as storage procedures for different platforms.
Only in cases where none of the options for configuration entities
mentioned in Section 11 is applicable alternative methods of
configuring Mbus protocol entities MAY be deployed.
10.2 Message Authentication
Either MD5 [14] or SHA-1 [15] SHOULD be used for message
authentication codes (MACs). An implementation MAY provide SHA-1,
whereas MD5 MUST be implemented. To generate keyed hash values the
algorithm described in RFC2104[4] MUST be applied with hash values
truncated to 96 bits (12 bytes). The resulting hash values MUST be
Base64 encoded (16 characters). The HMAC algorithm works with both,
MD5 and SHA-1.
HMAC values, regardless of the algorithm, MUST therefore always
consist of 16 Base64-encoded characters.
Hash keys MUST have a length of 96 bit (12 bytes), that are 16
Base64-encoded characters.
10.3 Encryption
Either DES, 3DES (triple DES) or IDEA SHOULD be used for encryption.
Encryption MAY be neglected for applications, e.g. in situations
where license regulations, export or encryption laws would be
offended otherwise. However, the implementation of DES is
RECOMMENDED as a baseline. DES implementations MUST use the DES
Cipher Block Chaining (CBC) mode. For algorithms requiring
en/decryption data to be padded to certain boundaries octets with a
value of 0 SHOULD be used for padding characters. The padding
characters MUST be appended after calculating the message digest
when encoding and MUST be erased before recalculating the message
digest when decoding. IDEA uses 128-bit keys (24 Base64-encoded
characters). DES keys (56 bits) MUST be encoded as 8 octets as
described in RFC1423[12], resulting in 12 Base64-encoded characters.
The mandatory subset of algorithms that MUST be provided by
implementations is DES and MD5.
See Section 11 for a specification of notations for Base64-strings.
11. Mbus Configuration
An implementation MUST be configurable by the following parameters: An implementation MUST be configurable by the following parameters:
Encryption key The secret key used for message encryption. Configuration version
Hash key The hash key used for message authentication.
Presence ID The UCI of the person participating in a conference.
Scope The Internet scope to be used for sent messages.
The logical structure of the specified parameters is as follows:[3] The version number of the given configuration entity. Version
numbers allow implementations to check if they can process the
entries of a given configuration entity. Version number are
integer values. The version number for the version specified
here is 1.
hashkey ::= algo-id expiration key Encryption key
secretkey ::= algo-id expiration key
presence ::= uci The secret key used for message encryption.
expiration ::= digits Hash key
algo-id ::= ``NOENCR'' | ``DES'' | ``3DES'' | ``IDEA'' | ``HMAC-MD5-80'' | ``HMAC-SHA1-80'' The hash key used for message authentication.
scope ::= ``HOSTLOCAL'' | ``LINKLOCAL'' Scope
key ::= base64string The Internet scope to be used for sent messages.
uci ::= alpha
A Base64-String consists of the characters defined in the Base64 The upper parameters are mandatory and MUST be present in every Mbus
char-set [3] including all eventual padding characters, i.e. the configuration entity.
length of Base64-string is always a multiple of 4.
_________________________ The following parameters are optional. When they are present they
[3] syntactical definitions follow below MUST be honoured but when they are not present implementations
SHOULD fall back to the predefined default values (as defined in
Transport (Section 6)):
Appendix D: Parameter storage Address
The non-standard multicast address to use for message
transport.
Port
The non-standard 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 SHALL be used and for Unix-like systems a configuration file SHOULD be used and for
Windows-95/98/NT systems a set of registry entries is defined. Windows-95/98/NT/2000 systems a set of registry entries is defined
that SHOULD be used.
File based parameter storage: The syntax of the values for the respective parameter entries
remains the same for both configuration facilities. The following
defines a set of ABNF (see RFC2234[13]) productions that are later
referenced for the definitions for the configuration file syntax and
registry entries:
The file name for a Mbus configuration file is ``.mbus'' in the algo-id = "NOENCR" / "DES" / "3DES" / "IDEA" /
user's home-directory which MAY be overridden by an environment "HMAC-MD5-96" / "HMAC-SHA1-96"
variable called MBUS. Implementations MUST ensure that this file has scope = "HOSTLOCAL" / "LINKLOCAL"
appropriate file permissions that prevent other users to read or key = base64string
write it. The file MUST exist before a conference is initiated. Its version_number = 1*10DIGIT
contents SHALL be UTF-8 encoded and SHALL be structured as follows: base64string = *(ALPHA / DIGIT / "+" / "/" / "=")
key_value = "(" algo-id "," key ")"
ipv4_addr = ipv4_octet 3*3("." ipv4_octet)
ipv4_octet = 1*3DIGIT
port = 1*5DIGIT
[MBUS] A key entry MUST be specified using this notation:
HASHKEY=<hashkey>
ENCRYPTIONKEY=<secretkey>
PRESENCE=<presence-id>
SCOPE=<scope-id>
A key entry MUST be in this notation: "("algo-id","base64string")"
``(''algo-id``,'' expiration``,''base64string``)'' algo-id is one of the character strings specified above. For
algo-id=``NOENCR'' the other fields are ignored. The de- limiting
commas MUST always be present though.
algo-id is one of the character strings specified above and A Base64 string consists of the characters defined in the Base64
expiration is a decimal number representing the date that the key char-set (see RFC1521[5]) including all eventual padding characters,
invalidates at, notated in seconds counting from 00:00:00, UTC, i.e. the length of Base64-string is always a multiple of 4.
January 1, 1970.
The presence-id is a universal communication identifier (UCI) for a The version_number parameter specifies a version number for the used
conference participant. This can be a canonical email address like configuration entity.
``dku@tzi.org''. In case the same UCI is actually used to represent
different presences, e.g. to express different affiliations of a
person or to let different person use a single-user end-system
concurrently, the presence-id MAY be constituted of a UCI and a
presence ``modifier'' like ``dku@tzi.org#0'', ``dku@tzi.org#1'' and
so on. Presence-ids MUST be in the US-ASCII subset of
ISO-10646/UTF-8.
An example Mbus-configuration file: 11.1 File based parameter storage
[MBUS] The file name for a Mbus configuration file is ".mbus" in the user's
HASHKEY=(HMAC-MD5-80,946080000,MTIzMTU2MTg5MTEyMQ==) home-directory. If an environment variable called MBUS is defined
ENCRYPTIONKEY=(DES,946080000,MTIzMTU2MQ==) implementations SHOULD interpret the value of this variable as a
PRESENCE=dku@tzi.org fully qualified file name that is to be used for the configuration
SCOPE=HOSTLOCAL file. Implementations MUST ensure that this file has appropriate
file permissions that prevent other users to read or write it. The
file MUST exist before a conference is initiated. Its contents MUST
be UTF-8 encoded and MUST be structured as follows:
Registry based parameter storage: mbus-file = mbus-topic LF *(entry LF)
mbus-topic = "[MBUS]"
entry = 1*(version_info / hashkey_info
/ encryptionkey_info / scope_info
/ port_info / address_info)
version_info = "CONFIG_VERSION=" version_number
hashkey_info = "HASHKEY=" key_value
encrkey_info = "ENCRYPTIONKEY=" key_value
scope_info = "SCOPE=" scope
port_info = "PORT=" port
address_info = "ADDRESS=" ipv4_addr
For systems lacking the concept of a user's home-directory as a place The following entries are defined: CONFIG_VERSION, HASHKEY,
for configuration files the suggested database for configuration ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.
settings (e.g. the Windows9x-, Windows NT-registry) SHALL be used.
The hierarchy for Mbus related registry entries is as follows:[4]
HKEY_CURRENT_USER\Software\Mbone Applications\Mbus The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory,
they MUST be present in every Mbus configuration file. The order of
entries is not significant.
The entries in this hierarchy section are An example Mbus configuration file:
[MBUS]
CONFIG_VERSION=1
HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy)
ENCRYPTIONKEY=(DES,MTIzMTU2MQ==)
SCOPE=HOSTLOCAL
ADDRESS=224.255.222.239
PORT=47000
11.2 Registry based parameter storage
For systems lacking the concept of a user's home-directory as a
place for configuration files the suggested database for
configuration settings (e.g. the Windows9x-, Windows NT-, Windows
2000-registry) SHOULD be used. The hierarchy for Mbus related
registry entries is as follows:
HKEY_CURRENT_USER\Software\Mbone Applications\Mbus
The entries in this hierarchy section are:
+---------------+--------+----------------+
|Name | Type | ABNF production|
+---------------+--------+----------------|
|CONFIG_VERSION | DWORD | version_number |
|HASHKEY | String | key_value |
|ENCRYPTIONKEY | String | key_value |
|SCOPE | String | scope |
|ADDRESS | String | ipv4_addr |
|PORT | DWORD | port |
+---------------+--------+----------------+
+--------------+--------+
|Name | Type |
+--------------+--------+
|HASHKEY | String |
|ENCRYPTIONKEY | String |
|PRESENCE | String |
|SCOPE | String |
+--------------+--------+
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.
_________________________ 12. Security Considerations
[4] complies with vat's registry hierarchy
The Mbus security mechanismns are specified in Section 10.1.
It should be noted that the Mbus transport specification defines a
mandatory baseline set of algorithms that have to be supported by
implementations. This baseline set does not neccessarily provide the
best security due to the cryptographic weaknesses of the individual
algorithms. For example, it has been stated in [4] that MD5 had been
shown to be vulnerable to collision search attacks (although this
was believed not to compromise the use of MD5 within HMAC
generation). However, SHA-1 is usually considered to be the
cryptographically stronger function ([16]).
Similar remarks can be made on the encryption functions. The base
specification requires DES, an algorithm that has shown to be
vulnerable to brute-force attacks ([16], [17]).
We do not consider the well-known weaknesses of the mentioned
algorithms a problem:
o The problem of receiving unauthenticated messages is considered
to be the main security threat for Mbus communication. We believe
that HMAC-MD5 is sufficiently secure as a baseline algorithm. For
application requiring special security concerning authentication
of messages there is the option of using implementations that
implement SHA-1.
o Encryption is optional anyway, i.e. users can decide to have
their implementations sending clear text Mbus messages. Given the
local nature of Mbus communication this is feasible for most use
cases. In case the base DES encryption is not considered
sufficient there is still the possibility to use implementations
that implement 3DES or IDEA.
However, application developers should be aware of incorrect IP
implementations that do not conform to RFC 1122[2] and do send
datagrams with TTL values of zero, resulting in Mbus messages sent
to the local network link although a user might have selected host
local scope in the Mbus configuration. In these cases the use of
encryption SHOULD be considered if privacy is desired.
13. IANA Considerations
The IANA is requested to assign a port number and a multicast
address. For the time being the tentative multicast address
224.255.222.239 and the port number 47000 (decimal) SHOULD be used.
References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[2] Braden, R., "Requirements for Internet Hosts -- Communication
Layers", RFC 1122, October 1989.
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[4] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[5] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, September
1993.
[6] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The
Internet Multimedia Conferencing Architecture", Internet Draft
draft-ietf-mmusic-confarch-02.txt, October 1999.
[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[8] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley, M. and V. Jacobsen, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[10] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
July 1998.
[11] Ott, J., Perkins, C. and D. Kutscher, "Requirements for Local
Conference Control", Internet Draft
draft-ietf-mmusic-mbus-req-00.txt, December 1999.
[12] Balenson, D., "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423,
February 1993.
[13] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
[15] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards
and Technology, "Secure Hash Standard", FIPS PUB 180-1, April
1995.
[16] Schneier, B., "Applied Cryptography", Edition 2, Publisher
John Wiley & Sons, Inc., 1996.
[17] distributed.net, "Project DES", WWW
http://www.distributed.net/des/, 1999.
[18] Microsoft, "BUG: Winsock Sends IP Packets with TTL 0", WWW
http://support.microsoft.com/support/kb/articles/Q138/2/68.asp, March 1999
.
Authors' Addresses
Joerg Ott
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.218-7028
Fax: +49.421.218-7000
EMail: jo@tzi.de
Colin Perkins
University College London
Gower Street
London WC1E 6BT
United Kingdom
EMail: c.perkins@cs.ucl.ac.uk
Dirk Kutscher
TZI, Universitaet Bremen
Bibliothekstr. 1
Bremen 28359
Germany
Phone: +49.421.218-7595
Fax: +49.421.218-7000
EMail: dku@tzi.de
Appendix A. Mbus Addresses for Conferencing
For conferencing application 5 address element keys are predefined:
conf conference identifier
media media type processed by application
module module type of Mbus entity in a application
app application name
The conf element is used to designate the name of a conference in
order to distinguish between entities that are present in more than
one conference. See Transport (Section 6) for further notes
concerning multiple presences using the Mbus.
The media element identifies the type of media processed by an
application. Currently defined values are:
audio An RTP audio stream
video An RTP video stream
workspace A shared workspace
whiteboard A shared whiteboard
editor A shared text editor
sap A session announcement tool, using SAP
sip A session invitation tool, using SIP
h323 An ITU-T H.323 conference controller
rtsp An RTSP session controller
control A local coordination entity
Other values are likely to be defined at a later date.
The module element defines a logical part of an application. The
value `ui' denotes the user-interface of an application, and the
value `engine' defines a media/protocol engine, and `transcoder'
defines a media transcoder. Other values may be defined in future.
The app element identifies the application being used (e.g.: rat,
vic, etc.).
The instance element is used to distinguish several instances of the
same application. This is a per-instance-unique identifier, which is
not necessarily an integer. Many Unix applications will use the
process-id (PID) number, although this is not a requirement. Note
that if an end system is spread across several hosts, the instance
MUST NOT be the process-id, unless e.g.. the host name or its IP
address are included as well. Section 8 defines a bootstrap
procedure ensuring that entities can track the abandoning and
restarting of application instances as long as unique instance
values are being used.
The following examples illustrate how to make use of the addresses:
+----------------------------+--------------------------------------+
|(conf:test media:audio | The user interface of |
|module:ui app:rat | the rat application with |
|id:4711-99@134.102.218.45) | the given id is taking |
| | part in conference test |
+----------------------------+--------------------------------------+
|(media:workspace module:ui) | The user interfaces of |
| | all workspace applications |
+----------------------------+--------------------------------------+
|(media:audio) | All audio applications |
+----------------------------+--------------------------------------+
|(app:rat) | All instances of the rat application |
+----------------------------+--------------------------------------+
|() | All entities |
+----------------------------+--------------------------------------+
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implmentation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC editor function is currently provided by the
Internet Society.
 End of changes. 161 change blocks. 
614 lines changed or deleted 818 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/