draft-ietf-mmusic-mbus-transport-01.txt   draft-ietf-mmusic-mbus-transport-02.txt 
Network Working Group Ott Network Working Group Ott
Internet-Draft TZI, Universitaet Bremen Internet-Draft TZI, Universitaet Bremen
Expires: July 3, 2000 Perkins Expires: January 12, 2001 Perkins
University College London USC Information Sciences Institute
Kutscher Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
January 3, 2000 July 14, 2000
A Message Bus for Local Coordination A Message Bus for Local Coordination
draft-ietf-mmusic-mbus-transport-01.txt draft-ietf-mmusic-mbus-transport-02.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.
skipping to change at page 1, line 34 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 3, 2000. This Internet-Draft will expire on January 12, 2001.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved. Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract Abstract
In a variety of conferencing scenarios, a local communication In a variety of conferencing scenarios, a local communication
channel is desirable for conference-related information exchange channel is desirable for conference-related information exchange
between co- located but otherwise independent application entities, between co- located but otherwise independent application entities,
skipping to change at page 3, line 7 skipping to change at page 3, line 7
documents. documents.
This document is intended for discussion in the Multiparty This document is intended for discussion in the Multiparty
Multimedia Session Control (MMUSIC) working group of the Internet Multimedia Session Control (MMUSIC) working group of the Internet
Engineering Task Force. Comments are solicited and should be Engineering Task Force. Comments are solicited and should be
addressed to the working group's mailing list at confctrl@isi.edu addressed to the working group's mailing list at confctrl@isi.edu
and/or the authors. and/or the authors.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Terminology for requirement specifications . . . . . . . . . 4 1.3 Terminology for requirement specifications . . . . . . . . . 5
2. General Outline . . . . . . . . . . . . . . . . . . . . . . 5 2. General Outline . . . . . . . . . . . . . . . . . . . . . . 6
3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 8
4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 10 4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 11
5. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 15 7. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 16
7.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 15 7.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 16
7.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 15 7.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 16
7.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 15 7.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 16
8. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. Awareness of other Entities . . . . . . . . . . . . . . . . 19
8.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1 Hello Message Transmission Interval . . . . . . . . . . . . 19
8.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1.1 Calculating the Interval for Hello Messages . . . . . . . . 20
8.3 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 21
8.4 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 19 8.1.3 Adjusting the Hello Message Interval when the Number of
8.5 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Entities increases . . . . . . . . . . . . . . . . . . . . . 21
9. Timer and Counters . . . . . . . . . . . . . . . . . . . . . 21 8.1.4 Adjusting the Hello Message Interval when the Number of
10. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 22 Entities decreases . . . . . . . . . . . . . . . . . . . . . 21
10.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 22 8.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 22
10.2 Message Authentication . . . . . . . . . . . . . . . . . . . 22 8.2 Calculating the Timeout for Hello Messages . . . . . . . . . 22
10.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 23 9. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 24 9.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.1 File based parameter storage . . . . . . . . . . . . . . . . 25 9.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 23
11.2 Registry based parameter storage . . . . . . . . . . . . . . 26 9.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 24
12. Security Considerations . . . . . . . . . . . . . . . . . . 28 9.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 24
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 9.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 26
A. Mbus Addresses for Conferencing . . . . . . . . . . . . . . 32 11. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement . . . . . . . . . . . . . . . . . . 34 11.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 27
11.2 Message Authentication . . . . . . . . . . . . . . . . . . . 27
11.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 28
12. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 29
12.1 File based parameter storage . . . . . . . . . . . . . . . . 30
12.2 Registry based parameter storage . . . . . . . . . . . . . . 31
13. Security Considerations . . . . . . . . . . . . . . . . . . 33
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
References . . . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36
A. Mbus Addresses for Conferencing . . . . . . . . . . . . . . 37
Full Copyright Statement . . . . . . . . . . . . . . . . . . 39
1. Introduction 1. Introduction
1.1 Background 1.1 Background
The requirement specification as defined in the requirements The requirement specification as defined in the requirements
draft[11] provides a set of scenario descriptions for the usage of a draft[11] provides a set of scenario descriptions for the usage of a
local coordination infrastructure. The Message Bus defined in this local coordination infrastructure. The Message Bus defined in this
and a companion document provides a suitable means for local and a companion document provides a suitable means for local
communication that serves all of the purposes mentioned in the communication that serves all of the purposes mentioned in the
skipping to change at page 6, line 25 skipping to change at page 6, line 25
port number may match leading to reception of the other party's Mbus port number may match leading to reception of the other party's Mbus
messages in addition to a user's own ones. Malicious disturbance messages in addition to a user's own ones. Malicious disturbance
may happen because of applications multicasting (e.g. at a global may happen because of applications multicasting (e.g. at a global
scope) or unicasting Mbus messages (which could contain a scope) or unicasting Mbus messages (which could contain a
"conf.terminated" command). To eliminate the possibility of "conf.terminated" command). To eliminate the possibility of
receiving bogus Mbus messages, the Mbus protocol contains message receiving bogus Mbus messages, the Mbus protocol contains message
digests for authentication. Furthermore, the Mbus allows for digests for authentication. Furthermore, the Mbus allows for
encryption to ensure privacy and thus enable using the Mbus for encryption to ensure privacy and thus enable using the Mbus for
local key distribution and other functions potentially sensitive to local key distribution and other functions potentially sensitive to
eavesdropping. This document defines the framework for configuring eavesdropping. This document defines the framework for configuring
Mbus applications with regard to security parameters in Section 11. Mbus applications with regard to security parameters in Section 12.
3. 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:
The MsgDigest is a Base64-encoded (see RFC1521[5]) calculated The MsgDigest is a Base64-encoded (see RFC1521[5]) calculated
hash value of the entire message (starting from the ProtocolID hash value of the entire message (starting from the ProtocolID
field) as described in Section 10 and Section 11. field) as described in Section 11 and Section 12.
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).
A sequence number (SeqNum) is contained in each message. The A sequence number (SeqNum) is contained in each message. The
first message sent by a source SHOULD have SeqNum equal to zero, first message sent by a source SHOULD have SeqNum equal to zero,
and it MUST increment by one for each message sent by that 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. A single sequence number is used for all messages from a
source, irrespective of the intended recipients and the source, irrespective of the intended recipients and the
skipping to change at page 11, line 15 skipping to change at page 11, line 15
5. 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. 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 8.1)). A sending entity MUST means of mbus.hello() messages (Section 9.1)). A sending entity MUST
NOT send a message reliably if the target address is not unique. NOT send a message reliably if the target address is not unique.
(See Transport (Section 6) for the specification of an algorithm to (See Transport (Section 6) for the specification of an algorithm to
determine whether an address is unique.) A receiving entity MUST determine whether an address is unique.) A receiving entity MUST
only process and acknowledge reliable message if the destination only process and acknowledge a reliable message if the destination
address exactly matches its own source address (the destination address exactly matches its own source address (the 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. Although ACK implosions are not really an
issue and losses are rare, achieving reliability for such messages issue and losses are rare, achieving reliability for such messages
would require full knowledge of the membership for each subgroup would require full knowledge of the membership for each subgroup
which is deemed too much effort. which is deemed too much effort.
skipping to change at page 11, line 47 skipping to change at page 11, line 47
to have failed. If the message is not delivered successfully, the to have failed. If the message is not delivered successfully, the
sending application is notified. In this case, it is up to this sending application is notified. In this case, it is up to this
application to determine the specific action(s) (if any) to be application to determine the specific action(s) (if any) to be
taken. 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 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 SHOULD
transmit the message via multicast or via unicast, keep a copy of transmit the message via multicast or via unicast, keep a copy of
M, initialize a retransmission counter N to '1', and start a M, 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 acknowledgment
is received from B, timer T MUST BE cancelled and the copy of M is received from B, timer T MUST BE cancelled and the copy of M
is discarded. If T expires, the message M SHOULD BE is discarded. If T expires, the message M SHOULD BE
retransmitted, the counter N SHOULD BE incremented by one, and retransmitted, the counter N SHOULD BE incremented by one, and
skipping to change at page 12, line 37 skipping to change at page 12, line 37
send it to A. If B is to transmit another Mbus message addressed send it to A. If B is to transmit another Mbus message addressed
only to A, it should piggy-back the acknowledgments onto this only to A, it should piggy-back the acknowledgments onto this
message and cancel TA. In either case, B should store a copy of 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 the acknowledgment list as a single entry in the per- sender copy
list, keep this entry for a period T_k, and empty the list, keep this entry for a period T_k, and empty the
acknowledgment list. In case any of the messages kept in an acknowledgment list. In case any of the messages kept in an
entry of the copy list is received again from A, the entire entry of the copy list is received again from A, the entire
acknowledgment list stored in this entry is scheduled for acknowledgment list stored in this entry is scheduled for
(re-)transmission following the above rules. (re-)transmission following the above rules.
Constants: Constants and Algorithms: The following constants and algorithms
SHOULD be used by implementations:
Suggested values are T_r=100ms, N_r=3, T_c=70ms, T_r=100ms
T_k=((N_r)*(N_r+1)/2)*T_r.
N_r=3
T_c=70ms
T_k=((N_r)*(N_r+1)/2)*T_r
6. Transport 6. Transport
All messages are transmitted as UDP messages with two ways of All messages are transmitted as UDP messages with two ways of
sending messages being possible: sending messages being possible:
1. Local multicast (host-local or link-local, see Mbus 1. Local multicast (host-local or link-local, see Mbus
configuration (Section 11)) to a fixed, yet to be assigned (see configuration (Section 12)) to a fixed, yet to be assigned (see
Section 13) link-local address of the administratively scoped Section 14) link-local address of the administratively scoped
multicast space as described in RFC 2365[10]. There will also be multicast space as described in RFC 2365[10]. There will also be
a fixed, registered port number that all Mbus entities MUST use. a fixed, registered port number that all Mbus entities MUST use.
Until the address and port numer are assigned, 224.255.222.239 Until the address and port numer are assigned, 224.255.222.239
is used as the multicast address and 47000 (decimal) as the port is used as the multicast address and 47000 (decimal) as the port
number. number.
2. Directed unicast (via UDP) to the port of a specific 2. Directed unicast (via UDP) to the port of a specific
application. This still requires the DestAddr field to be filled application. This still requires the DestAddr field to be filled
in properly. Directed unicast is intended for situations where in properly. Directed unicast is intended for situations where
node local multicast is not available. It MAY also be used by node local multicast is not available. It MAY also be used by
Mbus implementations for delivering messages addressed at a Mbus implementations for delivering messages addressed at a
single application entity only -- the address of which the Mbus single application entity only -- the address of which the Mbus
implementation has learned from other message exchanges before. implementation has learned from other message exchanges before.
Every Mbus entity SHOULD use a unique endpoint address for every Every Mbus entity SHOULD use a unique endpoint address for every
message it sends to the Mbus multicast group or to individual message it sends to the Mbus multicast group or to individual
receiving entities. A unique endpoint address is a tuple receiving entities. A unique endpoint address is a tuple
consisting of the entity's IP address and a port number, where consisting of the entity's IP address and a port number, where
the port number is different from the standard Mbus port number the port number is different from the standard Mbus port number
(yet to be assigned, see Section 13). When multicast is (yet to be assigned, see Section 14). When multicast is
available, messages MUST only be sent via unicast if the Mbus available, messages MUST only be sent via unicast if the Mbus
target address is unique and if the sending entity can verify target address is unique and if the sending entity can verify
that the receiving entity uses a unique endpoint address. The that the receiving entity uses a unique endpoint address. The
latter can be verified by considering the last message received latter can be verified by considering the last message received
from that entity. (Note that several Mbus entities, say within from that entity. (Note that several Mbus entities, say within
the same process, may share a common transport address; in this the same process, may share a common transport address; in this
case, the contents of the destination address field is used to case, the contents of the destination address field is used to
further dispatch the message. Given the definition of "unique further dispatch the message. Given the definition of "unique
endpoint address" above the use of a shared endpoint address and endpoint address" above the use of a shared endpoint address and
a dispatcher still allows other Mbus entities to send unicast a dispatcher still allows other Mbus entities to send unicast
skipping to change at page 15, line 14 skipping to change at page 15, line 14
7. Message Syntax 7. Message Syntax
7.1 Message Encoding 7.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 10. defined in Section 11.
7.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 Section 10 followed by a newline character. The other described in Section 11 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:
msg_header = MsgDigest LF "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP msg_header = MsgDigest LF "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 3). 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:
MsgDigest = base64 MsgDigest = base64
SeqNum = 1*DIGIT SeqNum = 1*DIGIT
TimeStamp = 1*DIGIT TimeStamp = 1*DIGIT
MessageType = "R" / "U" MessageType = "R" / "U"
ScrAddr = mbus_address ScrAddr = mbus_address
DestAddr = mbus_address DestAddr = mbus_address
AckList = "(" *(1*DIGIT)) ")" AckList = "(" *(1*DIGIT)) ")"
The syntax definition of a complete message is as follows: The syntax definition of a complete message is as follows:
mbus_message = msg_header LF msg_payload mbus_message = msg_header *1(LF msg_payload)
msg_payload = mbus_command *(LF mbus_command) msg_payload = mbus_command *(LF mbus_command)
See Figure 19 for the definition a Mbus command. See Figure 18 for the definition a Mbus command.
7.3 Command Syntax 7.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
skipping to change at page 17, line 23 skipping to change at page 17, line 23
delimiter between names in the hierarchy is "." (dot). delimiter between names in the hierarchy is "." (dot).
The Mbus addressing scheme defined in Addressing (Section 4) The Mbus addressing scheme defined in Addressing (Section 4)
provides for specifying incomplete addresses by omitting certain provides for specifying incomplete addresses by omitting certain
elements of an address element list, enabling entities to send elements of an address element list, enabling entities to send
commands to a group of Mbus entities. Therefore all command names commands to a group of Mbus entities. Therefore all command names
SHOULD be unambiguous in a way that it is possible to interpret or SHOULD be unambiguous in a way that it is possible to interpret or
ignore them without considering the message's address. ignore them without 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 8). by every entity is defined in Messages (Section 9).
8. Messages 8. Awareness of other Entities
The section defines some basic application independent messages that Before Mbus entities can communicate with one another, they need to
MUST be understood by all implementations. This specification does mutually find out about their existence. After this bootstrap
not contain application specific messages which are to be defined procedure that each Mbus entity goes through all other entities
outside of the basic Mbus protocol specification. 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.
Before components of a distributed system can communicate with one Any Mbus entity MUST announce its presence (on the Mbus) after
another using the Mbus, they need to mutually find out about their starting up. This is to be done repeatedly throughout its lifetime
existence. After this bootstrap procedure that each Mbus entity to address the issues of startup sequence: Entities should always
goes through all other entities listening to the same Mbus know become aware of other entities independent of the order of starting.
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.
Any Mbus entity is supposed to announce its presence (on the Mbus) Each Mbus entity MUST maintain the number of Mbus session members
after starting up. This is to be done repeatedly throughout its and continously update this number according to any observed
lifetime to address the issues of startup sequence: Entities should changes. The mechanisms of how the existence and the leaving of
always become aware of other entities independent of the order of other entities can be detected are dedicated Mbus messages for
starting. entity awareness: mbus.hello (Section 9.1) and mbus.bye (Section
9.2). Each Mbus protocol implementation MUST periodically send
mbus.hello messages that are used by other entities to monitor the
existence of that entity. If an entity has not received mbus.hello
messages for a certain time (see Section 8.2) from an entity the
respective entity is considered to have left the Mbus and MUST be
excluded from the set of currently known entities. Upon the
reception of a mbus.bye messages the respective entity is considered
to have left the Mbus as well and MUST be excluded from the set of
currently known entities immediately.
Any Mbus entity should frequently indicate that it is still alive. Each Mbus entity MUST send hello messages after startup to the Mbus.
This mechanism may be combined with the aforementioned After transmission of the hello message, it shall start a timer
self-announcement. after the expiration of which the next hello message is to be
transmitted. Transmission of hello messages MUST NOT be stopped
unless the entity detaches from the Mbus. The interval for sending
hello messages is depending on the current number of entities in a
Mbus group and can thus change dynamically in order to avoid
congestion due to many entities sending hello messages at a constant
high rate.
Section 8.1 specifies the calculation of hello message intervals
that MUST be used by protocol implementations. Using the values that
are calculated for obtaining the current hello message timer, the
timeout for received hello messages is calculated in Section 8.2.
Section 9 specifies the command synopsis for the corresponding Mbus
messages.
8.1 Hello Message Transmission Interval
Since Mbus sessions may vary in size concerning the number of
entities care must be taken to allow the Mbus protocol to scale well
over different numbers of entities automatically. The average rate
at which hello messages are received would increase linearly to the
number of entities in a session if the sending interval was set to a
fixed value. Given a interval of 1 second this would mean that an
entity taking part in an Mbus session with n entities would receive
n hello messages per second. Assuming all entities resided on one
host this would lead to n*n messages that have to be processed per
second -- which is obviously not a viable solution for larger
groups. It is therefore necessary to deploy dynamically adapted
hello message intervals taking varying numbers of entities into
account. In the following we specify an algorithm that MUST be used
by implementations to calculate the interval for hello messages
considering the observed number of Mbus entities.
The algorithm features the following characteristics:
o The number of hello messages that are received by a single entity
in a certain time unit remains approximately constant as the
number of entities changes.
o The effective interval that is used by a specific Mbus entity is
randomized in order to avoid unintentional synchronization of
hello messages within a Mbus session. The first hello message of
an entity is also delayed by a certain random amount of time.
o A timer reconsideration mechanism is deployed in order to adapt
the interval more appropriately in situations where a rapid
change of the number of entities is observed. This is useful when
an entity joins an Mbus sessions and is still learning of the
existence of other entities or when a larger number of entities
leaves the Mbus at once.
8.1.1 Calculating the Interval for Hello Messages
The following names for values are used in the calculation specified
below (all time values in milliseconds):
hello_p: The last time a hello message has been sent by a Mbus
entity.
hello_now: The current time
hello_d: The deterministic calculated interval between hello
messages.
hello_e: The effective (randomized) interval between hello messages.
hello_n: The time for the next scheduled transmission of a hello
message.
entities_p: The numbers of entities at the time hello_n has been
last recomputed.
entities: The number of currently known entities.
The interval between hello messages MUST be calculated as follows:
The number of currently known entities is multiplied by
c_hello_factor, yielding the interval between hello messages in
milliseconds. This is the deterministic calculated interval,
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 8
provides a specification of how to obtain the number of currently
known entities. Section 10 provides values for the constants
c_hello_factor and c_hello_min.
The effective interval hello_e that is to be used by individual
entities is calculated by multiplying hello_d with a randomly chosen
number between c_hello_dither_min and c_hello_dither_max (see
Section 10).
hello_n, the time for the next hello message in milliseconds is set
to hello_e + hello_now.
8.1.2 Initialization of Values
Upon joining a session a protocol implementation sets hello_p,
hello_now to 0 and entities, entities_p to 1 (the current Mbus
entity itself) and then calculates the time for the next hello
message as specified in Section 8.1.1. The next hello message is
scheduled for transmission at hello_n.
8.1.3 Adjusting the Hello Message Interval when the Number of Entities
increases
When the existence of a new entity is observed by a protocol
implementation the number of currently known entities is updated. No
further action concerning the calculation of the hello message
interval is required. The reconsideration of the timer interval
takes place when the current timer for the next hello message
expires (see Section 8.1.5).
8.1.4 Adjusting the Hello Message Interval when the Number of Entities
decreases
Upon realizing that an entity has left the Mbus the number of
currently known entities is updated and the following algorithm
should be used to reconsider the timer interval for hello messages:
1. The value for hello_n is updated by setting hello_n to
hello_now + (entities/entities_p)*(hello_n - hello_now)
2. The value for hello_p is updated by setting hello_p to
hello_now - (entities/entities_p)*(hello_now - hello_p)
3. The currently active timer for the next hello messages is
cancelled and a new timer is started for hello_n.
4. entities_p is set to entities.
8.1.5 Expiration of hello timers
When the hello message timer expires, the protocol implementation
MUST perform the following operations:
The hello interval hello_e is computed as specified in Section
8.1.1.
If
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
is calculated again as specified in Section 8.1.1 and hello_n
is set to hello_e + hello_now.
2. else if hello_e + hello_p is greater than hello_now, hello_n
is set to hello_e + hello_p. A new timer for the next hello
message is started to expire at hello_n. No hello message is
transmitted.
entities_p is set to entities.
8.2 Calculating the Timeout for Hello Messages
Whenever an Mbus entity has not heard for a time span of
c_hello_dead*(hello_d*c_hello_dither_max) milliseconds from another
Mbus entity it may consider this entity to have failed (or have quit
silently). The number of the currently known entities MUST be
updated accordingly. Note that no need for any further action is
necessarily implied from this observation.
Section 8.1.1 specifies how to obtain hello_d. Section 10 defines
values for the constants c_hello_dead and c_hello_dither_max.
9. Messages
This section defines some basic application independent messages
that MUST be understood by all implementations. This specification
does not contain application specific messages which are to be
defined outside of the basic Mbus protocol specification.
An Mbus entity should be able to indicate that it is waiting for a 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 certain event to happen (similar to a P() operation on a semaphore
but without creating external state somewhere). In conjunction with but without creating external state somewhere). In conjunction with
this, an Mbus entity should be capable of indicating to another this, an Mbus entity should be capable of indicating to another
entity that this condition is now satisfied (similar to a entity that this condition is now satisfied (similar to a
semaphore's V() operation). semaphore's V() operation).
An appropriate commend set to implement the aforementioned concepts An appropriate commend set to implement the aforementioned concepts
is presented in the following sections. is presented in the following sections.
8.1 mbus.hello 9.1 mbus.hello
Syntax: Syntax:
mbus.hello() mbus.hello(parameters...)
Parameters: - none -
Each Mbus entity MUST send HELLO messages after startup to the Parameters: see below
global Mbus channel. After transmission of the HELLO message, it
shall start a timer after the expiration of which the next HELLO
message shall be transmitted. The timer shall be set to a random
value t_hello <= t <= t_hello + t_dither to avoid synchronization of
HELLO messages. Transmission of HELLO messages MUST NOT be stopped
unless the entity detaches from the Mbus. Section 9 defines
concrete values for those parameters.
HELLO messages MUST be sent unreliably to all Mbus entities. 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. HELLO messages and tracking the sender address of each message and
can thus calculate the current number of entities.
The HELLO message is also used to track the liveness of any Mbus HELLO messages MUST be sent periodically in dynamically calculated
entity. Whenever an Mbus entity has not heard for a time span of intervals as specified in Section 8.
n_dead*(t_hello+t_dither) from another Mbus entity it may consider
this entity to have failed (or have quit silently). Note that no
need for any action is necessarily implied from this observation.
8.2 mbus.bye Upon startup the first HELLO message MUST be sent after a delay
hello_delay, where hello_delay be a randomly chosen number between 0
and c_hello_min (see Section 10).
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 a BYE message.
The BYE message MUST be sent unreliably to all receivers. The BYE message MUST be sent unreliably to all receivers.
8.3 mbus.quit 9.3 mbus.ping
Syntax:
Parameters: - none -
mbus.ping can be used to solicit other entities to signal their
existence by replying with a mbus.hello message. Each protocol
implementation MUST understand mbus.ping and reply with a mbus.hello
message. The reply hello message MUST be delayed for hello_delay
milliseconds, where hello_delay be a randomly chosen number between
0 and c_hello_min (see Section 10).
As specified in Section 9.1 hello messages MUST be sent unreliably
to all Mbus entities. An entity that replies to mbus.ping with
mbus.hello should stop any outstanding timers for hello messages
after sending the hello message and schedule a new timer event for
the subsequent hello message. (Note that using the variables and the
algorithms of Section 8.1.1 this can be achieved by setting hello_p
to hello_now.)
mbus.ping allows a new entity to quickly check for other entities
without having to wait for the regular individual hello messages. By
specifying a target address the new entity can restrict the
solicitation for hello messages to a subset of entities it is
interested in.
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 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 up to the discretion of the
application. application.
The QUIT message can be multicast or sent reliably via unicast to a The QUIT message can be multicast or sent reliably via unicast to a
single Mbus entity or a group of entities. single Mbus entity or a group of entities.
8.4 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.
skipping to change at page 20, line 17 skipping to change at page 24, line 21
multicast an arbitrary subgroup, or unicast to a particular peer. multicast an arbitrary subgroup, or unicast to a particular peer.
Transmission of the WAITING message MUST be unreliable and hence has Transmission of the WAITING message MUST be unreliable and hence has
to be repeated at an application-defined interval (until the to be repeated at an application-defined interval (until the
condition is satisfied). 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 WAITING messages are sent (possibly
included in the same Mbus payload). Note that HELLO and WAITING included in the same Mbus payload). Note that HELLO and WAITING
messages may also be transmitted in a single Mbus payload. messages may also be transmitted in a single Mbus payload.
8.5 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 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 entity -- the latter of which has indicated that it is waiting for a
certain condition to be met. Only a single condition can be certain condition to be met. Only a single condition can be
specified per GO message. If several conditions are satisfied specified per GO message. If several conditions are satisfied
simultaneously multiple GO messages MAY be combined in a single Mbus simultaneously multiple 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 GO message MUST be sent reliably via unicast to the Mbus entity
to unblock. to unblock.
9. Timer and Counters 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 | |Timer / Counter | Value | Unit |
+----------------+------------------+ +-------------------+------------------------+--------------+
|t_hello | 1 second | |c_hello_factor | 200 | - |
|t_dither | 100 milliseconds | |c_hello_min | 1000 | milliseconds |
|n_dead | 5 | |c_hello_dither_min | 0.9 | - |
+----------------+------------------+ |c_hello_dither_max | 1.1 | - |
|c_hello_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 11. Mbus Security
10.1 Security Model 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 10.2). For other users message authentication is deployed (Section 11.2). 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. Only if both values
are equal the messages must be processed further. In order to allow are equal the messages must be processed further. In order to allow
different simultaneous Mbus sessions at a given scope and to different simultaneous Mbus sessions at a given scope and to
compensate defective implementations of host local multicast ([18]) compensate defective implementations of host local multicast ([18])
message authentication MUST be provided by conforming message authentication MUST be provided by conforming
implementations. 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 10.3). Each message can using symmetric encryption methods (Section 11.3). 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 entity that is accessible to 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 11 defines the mandatory and optional configuration entity. 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 11 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.
10.2 Message Authentication 11.2 Message Authentication
Either MD5 [14] or SHA-1 [15] SHOULD be used for message Either MD5 [14] or SHA-1 [15] SHOULD be used for message
authentication codes (MACs). An implementation MAY provide SHA-1, authentication codes (MACs). An implementation MAY provide SHA-1,
whereas MD5 MUST be implemented. To generate keyed hash values the whereas MD5 MUST be implemented. To generate keyed hash values the
algorithm described in RFC2104[4] MUST be applied with hash values algorithm described in RFC2104[4] MUST be applied with hash values
truncated to 96 bits (12 bytes). The resulting hash values MUST be truncated to 96 bits (12 bytes). The resulting hash values MUST be
Base64 encoded (16 characters). The HMAC algorithm works with both, Base64 encoded (16 characters). The HMAC algorithm works with both,
MD5 and SHA-1. MD5 and SHA-1.
HMAC values, regardless of the algorithm, MUST therefore always HMAC values, regardless of the algorithm, MUST therefore always
consist of 16 Base64-encoded characters. consist of 16 Base64-encoded characters.
Hash keys MUST have a length of 96 bit (12 bytes), that are 16 Hash keys MUST have a length of 96 bit (12 bytes), that are 16
Base64-encoded characters. Base64-encoded characters.
10.3 Encryption 11.3 Encryption
Either DES, 3DES (triple DES) or IDEA SHOULD be used for encryption. Either DES, 3DES (triple DES) or IDEA SHOULD be used for encryption.
Encryption MAY be neglected for applications, e.g. in situations Encryption MAY be neglected for applications, e.g. in situations
where license regulations, export or encryption laws would be where license regulations, export or encryption laws would be
offended otherwise. However, the implementation of DES is offended otherwise. However, the implementation of DES is
RECOMMENDED as a baseline. DES implementations MUST use the DES RECOMMENDED as a baseline. DES implementations MUST use the DES
Cipher Block Chaining (CBC) mode. For algorithms requiring Cipher Block Chaining (CBC) mode. For algorithms requiring
en/decryption data to be padded to certain boundaries octets with a en/decryption data to be padded to certain boundaries octets with a
value of 0 SHOULD be used for padding characters. The padding value of 0 SHOULD be used for padding characters. The padding
characters MUST be appended after calculating the message digest characters MUST be appended after calculating the message digest
when encoding and MUST be erased before recalculating the message when encoding and MUST be erased before recalculating the message
digest when decoding. IDEA uses 128-bit keys (24 Base64-encoded digest when decoding. IDEA uses 128-bit keys (24 Base64-encoded
characters). DES keys (56 bits) MUST be encoded as 8 octets as characters). DES keys (56 bits) MUST be encoded as 8 octets as
described in RFC1423[12], resulting in 12 Base64-encoded characters. described in RFC1423[12], resulting in 12 Base64-encoded characters.
The mandatory subset of algorithms that MUST be provided by The mandatory subset of algorithms that MUST be provided by
implementations is DES and MD5. implementations is DES and MD5.
See Section 11 for a specification of notations for Base64-strings. See Section 12 for a specification of notations for Base64-strings.
11. 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 25, line 33 skipping to change at page 29, line 33
algo-id=``NOENCR'' the other fields are ignored. The de- limiting algo-id=``NOENCR'' the other fields are ignored. The de- limiting
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[5]) including all eventual padding characters, char-set (see RFC1521[5]) including all eventual padding characters,
i.e. the length of Base64-string is always a multiple of 4. i.e. the length of Base64-string is always a multiple of 4.
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.
11.1 File based parameter storage 12.1 File based parameter storage
The file name for a Mbus configuration file is ".mbus" in the user's The file name for a Mbus configuration file is ".mbus" in the user's
home-directory. If an environment variable called MBUS is defined home-directory. If an environment variable called MBUS is defined
implementations SHOULD interpret the value of this variable as a implementations SHOULD interpret the value of this variable as a
fully qualified file name that is to be used for the configuration fully qualified file name that is to be used for the configuration
file. Implementations MUST ensure that this file has appropriate file. Implementations MUST ensure that this file has appropriate
file permissions that prevent other users to read or write it. The file permissions that prevent other users to read or write it. The
file MUST exist before a conference is initiated. Its contents MUST file MUST exist before a conference is initiated. Its contents MUST
be UTF-8 encoded and MUST be structured as follows: be UTF-8 encoded and MUST be structured as follows:
skipping to change at page 26, line 34 skipping to change at page 30, line 34
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
11.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\Mbone Applications\Mbus
The entries in this hierarchy section are: The entries in this hierarchy section are:
skipping to change at page 28, line 5 skipping to change at page 32, line 5
|HASHKEY | String | key_value | |HASHKEY | String | key_value |
|ENCRYPTIONKEY | String | key_value | |ENCRYPTIONKEY | String | key_value |
|SCOPE | String | scope | |SCOPE | String | scope |
|ADDRESS | String | ipv4_addr | |ADDRESS | String | ipv4_addr |
|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.
12. Security Considerations 13. Security Considerations
The Mbus security mechanismns are specified in Section 10.1. The Mbus security mechanismns 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 does not neccessarily provide the implementations. This baseline set does not neccessarily provide the
best security due to the cryptographic weaknesses of the individual best security due to the cryptographic weaknesses of the individual
algorithms. For example, it has been stated in [4] that MD5 had been algorithms. For example, it has been stated in [4] that MD5 had been
shown to be vulnerable to collision search attacks (although this shown to be vulnerable to collision search attacks (although this
was believed not to compromise the use of MD5 within HMAC was believed not to compromise the use of MD5 within HMAC
generation). However, SHA-1 is usually considered to be the generation). However, SHA-1 is usually considered to be the
cryptographically stronger function ([16]). cryptographically stronger function ([16]).
skipping to change at page 29, line 5 skipping to change at page 33, line 5
sufficient there is still the possibility to use implementations sufficient there is still the possibility to use implementations
that implement 3DES or IDEA. that implement 3DES or IDEA.
However, application developers should be aware of incorrect IP However, 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. In these cases the use of local scope in the Mbus configuration. In these cases the use of
encryption SHOULD be considered if privacy is desired. encryption SHOULD be considered if privacy is desired.
13. IANA Considerations 14. IANA Considerations
The IANA is requested to assign a port number and a multicast The IANA is requested to assign a port number and a multicast
address. For the time being the tentative multicast address address. For the time being the tentative multicast address
224.255.222.239 and the port number 47000 (decimal) SHOULD be used. 224.255.222.239 and the port number 47000 (decimal) SHOULD be used.
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.
skipping to change at page 31, line 27 skipping to change at page 35, line 27
. .
Authors' Addresses Authors' Addresses
Joerg Ott Joerg Ott
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.218-7028 Phone: +49.421.201-7028
Fax: +49.421.218-7000 Fax: +49.421.218-7000
EMail: jo@tzi.de EMail: jo@tzi.uni-bremen.de
Colin Perkins Colin Perkins
University College London USC Information Sciences Institute
Gower Street 4350 N. Fairfax Drive #620
London WC1E 6BT Arlington VA 22203
United Kingdom USA
EMail: c.perkins@cs.ucl.ac.uk EMail: csp@isi.edu
Dirk Kutscher Dirk Kutscher
TZI, Universitaet Bremen TZI, Universitaet Bremen
Bibliothekstr. 1 Bibliothekstr. 1
Bremen 28359 Bremen 28359
Germany Germany
Phone: +49.421.218-7595 Phone: +49.421.218-7595
Fax: +49.421.218-7000 Fax: +49.421.218-7000
EMail: dku@tzi.de EMail: dku@tzi.uni-bremen.de
Appendix A. Mbus Addresses for Conferencing Appendix A. Mbus Addresses for Conferencing
For conferencing application 5 address element keys are predefined: For conferencing application 5 address element keys are predefined
(in addition to the mandatory element key "id"):
conf conference identifier conf conference identifier
media media type processed by application media media type processed by application
module module type of Mbus entity in a application module module type of Mbus entity in a application
app application name app application name
The conf element is used to designate the name of a conference in The conf element is used to designate the name of a conference in
order to distinguish between entities that are present in more than order to distinguish between entities that are present in more than
one conference. See Transport (Section 6) for further notes one conference. See Transport (Section 6) for further notes
concerning multiple presences using the Mbus. concerning multiple presences using the Mbus.
skipping to change at page 32, line 49 skipping to change at page 36, line 50
The app element identifies the application being used (e.g.: rat, The app element identifies the application being used (e.g.: rat,
vic, etc.). vic, etc.).
The instance element is used to distinguish several instances of the The instance element is used to distinguish several instances of the
same application. This is a per-instance-unique identifier, which is same application. This is a per-instance-unique identifier, which is
not necessarily an integer. Many Unix applications will use the not necessarily an integer. Many Unix applications will use the
process-id (PID) number, although this is not a requirement. Note process-id (PID) number, although this is not a requirement. Note
that if an end system is spread across several hosts, the instance 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 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 address are included as well. Section 9 defines a bootstrap
procedure ensuring that entities can track the abandoning and procedure ensuring that entities can track the abandoning and
restarting of application instances as long as unique instance restarting of application instances as long as unique instance
values are being used. values are being used.
The following examples illustrate how to make use of the addresses: The following examples illustrate how to make use of the addresses:
+----------------------------+--------------------------------------+ +----------------------------+--------------------------------------+
|(conf:test media:audio | The user interface of | |(conf:test media:audio | The user interface of |
|module:ui app:rat | the rat application with | |module:ui app:rat | the rat application with |
|id:4711-99@134.102.218.45) | the given id is taking | |id:4711-99@134.102.218.45) | the given id is taking |
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/