draft-ietf-mmusic-mbus-transport-03.txt		draft-ietf-mmusic-mbus-transport-04.txt
	Network Working Group Ott		Network Working Group Ott
	Internet-Draft TZI, Universitaet Bremen		Internet-Draft TZI, Universitaet Bremen
	Expires: May 21, 2001 Perkins		Expires: August 8, 2001 Perkins
	USC Information Sciences Institute		USC Information Sciences Institute
	Kutscher		Kutscher
	TZI, Universitaet Bremen		TZI, Universitaet Bremen
	November 20, 2000		February 7, 2001
	A Message Bus for Local Coordination		A Message Bus for Local Coordination
	draft-ietf-mmusic-mbus-transport-03.txt		draft-ietf-mmusic-mbus-transport-04.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with		This document is an Internet-Draft and is in full conformance with
	all provisions of Section 10 of RFC2026.		all provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as		other groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of six		Internet-Drafts are draft documents valid for a maximum of six
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	To view the entire list of Internet-Draft Shadow Directories, see		To view the entire list of Internet-Draft Shadow Directories, see
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on May 21, 2001.		This Internet-Draft will expire on August 8, 2001.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	Abstract		Abstract
	The local Message Bus (Mbus) is a simple message-oriented		The local Message Bus (Mbus) is a simple message-oriented
	coordination infrastructure for group communication within groups of		coordination infrastructure for group communication within groups of
	co-located application entities. The Message Bus comprises three		co-located application entities. The Message Bus comprises three
	logically distinct parts: a message transport infrastructure, a		logically distinct parts: a message transport infrastructure, a
	structured message hierarchy, and a general purpose addressing		structured message hierarchy, and a general purpose addressing
	scheme. This document deals with message addressing, transport, and		scheme. This document specifies message addressing, transport, and
	security issues and defines the message syntax for the Mbus. It does		security procedures and defines the message syntax for the Mbus. It
	not define application oriented semantics and procedures for using		does not define application oriented semantics and procedures for
	the message bus. Application specific command sets and procedures		using the message bus.
	for applications using the Mbus are expected to be defined in
	follow-up documents.
	This document is a product of the Multiparty Multimedia Session		This document is a product of the Multiparty Multimedia Session
	Control (MMUSIC) working group of the Internet Engineering Task		Control (MMUSIC) working group of the Internet Engineering Task
	Force. Comments are solicited and should be addressed to the working		Force. Comments are solicited and should be addressed to the working
	group's mailing list at confctrl@isi.edu and/or the authors.		group's mailing list at confctrl@isi.edu and/or the authors.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Application Scenarios . . . . . . . . . . . . . . . . . . . 4		1.1 Application Scenarios . . . . . . . . . . . . . . . . . . . 4
	1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.3 Terminology for requirement specifications . . . . . . . . . 4		1.3 Terminology for requirement specifications . . . . . . . . . 4
	2. General Outline . . . . . . . . . . . . . . . . . . . . . . 6		2. General Outline . . . . . . . . . . . . . . . . . . . . . . 6
	3. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 8		3. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 8
	4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 10		4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 10
	5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 13		5.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 12
	6. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 14		6. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 13
	6.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 14		6.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 13
	6.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 14		6.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 13
	6.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 15		6.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 17		7. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 17		7.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 16
			7.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 17
			7.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 17
			7.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 18
			7.1.4 Mbus Port Number . . . . . . . . . . . . . . . . . . . . . . 18
	7.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 18		7.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 18
	8. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 20		8. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 21
	9. Awareness of other Entities . . . . . . . . . . . . . . . . 22		9. Awareness of other Entities . . . . . . . . . . . . . . . . 23
	9.1 Hello Message Transmission Interval . . . . . . . . . . . . 22		9.1 Hello Message Transmission Interval . . . . . . . . . . . . 23
	9.1.1 Calculating the Interval for Hello Messages . . . . . . . . 23		9.1.1 Calculating the Interval for Hello Messages . . . . . . . . 24
	9.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 24		9.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 25
	9.1.3 Adjusting the Hello Message Interval when the Number of		9.1.3 Adjusting the Hello Message Interval when the Number of
	Entities increases . . . . . . . . . . . . . . . . . . . . . 24		Entities increases . . . . . . . . . . . . . . . . . . . . . 25
	9.1.4 Adjusting the Hello Message Interval when the Number of		9.1.4 Adjusting the Hello Message Interval when the Number of
	Entities decreases . . . . . . . . . . . . . . . . . . . . . 24		Entities decreases . . . . . . . . . . . . . . . . . . . . . 25
	9.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 25		9.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 26
	9.2 Calculating the Timeout for Hello Messages . . . . . . . . . 25		9.2 Calculating the Timeout for Hello Messages . . . . . . . . . 26
	10. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 26		10. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 26		10.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 26		10.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 27
	10.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 27		10.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 28
	10.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 27		10.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 28
	10.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 27		10.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 28
	10.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 28		10.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 29
	11. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 29		11. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 30
	12. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 30		12. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 31
	12.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 30		12.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 31
	12.2 Message Authentication . . . . . . . . . . . . . . . . . . . 30		12.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 31
	12.3 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 31		12.3 Message Authentication . . . . . . . . . . . . . . . . . . . 32
	13. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 32		12.4 Procedures for Senders and Receivers . . . . . . . . . . . . 32
	13.1 File based parameter storage . . . . . . . . . . . . . . . . 34		13. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 34
	13.2 Registry based parameter storage . . . . . . . . . . . . . . 35		13.1 File based parameter storage . . . . . . . . . . . . . . . . 36
	14. Security Considerations . . . . . . . . . . . . . . . . . . 36		13.2 Registry based parameter storage . . . . . . . . . . . . . . 37
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37		14. Security Considerations . . . . . . . . . . . . . . . . . . 38
	References . . . . . . . . . . . . . . . . . . . . . . . . . 38		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39		References . . . . . . . . . . . . . . . . . . . . . . . . . 40
	Full Copyright Statement . . . . . . . . . . . . . . . . . . 41		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41
			A. About References . . . . . . . . . . . . . . . . . . . . . . 43
			B. Limitations and Future Work . . . . . . . . . . . . . . . . 44
			Full Copyright Statement . . . . . . . . . . . . . . . . . . 45
	1. Introduction		1. Introduction
	1.1 Application Scenarios		1.1 Application Scenarios
	The implementation of multiparty multimedia conferencing systems is		The implementation of multiparty multimedia conferencing systems is
	one example where a simple coordination infrastructure can be		one example where a simple coordination infrastructure can be
	useful: In a variety of conferencing scenarios, a local		useful: In a variety of conferencing scenarios, a local
	communication channel can provide conference-related information		communication channel can provide conference-related information
	exchange between co- located but otherwise independent application		exchange between co-located but otherwise independent application
	entities, for example those taking part in application sessions that		entities, for example those taking part in application sessions that
	belong to the same conference. In loosely coupled conferences such a		belong to the same conference. In loosely coupled conferences such a
	mechanism allows for coordination of applications entities to e.g.		mechanism allows for coordination of applications entities to e.g.
	implement synchronization between media streams or to configure		implement synchronization between media streams or to configure
	entities without user interaction. It can also be used to implement		entities without user interaction. It can also be used to implement
	tightly coupled conferences enabling a conference controller to		tightly coupled conferences enabling a conference controller to
	enforce conference wide control within a end system.		enforce conference wide control within an end system.
	1.2 Purpose		1.2 Purpose
	Three components constitute the message bus: the low level message		Three components constitute the message bus: the low level message
	passing mechanisms, a command syntax and naming hierarchy, and the		passing mechanisms, a command syntax and naming hierarchy, and the
	addressing scheme.		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
	lower level Mbus message passing mechanism which is common to all		lower level Mbus message passing mechanism which is common to all
	Mbus implementations. This includes the specification of		Mbus implementations. This includes the specification of
	skipping to change at page 8, line 7 ¶		skipping to change at page 8, line 7 ¶
	possibility of receiving unwanted Mbus messages, the Mbus protocol		possibility of receiving unwanted Mbus messages, the Mbus protocol
	contains message digests for authentication. Furthermore, the Mbus		contains message digests for authentication. Furthermore, the Mbus
	allows for encryption to ensure privacy and thus enable using the		allows for encryption to ensure privacy and thus enable using the
	Mbus for local key distribution and other functions potentially		Mbus for local key distribution and other functions potentially
	sensitive to eavesdropping. This document defines the framework for		sensitive to eavesdropping. This document defines the framework for
	configuring Mbus applications with regard to security parameters in		configuring Mbus applications with regard to security parameters in
	Section 13.		Section 13.
	3. Common Formal Syntax Rules		3. Common Formal Syntax Rules
	This section contains some definitions of common ABNF [14] syntax		This section contains some definitions of common ABNF [12] syntax
	elements that are later referenced by other definitions in this		elements that are later referenced by other definitions in this
	document:		document:
	base64 = base64_terminal /		base64 = base64_terminal /
	( 1*(4base64_CHAR) [base64_terminal] )		( 1*(4base64_CHAR) [base64_terminal] )
	base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"		base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/"
	;; Case-sensitive		;; Case-sensitive
	base64_terminal = (2base64_char "==") / (3base64_char "=")		base64_terminal = (2base64_char "==") / (3base64_char "=")
	skipping to change at page 8, line 29 ¶		skipping to change at page 8, line 29 ¶
	UPALPHA = %x41-5A ;; Uppercase: A-Z		UPALPHA = %x41-5A ;; Uppercase: A-Z
	LOALPHA = %x61-7A ;; Lowercase: a-z		LOALPHA = %x61-7A ;; Lowercase: a-z
	ALPHA = %x41-5A / %x61-7A ; A-Z / a-z		ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
	CHAR = %x01-7F		CHAR = %x01-7F
	; any 7-bit US-ASCII character,		; any 7-bit US-ASCII character,
	excluding NUL		excluding NUL
			OCTET = %x00-FF
			; 8 bits of data
	CR = %x0D		CR = %x0D
	; carriage return		; carriage return
	CRLF = CR LF		CRLF = CR LF
	; Internet standard newline		; Internet standard newline
	DIGIT = %x30-39		DIGIT = %x30-39
	; 0-9		; 0-9
	DQUOTE = %x22		DQUOTE = %x22
	skipping to change at page 9, line 8 ¶		skipping to change at page 9, line 11 ¶
	LWSP = *(WSP / CRLF WSP)		LWSP = *(WSP / CRLF WSP)
	; linear white space (past newline)		; linear white space (past newline)
	SP = %x20		SP = %x20
	; space		; space
	WSP = SP / HTAB		WSP = SP / HTAB
	; white space		; white space
	Taken from RFC 2234 [14] and RFC 2554 [15].		Taken from RFC 2234 [12] and RFC 2554 [13].
	4. Message Format		4. 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[6]) calculated
	hash value of the entire message (starting from the ProtocolID
	field) as described in Section 12 and Section 13.
	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
	reliability mode selected. SeqNums are decimal numbers in ASCII		reliability mode selected. SeqNums are decimal numbers in ASCII
	skipping to change at page 12, line 7 ¶		skipping to change at page 11, line 7 ¶
	The header is followed by the message body which contains zero or		The header is followed by the message body which contains zero or
	more commands to be delivered to the destination entity. The syntax		more commands to be delivered to the destination entity. The syntax
	for a complete message is given in Section 6.		for a complete message is given in Section 6.
	If multiple commands are contained within the same Mbus message		If multiple commands are contained within the same Mbus message
	payload, they MUST to be delivered to the Mbus application in the		payload, they MUST to be delivered to the Mbus application in the
	same sequence in which they appear in the message payload.		same sequence in which they appear in the message payload.
	5. Addressing		5. Addressing
	Each entity on the message bus SHOULD respond to messages sent to		Each entity on the message has a unique Mbus address that is used to
	one (or more) addresses. Addresses are sequences of address elements		identify the entity. Senders and receivers of messages are
	that are tag/value pairs. The tag and the value are separated by a		identified by their Mbus addresses. Mbus addresses are sequences of
	colon and tag/value pairs are separated by whitespace, like this:		address elements that are tag/value pairs. The tag and the value are
			separated by a colon and tag/value pairs are separated by
			whitespace, like this:
	(tag:value tag:value ...)		(tag:value tag:value ...)
	The formal ABNF syntax definition for Mbus addresses and their		The formal ABNF syntax definition for Mbus addresses and their
	elements is as follows:		elements is as follows:
	mbus_address = "(" *address_element ")"		mbus_address = "(" *address_element ")"
	address_element = *WSP address_tag ":" address_value *WSP		address_element = *WSP address_tag ":" address_value *WSP
	skipping to change at page 13, line 19 ¶		skipping to change at page 12, line 20 ¶
	5.1 Mandatory Address Elements		5.1 Mandatory Address Elements
	Each Mbus entity MUST provide one mandatory address element that		Each Mbus entity MUST provide one mandatory address element that
	allows to identify the entity. The element name is "id" and the		allows to identify the entity. The element name is "id" and the
	value MUST be be composed of the following components:		value MUST be be composed of the following components:
	o The IP address of the interface that is used for sending messages		o The IP address of the interface that is used for sending messages
	to the Mbus. For IPv4 this the address in decimal dotted		to the Mbus. For IPv4 this the address in decimal dotted
	notation. For IPv6 the interface-ID-part of an address in textual		notation. For IPv6 the interface-ID-part of an address in textual
	representation as specified in [3] MUST be used. In this		representation as specified in RFC 2373[3] MUST be used. In this
	specification, this part is called the "host-ID".		specification, this part is called the "host-ID".
	o An identifier ("entity-ID") that is unique within the scope of a		o An identifier ("entity-ID") that is unique within the scope of a
	single host-ID. The entity comprises two parts. For systems where		single host-ID. The entity comprises two parts. For systems where
	the concept of a process ID is applicable it is RECOMMENDED this		the concept of a process ID is applicable it is RECOMMENDED this
	identifier be composed using a process-ID and a per-process		identifier be composed using a process-ID and a per-process
	disambiguator for different Mbus entities of a process. If a		disambiguator for different Mbus entities of a process. If a
	process ID is not available, this part of the entity-ID may be		process ID is not available, this part of the entity-ID may be
	randomly chosen (it is recommended that at least a 32 bit random		randomly chosen (it is recommended that at least a 32 bit random
	number is chosen). Both numbers are represented in decimal		number is chosen). Both numbers are represented in decimal
	skipping to change at page 14, line 18 ¶		skipping to change at page 13, line 18 ¶
	All messages MUST use the UTF-8 character encoding. Note that US		All messages MUST use the UTF-8 character encoding. Note that US
	ASCII is a subset of UTF-8 and requires no additional encoding, and		ASCII is a subset of UTF-8 and requires no additional encoding, and
	that a message encoded with UTF-8 will not contain zero bytes.		that a message encoded with UTF-8 will not contain zero bytes.
	Each Message MAY be encrypted using a secret key algorithm as		Each Message MAY be encrypted using a secret key algorithm as
	defined in Section 12.		defined in Section 12.
	6.2 Message Header		6.2 Message Header
	A message starts with the header. The first field in the header is		The fields in the header are separated by white space characters,
	the message digest calculated using a keyed hash algorithm as		and followed by CRLF. The format of the header is as follows:
	described in Section 12 followed by CRLF. The other fields in the
	header are separated by white space characters, and followed by
	CRLF. The format of the header is as follows:
	msg_header = MsgDigest CRLF "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP		msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP
	MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList		MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList
	The header fields are explained in Message Format (Section 4). Here		The header fields are explained in Message Format (Section 4). Here
	are the ABNF syntax definitions for the header fields:		are the ABNF syntax definitions for the header fields:
	MsgDigest = base64
	SeqNum = 1*10DIGIT		SeqNum = 1*10DIGIT
	TimeStamp = 1*10DIGIT		TimeStamp = 1*10DIGIT
	MessageType = "R" / "U"		MessageType = "R" / "U"
	ScrAddr = mbus_address		ScrAddr = mbus_address
	DestAddr = mbus_address		DestAddr = mbus_address
	skipping to change at page 16, line 17 ¶		skipping to change at page 15, line 16 ¶
	command_name = ALPHA *(ALPHA / DIGIT / "_" / ".")		command_name = ALPHA *(ALPHA / DIGIT / "_" / ".")
	arglist = "(" *(*WSP parameter *WSP) ")"		arglist = "(" *(*WSP parameter *WSP) ")"
	parameter = Integer / Float / String / List		parameter = Integer / Float / String / List
	Symbol / Data		Symbol / Data
	Command names SHOULD be constructed using hierarchical names to		Command names SHOULD be constructed using hierarchical names to
	group conceptually related commands under a common hierarchy. The		group conceptually related commands under a common hierarchy. The
	delimiter between names in the hierarchy is "." (dot). Applications		delimiter between names in the hierarchy is "." (dot). Application
	profiles MUST NOT define commands starting with "mbus.".		profiles MUST NOT define commands starting with "mbus.".
	The Mbus addressing scheme defined in Section 5 provides for		The Mbus addressing scheme defined in Section 5 provides for
	specifying incomplete addresses by omitting certain elements of an		specifying incomplete addresses by omitting certain elements of an
	address element list, enabling entities to send commands to a group		address element list, enabling entities to send commands to a group
	of Mbus entities. Therefore all command names SHOULD be unambiguous		of Mbus entities. Therefore all command names SHOULD be unambiguous
	in a way that it is possible to interpret or ignore them without		in a way that it is possible to interpret or ignore them without
	considering the message's address.		considering the message's address.
	A set of commands within a certain hierarchy that MUST be understood		A set of commands within a certain hierarchy that MUST be understood
	by every entity is defined in Messages (Section 10).		by every entity is defined in Messages (Section 10).
	7. Transport		7. Transport
	All messages are transmitted as UDP messages with two ways of		All messages are transmitted as UDP messages, with two possible
	sending messages being possible:		alternatives:
	1. Local multicast/broadcast:		1. Local multicast/broadcast:
	This transport class MUST be used for all messages that are not		This transport class MUST be used for all messages that are not
	sent to a fully qualified target address. It MAY also be used		sent to a fully qualified target address. It MAY also be used
	for messages that are sent to a fully qualified target address.		for messages that are sent to a fully qualified target address.
	It MUST be provided by conforming implementations. See Section		It MUST be provided by conforming implementations. See Section
	7.1 for details.		7.1 for details.
	2. Directed unicast:		2. Directed unicast:
	This transport class MAY be used for messages that are sent to a		This transport class MAY be used for messages that are sent to a
	fully qualified destination address. It is OPTIONAL and does not		fully qualified destination address. It is OPTIONAL and does not
	have to be provided by conforming implementations.		have to be provided by conforming implementations.
	Note that "unicast", "multicast" and "broadcast" mean IP-Unicast,		Messages are transmitted in UDP datagrams, a maximum message size of
	IP-Multicast and IP-Broadcast respectively. It is possible to send a
	Mbus message that is addressed to a single entity using
	IP-multicast.
	Since messages are transmitted in UDP datagrams, a maximum size of
	64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications		64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications
	using a non host-local scope do not exceed a message size of the		using a non host-local scope do not exceed a message size of the
	network's MTU.		network's MTU.
			Note that "unicast", "multicast" and "broadcast" mean IP-Unicast,
			IP-Multicast and IP-Broadcast respectively. It is possible to send
			an Mbus message that is addressed to a single entity using
			IP-multicast. This specification deals with both Mbus over UDP/IPv4
			and Mbus over UDP/IPv6.
	7.1 Local Multicast/Broadcast		7.1 Local Multicast/Broadcast
	Local multicast (host-local or link-local, see Mbus configuration		In general, the Mbus uses multicast with a limited scope for message
	(Section 13)), uses a scope relative multicast address of the		transport. Two different Mbus multicast scopes are defined:
	administratively scoped multicast space as described in RFC
	2365[11]. This scope relativ multicast address has yet to be
	assigned (see Section 15). Implementations MUST NOT use scopes
	larger than the link-local scope.
	There will also be a fixed, registered port number that all Mbus		1. host-local
	entities MUST use. Until the address and port number are assigned
	the values given in Section 15 SHOULD be used. In situations where		2. link-local
	multicast is not available, broadcast MAY be used instead. In these
	cases an IP broadcast address for the connected network SHOULD be		Participants of an Mbus session have to know the multicast address
	used for sending. Broadcast MUST NOT be used in situations where		in advance -- it cannot be negotiated during the session since it is
	multicast is available and supported by all systems participating in		already needed for any communication between the participants. I can
	an Mbus session.		also not be allocated prior to an Mbus session because there would
			be no mechanism to announce the allocated address to all potential
			Mbus participants. Therefore the multicast address cannot be
			allocated dynamically, e.g. using multicast address allocation
			protocols, but has to be assigned statically. This document defines
			the use of statically assigned addresses and also provides a
			specification of how an Mbus session can be configured to use
			non-standard addresses (see Section 13).
			An Mbus session can be configured to use either one of the mentioned
			scopes. The following sections specify the use of multicast
			addresses for IPv4 and IPv6.
			7.1.1 Mbus multicast groups for IPv4
			For IPv4, there are two address ranges for "local scope" multicast:
			The IPv4 Local Scope -- 239.255.0.0/16 239.255.0.0/16 is the minimal
			enclosing scope for administratively scoped multicast (as defined
			by RFC 2365[10]) and not further divisible -- its exact extent is
			site dependent. Allocating a statically assigned address in this
			scope would require to allocate a scope relative multicast
			address (the high order /24 in every scoped region is reserved
			for relative assignments), because the main address space is to
			be assigned dynamically, e.g. by using address allocation
			protocols.
			The IPv4 statically assigned link-local scope -- 224.0.0.0/24
			224.0.0.0/24 is the address range for statically assigned
			multicast address for link-local multicast. Multicast routers
			should not forward any multicast datagram with destination
			addresses in this range, regardless of its TTL.
			Because of the unexact extent of 239.255.0.0/16 scopes and the fact
			that the only way to allocate a static address is the use of an
			assigned scope relative address the Mbus uses an multicast address
			from the statically assigned link-local scope (224.0.0.0/24).
			Host-local Mbus scope in an IPv4 environment MUST be implemented by
			using an IPv4 link-local address and an IP-Multicast-TTL of zero.
			Link-local Mbus scope in an IPv4 environment MUST be implemented by
			using an IPv4 link-ocal Scope address and an IP-Multicast-TTL
			greater than zero.
			The IPv4 link-local multicast address has yet to be assigned (see
			Section 15).
			7.1.2 Mbus multicast groups for IPv6
			IPv6 has different address ranges for different multicast scopes and
			distinguishes node local and link local scopes, that are implemented
			as a set of address prefixes for the different address ranges (RFC
			2373[18]). The link-local prefix is FF02, the node-local prefix is
			FF01. A permanently assigned multicast address will be used for Mbus
			multicast communication, i.e. an address that is independent of the
			scope value and that can be used for all scopes. Implementations for
			IPv6 MUST use the scope independent address and the appropriate
			prefix for the selected scope. For host-local Mbus communication the
			IPv6 node-local scope prefix MUST be used, for link-local Mbus
			communication the IPv6 link-local scope prefix MUST be used.
			The permanent IPv6 multicast addresses has yet to be assigned (see
			Section 15).
	If a single application system is distributed across several		If a single application system is distributed across several
	co-located hosts, link local scope SHOULD be used for multicasting		co-located hosts, link local scope SHOULD be used for multicasting
	Mbus messages that potentially have recipients on the other hosts.		Mbus messages that potentially have recipients on the other hosts.
	The Mbus protocol is not intended (and hence deliberately not		The Mbus protocol is not intended (and hence deliberately not
	designed) for communication between hosts not on the same link.		designed) for communication between hosts not on the same link. See
			Section 13 for specifications of Mbus configuration mechanisms.
			7.1.3 Use of Broadcast
			In situations where multicast is not available, broadcast MAY be
			used instead. In these cases an IP broadcast address for the
			connected network SHOULD be used for sending. The node-local
			broadcast address for IPv6 is FF01:0:0:0:0:0:0:1, the link-local
			broadcast address for IPv6 is FF02:0:0:0:0:0:0:1. For IPv4, the
			generic broadcast address (for link-local broadcast) is
			255.255.255.255. It is RECOMMENDED that IPv4-implementations use the
			generic broadcast address and a TTL of zero for host-local
			broadcast.
			Broadcast MUST NOT be used in situations where multicast is
			available and supported by all systems participating in an Mbus
			session.
			See Section 13 for specifications of how to configure the use of
			broadcast.
			7.1.4 Mbus Port Number
			There will also be a fixed, registered port number that all Mbus
			entities MUST use. Until the address and port number are assigned
			the values given in Section 15 SHOULD be used.
	7.2 Directed Unicast		7.2 Directed Unicast
	Directed unicast (via UDP) to the port of a specific application is		Directed unicast (via UDP) to the port of a specific application is
	an alternative transport class. Directed unicast is an OPTIONAL		an alternative transport class. Directed unicast is an OPTIONAL
	optimization and MAY be used by Mbus implementations for delivering		optimization and MAY be used by Mbus implementations for delivering
	messages addressed at a single application entity only -- the		messages addressed at a single application entity only -- the
	address of which the Mbus implementation has learned from other		address of which the Mbus implementation has learned from other
	message exchanges before. Note that the DestAddr field of such		message exchanges before. Note that the DestAddr field of such
	messages MUST still be filled in properly. Every Mbus entity SHOULD		messages MUST still be filled in properly. Every Mbus entity SHOULD
	skipping to change at page 18, line 38 ¶		skipping to change at page 19, line 25 ¶
	Given the definition of "unique endpoint address" above the use of a		Given the definition of "unique endpoint address" above the use of a
	shared endpoint address and a dispatcher still allows other Mbus		shared endpoint address and a dispatcher still allows other Mbus
	entities to send unicast messages to one of the entities that share		entities to send unicast messages to one of the entities that share
	the endpoint address. So this can be considered an implementation		the endpoint address. So this can be considered an implementation
	detail.)		detail.)
	Messages with an empty target address list MUST always be sent to		Messages with an empty target address list MUST always be sent to
	all Mbus entities (via multicast if available).		all Mbus entities (via multicast if available).
	The following algorithm can be used by sending entities to determine		The following algorithm can be used by sending entities to determine
	whether a Mbus address is unique considering the current set of Mbus		whether an Mbus address is unique considering the current set of
	entities:		Mbus entities:
	let ta=the target address;		let ta=the target address;
	iterate through the set of all		iterate through the set of all
	currently known Mbus addresses {		currently known Mbus addresses {
	let ti=the address in each iteration;		let ti=the address in each iteration;
	count the addresses for which		count the addresses for which
	the predicate isSubsetOf(ta,ti) yields true;		the predicate isSubsetOf(ta,ti) yields true;
	}		}
	If the count of matching addresses is exactly 1 the address is		If the count of matching addresses is exactly 1 the address is
	skipping to change at page 20, line 39 ¶		skipping to change at page 21, line 39 ¶
	can be achieved by application layers by sending individual reliable		can be achieved by application layers by sending individual reliable
	messages to each fully qualified destination address, if the		messages to each fully qualified destination address, if the
	membership information for the Mbus session is available.		membership information for the Mbus session is available.
	Each message is tagged with a message sequence number. If the		Each message is tagged with a message sequence number. If the
	MessageType is "R", the sender expects an acknowledgment from the		MessageType is "R", the sender expects an acknowledgment from the
	recipient within a short period of time. If the acknowledgment is		recipient within a short period of time. If the acknowledgment is
	not received within this interval, the sender SHOULD retransmit the		not received within this interval, the sender 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 MUST be retransmitted a		timeout, and restart the timer. Messages MUST be retransmitted a
	small number of times (see below) before the recipient is considered		small number of times (see below) before the transmission or the
	to have failed. If the message is not delivered successfully, the		recipient is considered to have failed. If the message is not
	sending application is notified. In this case, it is up to this		delivered successfully, the sending application is notified. In this
	application to determine the specific actions (if any) to be taken.		case, it is up to this application to determine the specific actions
			(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 commands in the message payload part.		message, with no commands in the message payload part.
	The precise procedures are as follows:		The precise procedures are as follows:
	skipping to change at page 22, line 39 ¶		skipping to change at page 23, line 39 ¶
	excluded from the set of currently known entities. Upon the		excluded from the set of currently known entities. Upon the
	reception of a mbus.bye messages the respective entity is considered		reception of a mbus.bye messages the respective entity is considered
	to have left the Mbus as well and MUST be excluded from the set of		to have left the Mbus as well and MUST be excluded from the set of
	currently known entities immediately.		currently known entities immediately.
	Each Mbus entity MUST send hello messages after startup to the Mbus.		Each Mbus entity MUST send hello messages after startup to the Mbus.
	After transmission of the hello message, it shall start a timer		After transmission of the hello message, it shall start a timer
	after the expiration of which the next hello message is to be		after the expiration of which the next hello message is to be
	transmitted. Transmission of hello messages MUST NOT be stopped		transmitted. Transmission of hello messages MUST NOT be stopped
	unless the entity detaches from the Mbus. The interval for sending		unless the entity detaches from the Mbus. The interval for sending
	hello messages is depending on the current number of entities in a		hello messages is depending on the current number of entities in an
	Mbus group and can thus change dynamically in order to avoid		Mbus group and can thus change dynamically in order to avoid
	congestion due to many entities sending hello messages at a constant		congestion due to many entities sending hello messages at a constant
	high rate.		high rate.
	Section 9.1 specifies the calculation of hello message intervals		Section 9.1 specifies the calculation of hello message intervals
	that MUST be used by protocol implementations. Using the values that		that MUST be used by protocol implementations. Using the values that
	are calculated for obtaining the current hello message timer, the		are calculated for obtaining the current hello message timer, the
	timeout for received hello messages is calculated in Section 9.2.		timeout for received hello messages is calculated in Section 9.2.
	Section 10 specifies the command synopsis for the corresponding Mbus		Section 10 specifies the command synopsis for the corresponding Mbus
	messages.		messages.
	skipping to change at page 23, line 27 ¶		skipping to change at page 24, line 27 ¶
	considering the observed number of Mbus entities.		considering the observed number of Mbus entities.
	The algorithm features the following characteristics:		The algorithm features the following characteristics:
	o The number of hello messages that are received by a single entity		o The number of hello messages that are received by a single entity
	in a certain time unit remains approximately constant as the		in a certain time unit remains approximately constant as the
	number of entities changes.		number of entities changes.
	o The effective interval that is used by a specific Mbus entity is		o The effective interval that is used by a specific Mbus entity is
	randomized in order to avoid unintentional synchronization of		randomized in order to avoid unintentional synchronization of
	hello messages within a Mbus session. The first hello message of		hello messages within an Mbus session. The first hello message of
	an entity is also delayed by a certain random amount of time.		an entity is also delayed by a certain random amount of time.
	o A timer reconsideration mechanism is deployed in order to adapt		o A timer reconsideration mechanism is deployed in order to adapt
	the interval more appropriately in situations where a rapid		the interval more appropriately in situations where a rapid
	change of the number of entities is observed. This is useful when		change of the number of entities is observed. This is useful when
	an entity joins an Mbus sessions and is still learning of the		an entity joins an Mbus sessions and is still learning of the
	existence of other entities or when a larger number of entities		existence of other entities or when a larger number of entities
	leaves the Mbus at once.		leaves the Mbus at once.
	9.1.1 Calculating the Interval for Hello Messages		9.1.1 Calculating the Interval for Hello Messages
	skipping to change at page 30, line 11 ¶		skipping to change at page 31, line 11 ¶
	|c_hello_dither_max | 1.1 | - |		|c_hello_dither_max | 1.1 | - |
	|c_hello_dead | 5 | - |		|c_hello_dead | 5 | - |
	+-------------------+------------------------+--------------+		+-------------------+------------------------+--------------+
	12. Mbus Security		12. Mbus Security
	12.1 Security Model		12.1 Security Model
	In order to prevent accidental or malicious disturbance of Mbus		In order to prevent accidental or malicious disturbance of Mbus
	communications through messages originated by applications from		communications through messages originated by applications from
	other users, message authentication is deployed (Section 12.2). For		other users, message authentication is deployed (Section 12.3). For
	each message a digest is calculated based on the value of a shared		each message a digest is calculated based on the value of a shared
	secret key value. Receivers of messages can check if the sender		secret key value. Receivers of messages can check if the sender
	belongs to the same Mbus security domain by re-calculating the		belongs to the same Mbus security domain by re-calculating the
	digest and comparing it to the received value. Only if both values		digest and comparing it to the received value. 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 ([20])		compensate defective implementations of host local multicast message
	message authentication MUST be provided by conforming		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 12.3). Each message can		using symmetric encryption methods (Section 12.2). Each message can
	be encrypted using an additional shared secret key and a symmetric		be encrypted using an additional shared secret key and a symmetric
	encryption algorithm. Encryption is OPTIONAL for applications, i.e.		encryption algorithm. Encryption is OPTIONAL for applications, i.e.
	it is allowed to configure an Mbus domain not to use encryption. But		it is allowed to configure an Mbus domain not to use encryption. But
	conforming implementations MUST provide the possibility to use		conforming implementations MUST provide the possibility to use
	message encryption (see below).		message encryption (see below).
	Message authentication and encryption can be parameterized by		Message authentication and encryption can be parameterized by
	certain values, e.g. by the algorithms to apply or by the keys to		certain values, e.g. by the algorithms to apply or by the keys to
	use. These parameters (amongst others) are defined in an Mbus		use. These parameters (amongst others) are defined in an Mbus
	configuration entity that is accessible to all Mbus entities that		configuration 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 13 defines the mandatory and optional		configuration entity. Section 13 defines the mandatory and optional
	parameters as well as storage procedures for different platforms.		parameters as well as storage procedures for different platforms.
	Only in cases where none of the options for configuration entities		Only in cases where none of the options for configuration entities
	mentioned in Section 13 is applicable alternative methods of		mentioned in Section 13 is applicable alternative methods of
	configuring Mbus protocol entities MAY be deployed.		configuring Mbus protocol entities MAY be deployed.
	12.2 Message Authentication		The algorithms and procedures for applying encryption and
			authentication techniques are specified in the following sections.
	Either MD5 [16] or SHA-1 [17] SHOULD be used for message		12.2 Encryption
	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		Encryption of messages is OPTIONAL, that means, an Mbus MAY be
	consist of 16 Base64-encoded characters.		configured not to use encryption.
	Hash keys MUST have a length of 96 bit (12 bytes), that are 16		Implementations can choose between different encryption algorithms.
	Base64-encoded characters.		Either AES [17], DES [15], 3DES (triple DES) [15] or IDEA [21]
			SHOULD be used for encryption. Implementations MUST at least provide
			AES and it is RECOMMENDED that they support the other algorithms as
			well.
	12.3 Encryption		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.
	Either DES, 3DES (triple DES) or IDEA SHOULD be used for encryption.		The length of the encryption keys is determined by the currently
	Encryption MAY be neglected for applications, e.g. in situations		used encryption algorithm. This means, the configured encryption key
	where license regulations, export or encryption laws would be		MUST NOT be shorter than the native key length for the currently
	offended otherwise. However, the implementation of DES is		configured algorithm.
	RECOMMENDED as a baseline. DES implementations MUST use the DES
	Cipher Block Chaining (CBC) mode. For algorithms requiring		DES implementations MUST use the DES Cipher Block Chaining (CBC)
	en/decryption data to be padded to certain boundaries octets with a		mode. DES keys (56 bits) MUST be encoded as 8 octets as described in
	value of 0 SHOULD be used for padding characters. The padding		RFC1423[11], resulting in 12 Base64-encoded characters. IDEA uses
	characters MUST be appended after calculating the message digest		128-bit keys (24 Base64-encoded characters). AES can use either
	when encoding and MUST be erased before recalculating the message		128-bit, 192-bit or 256-bit keys. For Mbus encryption only 128-bit
	digest when decoding. IDEA uses 128-bit keys (24 Base64-encoded		keys (24 Base64-encoded characters) MUST be used.
	characters). DES keys (56 bits) MUST be encoded as 8 octets as
	described in RFC1423[13], resulting in 12 Base64-encoded characters.		12.3 Message Authentication
			For authentication of messages, hashed message authentication codes
			(HMACs) as described in RFC2104[4] are deployed. In general,
			implementations can choose between a number of digest algorithms.
			For Mbus authentication, the HMAC algorithm MUST be applied in the
			following way:
			The keyed hash value is calculated using the HMAC algorithm
			specified in RFC2104[4]. The concrete hash algorithm and the
			secret hash key MUST be obtained from the Mbus configuration (see
			Section 13).
			The keyed hash values (see RFC2104[4]) MUST be truncated to 96
			bits (12 octets).
			Subsequently, the resulting 12 octets MUST be Base64-encoded,
			resulting in 16 Base64-encoded characters (see RFC1521[6]).
			Either MD5 [14] or SHA-1 [16] SHOULD be used for message
			authentication codes (MACs). An implementation MAY provide MD5,
			whereas SHA-1 MUST be implemented.
			The length of the hash keys is determined by the selected hashing
			algorithm. This means, the configured hash key MUST NOT be shorter
			than the native key length for the currently configured algorithm.
			12.4 Procedures for Senders and Receivers
	The mandatory subset of algorithms that MUST be provided by		The mandatory subset of algorithms that MUST be provided by
	implementations is DES and MD5.		implementations is AES and SHA-1.
	See Section 13 for a specification of notations for Base64-strings.		See Section 13 for a specification of notations for Base64-strings.
			A sender MUST apply the following operations to a message that is to
			be sent:
			1. If encryption is enabled, the message MUST be encrypted using
			the configured algorithm and the configured encryption key.
			Padding (adding extra-characters) for block-ciphers MUST be
			applied as specified in Section 12.2. If encryption is not
			enabled, the message is left unchanged.
			2. Subsequently, a message authentication code (MAC) for the
			encrypted message MUST be calculated using the configured
			HMAC-algorithm and the configured hash key.
			3. The MAC MUST then be converted to Base64 encoding, resulting in
			12 Base64-charcters as specified in Section 12.3.
			4. At last, the sender MUST construct the final message by placing
			the encrypted message after the base64-encoded MAC and a CRLF.
			The ABNF definition for the final message is as follows:
			final_msg = MsgDigest CRLF encr_msg
			MsgDigest = base64
			encr_msg = *OCTET
			A receiver MUST apply the following operations to a message that it
			has received:
			1. Separate the base64-encoded MAC from the encypted message and
			decode the MAC.
			2. Re-calculate the MAC for the message using the configured
			HMAC-algorithm and the configured hash key.
			3. Compare the original MAC with re-calculated MAC. If they differ,
			the message MUST NOT be decrypted and parsed further.
			4. If encryption is enabled, the message MUST be decrypted using
			the confiured algorithm and the configured encryption key.
			Trailing octets with a value of 0 MUST be deleted.
	13. Mbus Configuration		13. 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
	skipping to change at page 32, line 27 ¶		skipping to change at page 34, line 27 ¶
	Encryption key		Encryption key
	The secret key used for message encryption.		The secret key used for message encryption.
	Hash key		Hash key
	The hash key used for message authentication.		The hash key used for message authentication.
	Scope		Scope
	The Internet scope to be used for sent messages.		The multicast scope to be used for sent messages.
	The upper parameters are mandatory and MUST be present in every Mbus		The upper parameters are mandatory and MUST be present in every Mbus
	configuration entity.		configuration entity.
	The following parameters are optional. When they are present they		The following parameters are optional. When they are present they
	MUST be honoured but when they are not present implementations		MUST be honoured but when they are not present implementations
	SHOULD fall back to the predefined default values (as defined in		SHOULD fall back to the predefined default values (as defined in
	Transport (Section 7)):		Transport (Section 7)):
	Address		Address
	The non-standard multicast/broadcast address to use for		The non-standard multicast address to use for message
	message transport.		transport.
	Port		Use of Broadcast
			It can be specified whether broadcast should be used. If
			broadcast has been configured implementations SHOULD use the
			network broadcast address (as specified in Section 7.1.3)
			instead of the standard multicast address.
			Port Number
	The non-standard port number to use for message transport.		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 SHOULD be used and for		Unix-like systems a configuration file SHOULD be used and for
	Windows-95/98/NT/2000 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.		that SHOULD be used. For other systems it is RECOMMENDED that the
			file-based configuration mechanism is used.
	The syntax of the values for the respective parameter entries		The syntax of the values for the respective parameter entries
	remains the same for both configuration facilities. The following		remains the same for both configuration facilities. The following
	defines a set of ABNF (see RFC2234[14]) productions that are later		defines a set of ABNF (see RFC2234[12]) productions that are later
	referenced for the definitions for the configuration file syntax and		referenced for the definitions for the configuration file syntax and
	registry entries:		registry entries:
	algo-id = "NOENCR" / "DES" / "3DES" / "IDEA" /		algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" /
	"HMAC-MD5-96" / "HMAC-SHA1-96"		"HMAC-MD5-96" / "HMAC-SHA1-96"
	scope = "HOSTLOCAL" / "LINKLOCAL"		scope = "HOSTLOCAL" / "LINKLOCAL"
	key = base64		key = base64
	version_number = 1*10DIGIT		version_number = 1*10DIGIT
	key_value = "(" algo-id "," key ")"		key_value = "(" algo-id "," key ")"
	address = IPv4address / IPv6address		address = IPv4address / IPv6address / "BROADCAST"
	port = 1*5DIGIT		port = 1*5DIGIT
	Given the definition above, a key entry MUST be specified using this		Given the definition above, a key entry MUST be specified using this
	notation:		notation:
	"("algo-id","base64string")"		"("algo-id","base64string")"
	algo-id is one of the character strings specified above. For		algo-id is one of the character strings specified above. For
	algo-id==``NOENCR'' the other fields are ignored. The delimiting		algo-id==``NOENCR'' the other fields are ignored. The delimiting
	commas MUST always be present though.		commas MUST always be present though.
	A Base64 string consists of the characters defined in the Base64		A Base64 string consists of the characters defined in the Base64
	char-set (see RFC1521[6]) including all eventual padding characters,		char-set (see RFC1521[6]) including all eventual padding characters,
	i.e. the length of Base64-string is always a multiple of 4.		i.e. the length of a Base64-string is always a multiple of 4.
	The scope parameter is used to configure an IP-Multicast scope and		The scope parameter is used to configure an IP-Multicast scope and
	may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations		may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations
	SHOULD choose an appropriate IP-Multicast scope depending on the		SHOULD choose an appropriate IP-Multicast scope depending on the
	value of this parameter and construct an effective IP-Address using		value of this parameter and construct an effective IP-Address
	the Mbus scope relative address (see Section 15). Implementations		considering the specifications of Section 7.1.
	MUST NOT use scopes larger than link-local scope. Note that the IPv4
	local scope is 239.255.0.0/16. Host-local scope in an IPv4		The use of broadcast is configured by providing the value
	environment MUST be implemented by using a local scope address and		"BROADCAST" for the address field. If broadcast has been configured,
	an IP-Multicast-TTL of zero. Link-local scope in an IPv4 environment		implementations SHOULD use the network broadcast address for the
	MUST be implemented by using a local scope address and an		used IP version instead of the standard multicast address.
	IP-Multicast-TTL of one. For IPv6 the link-local prefix is FF02, the
	node-local prefix is FF01.
	The version_number parameter specifies a version number for the used		The version_number parameter specifies a version number for the used
	configuration entity.		configuration entity.
	13.1 File based parameter storage		13.1 File based parameter storage
	The file name for a Mbus configuration file is ".mbus" in the user's		The file name for an Mbus configuration file is ".mbus" in the
	home-directory. If an environment variable called MBUS is defined		user's home-directory. If an environment variable called MBUS is
	implementations SHOULD interpret the value of this variable as a		defined implementations SHOULD interpret the value of this variable
	fully qualified file name that is to be used for the configuration		as a fully qualified file name that is to be used for the
	file. Implementations MUST ensure that this file has appropriate		configuration file. Implementations MUST ensure that this file has
	file permissions that prevent other users to read or write it. The		appropriate file permissions that prevent other users to read or
	file MUST exist before a conference is initiated. Its contents MUST		write it. The file MUST exist before a conference is initiated. Its
	be UTF-8 encoded and MUST be structured as follows:		contents MUST be UTF-8 encoded and MUST be structured as follows:
	mbus-file = mbus-topic LF *(entry LF)		mbus-file = mbus-topic LF *(entry LF)
	mbus-topic = "[MBUS]"		mbus-topic = "[MBUS]"
	entry = 1*(version_info / hashkey_info		entry = 1*(version_info / hashkey_info
	/ encryptionkey_info / scope_info		/ encryptionkey_info / scope_info
	/ port_info / address_info)		/ port_info / address_info)
	version_info = "CONFIG_VERSION=" version_number		version_info = "CONFIG_VERSION=" version_number
	skipping to change at page 34, line 36 ¶		skipping to change at page 36, line 39 ¶
	hashkey_info = "HASHKEY=" key_value		hashkey_info = "HASHKEY=" key_value
	encrkey_info = "ENCRYPTIONKEY=" key_value		encrkey_info = "ENCRYPTIONKEY=" key_value
	scope_info = "SCOPE=" scope		scope_info = "SCOPE=" scope
	port_info = "PORT=" port		port_info = "PORT=" port
	address_info = "ADDRESS=" address		address_info = "ADDRESS=" address
	Please refer to [3] for productions of IPv4address.
	The following entries are defined: CONFIG_VERSION, HASHKEY,		The following entries are defined: CONFIG_VERSION, HASHKEY,
	ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.		ENCRYPTIONKEY, SCOPE, PORT, ADDRESS.
	The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory,		The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory,
	they MUST be present in every Mbus configuration file. The order of		they MUST be present in every Mbus configuration file. The order of
	entries is not significant.		entries is not significant.
	An example Mbus configuration file:		An example Mbus configuration file:
	[MBUS]		[MBUS]
	skipping to change at page 36, line 11 ¶		skipping to change at page 38, line 11 ¶
	The same syntax for key values as for the file based configuration		The same syntax for key values as for the file based configuration
	facility MUST be used.		facility MUST be used.
	14. Security Considerations		14. Security Considerations
	The Mbus security mechanisms are specified in Section 12.1.		The Mbus security mechanisms are specified in Section 12.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 is intended to provide reasonable
	best security due to the cryptographic weaknesses of the individual		security by mandating algorithms and key lengths that are currently
	algorithms. For example, it has been stated in [4] that MD5 had been		considered to be cryptographically strong enough.
	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 ([18]).
	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 ([18], [19]).
	We do not consider the well-known weaknesses of the mentioned
	algorithms a problem:
	o The problem of receiving unauthenticated messages is considered		However, in order to allow for efficiency it is allowable to use
	to be the main security threat for Mbus communication. We believe		cryptographically weaker algorithms, for example HMAC-MD5 instead of
	that HMAC-MD5 is sufficiently secure as a baseline algorithm. For		HMAC-SHA1. Furthermore, encryption can be turned off completely if
	application requiring special security concerning authentication		privacy is provided by other means or not considered important for a
	of messages there is the option of using implementations that		certain application.
	implement SHA-1.
	o Encryption is optional anyway, i.e. users can decide to have		Users of the Mbus should therefore be aware of the selected security
	their implementations sending clear text Mbus messages. Given the		configuration and should check if it meets the security demands for
	local nature of Mbus communication this is feasible for most use		a given application. Since every implementation MUST provide the
	cases. In case the base DES encryption is not considered		cryptographically strong algorithm it should always be possible to
	sufficient there is still the possibility to use implementations		configure an Mbus in a way that secure communication with
	that implement 3DES or IDEA.		authentication and privacy is ensured.
	However, application developers should be aware of incorrect IP		In any way, application developers should be aware of incorrect IP
	implementations that do not conform to RFC 1122[2] and do send		implementations that do not conform to RFC 1122[2] and do send
	datagrams with TTL values of zero, resulting in Mbus messages sent		datagrams with TTL values of zero, resulting in Mbus messages sent
	to the local network link although a user might have selected host		to the local network link although a user might have selected host
	local scope in the Mbus configuration. In these cases the use of		local scope in the Mbus configuration. When using of
	encryption SHOULD be considered if privacy is desired.		administratively scoped multicast users cannot always assume the
			presence of correctly configured boundary routers. In these cases
			the use of encryption SHOULD be considered if privacy is desired.
	15. IANA Considerations		15. IANA Considerations
	The IANA is requested to assign a port number and a scope relative		The IANA is requested to assign a link-local IPv4 multicast address
	multicast address. For the time being the tentative IPv4 multicast		from the address space 224.0.0.0/24, an IPv6 permanent multicast
	address 239.255.255.247 and the port number 47000 (decimal) SHOULD		address and a port number. For the time being the tentative IPv4
	be used.		multicast address 239.255.255.247 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.
	[2] Braden, R., "Requirements for Internet Hosts -- Communication		[2] Braden, R., "Requirements for Internet Hosts -- Communication
	Layers", RFC 1122, October 1989.		Layers", RFC 1122, October 1989.
	[3] Hinden, R. and S. Deering, "IP Version 6 Addressing		[3] Hinden, R. and S. Deering, "IP Version 6 Addressing
	skipping to change at page 38, line 27 ¶		skipping to change at page 40, line 27 ¶
	for Message Authentication", RFC 2104, February 1997.		for Message Authentication", RFC 2104, February 1997.
	[5] Crocker, D.H., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT		[5] Crocker, D.H., "STANDARD FOR THE FORMAT OF ARPA INTERNET TEXT
	MESSAGES", August 1982.		MESSAGES", August 1982.
	[6] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail		[6] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
	Extensions) Part One: Mechanisms for Specifying and Describing		Extensions) Part One: Mechanisms for Specifying and Describing
	the Format of Internet Message Bodies", RFC 1521, September		the Format of Internet Message Bodies", RFC 1521, September
	1993.		1993.
	[7] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The		[7] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
	Internet Multimedia Conferencing Architecture", Internet Draft
	draft-ietf-mmusic-confarch-03.txt, July 2000.
	[8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen,
	"RTP: A Transport Protocol for Real-Time Applications", RFC		"RTP: A Transport Protocol for Real-Time Applications", RFC
	1889, January 1996.		1889, January 1996.
	[9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,		[8] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
	"SIP: Session Initiation Protocol", RFC 2543, March 1999.		"SIP: Session Initiation Protocol", RFC 2543, March 1999.
	[10] Handley, M. and V. Jacobsen, "SDP: Session Description		[9] Handley, M. and V. Jacobsen, "SDP: Session Description
	Protocol", RFC 2327, April 1998.		Protocol", RFC 2327, April 1998.
	[11] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,		[10] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
	July 1998.		July 1998.
	[12] Ott, J., Perkins, C. and D. Kutscher, "Requirements for Local		[11] Balenson, D., "Privacy Enhancement for Internet Electronic
	Conference Control", Internet Draft
	draft-ietf-mmusic-mbus-req-00.txt, December 1999.
	[13] Balenson, D., "Privacy Enhancement for Internet Electronic
	Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423,		Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423,
	February 1993.		February 1993.
	[14] Crocker, D. and P. Overell, "Augmented BNF for Syntax		[12] Crocker, D. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", RFC 2234, November 1997.		Specifications: ABNF", RFC 2234, November 1997.
	[15] Myers, J., "SMTP Service Extension for Authentication", RFC		[13] Myers, J., "SMTP Service Extension for Authentication", RFC
	2554, March 1999.		2554, March 1999.
	[16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,		[14] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
	April 1992.		April 1992.
	[17] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards		[15] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards
			and Technology, "Data Encryption Standard (DES)", FIPS PUB
			46-3, Category Computer Security, Subcategory Cryptography,
			October 1999.
			[16] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards
	and Technology, "Secure Hash Standard", FIPS PUB 180-1, April		and Technology, "Secure Hash Standard", FIPS PUB 180-1, April
	1995.		1995.
	[18] Schneier, B., "Applied Cryptography", Edition 2, Publisher		[17] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March
	John Wiley & Sons, Inc., 1996.		1999.
	[19] distributed.net, "Project DES", WWW		[18] Hinden, R.M. and S.E. Deering, "IP Version 6 Addressing
	http://www.distributed.net/des/, 1999.		Architecture", RFC 2373, July 1998.
	[20] Microsoft, "BUG: Winsock Sends IP Packets with TTL 0", WWW		[19] Handley, M., Crowcroft, J., Bormann, C. and J. Ott, "The
	http://support.microsoft.com/support/kb/articles/Q138/2/68.asp, March 1999		Internet Multimedia Conferencing Architecture", Internet Draft
	.		draft-ietf-mmusic-confarch-03.txt, status: non-normative, July
			2000.
			[20] Ott, J., Perkins, C. and D. Kutscher, "Requirements for Local
			Conference Control", Internet Draft
			draft-ietf-mmusic-mbus-req-00.txt, status: non-normative,
			December 1999.
			[21] Schneier, B., "Applied Cryptography", Edition 2, Publisher
			John Wiley & Sons, Inc., status: non-normative, 1996.
			[22] distributed.net, "Project DES", WWW
			http://www.distributed.net/des/, status: non-normative, 1999.
	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.201-7028		Phone: +49.421.201-7028
	skipping to change at page 41, line 5 ¶		skipping to change at page 43, line 5 ¶
	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.uni-bremen.de		EMail: dku@tzi.uni-bremen.de
			Appendix A. About References
			Please note that the list of references contains normative as well
			as non-normative references. Each Non-normative references is marked
			as "status: non-normative". All unmarked references are normative.
			Appendix B. Limitations and Future Work
			The Mbus is a light-weight local coordination mechanism and
			deliberately not designed for larger scope coordination. It is
			expected to be used on a single node or -- at most -- on a single
			network link.
			Therefore the Mbus protocol does not contain features that would be
			required to qualify it for the use over the global Internet:
			There are no mechanisms to provide congestion control. The issue
			of congestion control is a general problem for multicast
			protocols. The Mbus allows for un-acknowledged messages that are
			sent unreliably, for example as event notifications, from one
			entity to another. Since negative acknowledgements are not
			defined there is no way the sender could realize that it is
			flooding another entity or congesting a low bandwidth network
			segment.
			The reliability mechanism, i.e. the retransmission timers, are
			designed to provide effective, responsive message transport on
			local links but are not suited to cope with larger delays that
			could be introduced from router queues etc.
			Some experiments are currently underway to test the applicability of
			bridges between different distributed Mbus domains without changing
			the basic protocol semantics. Since the use of such bridges should
			be orthogonal to the basic Mbus protocol definitions and since these
			experiments are still work in progress there is no mention of this
			concept in this specification.
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2000). All Rights Reserved.		Copyright (C) The Internet Society (2001). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implmentation may be prepared, copied, published		or assist in its implmentation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	document itself may not be modified in any way, such as by removing		document itself may not be modified in any way, such as by removing
	the copyright notice or references to the Internet Society or other		the copyright notice or references to the Internet Society or other
	Internet organizations, except as needed for the purpose of		Internet organizations, except as needed for the purpose of
End of changes. 74 change blocks.
	220 lines changed or deleted		418 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/