diff options
Diffstat (limited to 'doc/rfc/rfc3259.txt')
| -rw-r--r-- | doc/rfc/rfc3259.txt | 2187 |
1 files changed, 2187 insertions, 0 deletions
diff --git a/doc/rfc/rfc3259.txt b/doc/rfc/rfc3259.txt new file mode 100644 index 0000000..41c6414 --- /dev/null +++ b/doc/rfc/rfc3259.txt @@ -0,0 +1,2187 @@ + + + + + + +Network Working Group J. Ott +Request for Comments: 3259 TZI, Universitaet Bremen +Category: Informational C. Perkins + USC Information Sciences Institute + D. Kutscher + TZI, Universitaet Bremen + April 2002 + + + A Message Bus for Local Coordination + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + The local Message Bus (Mbus) is a light-weight message-oriented + coordination protocol for group communication between application + components. The Mbus provides automatic location of communication + peers, subject based addressing, reliable message transfer and + different types of communication schemes. The protocol is layered on + top of IP multicast and is specified for IPv4 and IPv6. The IP + multicast scope is limited to link-local multicast. This document + specifies the Mbus protocol, i.e., message syntax, addressing and + transport mechanisms. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1 Mbus Overview . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.2 Purpose of this Document . . . . . . . . . . . . . . . . . . 5 + 1.3 Areas of Application . . . . . . . . . . . . . . . . . . . . 5 + 1.4 Terminology for requirement specifications . . . . . . . . . 6 + 2. Common Formal Syntax Rules . . . . . . . . . . . . . . . . . 6 + 3. Message Format . . . . . . . . . . . . . . . . . . . . . . . 7 + 4. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.1 Mandatory Address Elements . . . . . . . . . . . . . . . . . 10 + 5. Message Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.1 Message Encoding . . . . . . . . . . . . . . . . . . . . . . 11 + 5.2 Message Header . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.3 Command Syntax . . . . . . . . . . . . . . . . . . . . . . . 12 + + + +Ott, et. al. Informational [Page 1] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + 6. Transport . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6.1 Local Multicast/Broadcast . . . . . . . . . . . . . . . . . 14 + 6.1.1 Mbus multicast groups for IPv4 . . . . . . . . . . . . . . . 15 + 6.1.2 Mbus multicast groups for IPv6 . . . . . . . . . . . . . . . 15 + 6.1.3 Use of Broadcast . . . . . . . . . . . . . . . . . . . . . . 16 + 6.1.4 Mbus UDP Port Number . . . . . . . . . . . . . . . . . . . . 16 + 6.2 Directed Unicast . . . . . . . . . . . . . . . . . . . . . . 16 + 7. Reliability . . . . . . . . . . . . . . . . . . . . . . . . 18 + 8. Awareness of other Entities . . . . . . . . . . . . . . . . 20 + 8.1 Hello Message Transmission Interval . . . . . . . . . . . . 21 + 8.1.1 Calculating the Interval for Hello Messages . . . . . . . . 22 + 8.1.2 Initialization of Values . . . . . . . . . . . . . . . . . . 23 + 8.1.3 Adjusting the Hello Message Interval when the Number of + Entities increases . . . . . . . . . . . . . . . . . . . . . 23 + 8.1.4 Adjusting the Hello Message Interval when the Number of + Entities decreases . . . . . . . . . . . . . . . . . . . . . 23 + 8.1.5 Expiration of hello timers . . . . . . . . . . . . . . . . . 23 + 8.2 Calculating the Timeout for Mbus Entities . . . . . . . . . 24 + 9. Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.1 mbus.hello . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.2 mbus.bye . . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 9.3 mbus.ping . . . . . . . . . . . . . . . . . . . . . . . . . 25 + 9.4 mbus.quit . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 9.5 mbus.waiting . . . . . . . . . . . . . . . . . . . . . . . . 26 + 9.6 mbus.go . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 10. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 11. Mbus Security . . . . . . . . . . . . . . . . . . . . . . . 28 + 11.1 Security Model . . . . . . . . . . . . . . . . . . . . . . . 28 + 11.2 Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 28 + 11.3 Message Authentication . . . . . . . . . . . . . . . . . . . 29 + 11.4 Procedures for Senders and Receivers . . . . . . . . . . . . 30 + 12. Mbus Configuration . . . . . . . . . . . . . . . . . . . . . 31 + 12.1 File based parameter storage . . . . . . . . . . . . . . . . 33 + 12.2 Registry based parameter storage . . . . . . . . . . . . . . 34 + 13. Security Considerations . . . . . . . . . . . . . . . . . . 34 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 + A. About References . . . . . . . . . . . . . . . . . . . . . . 37 + B. Limitations and Future Work . . . . . . . . . . . . . . . . 37 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 39 + + + + + + + + + + +Ott, et. al. Informational [Page 2] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +1. Introduction + + The implementation of multiparty multimedia conferencing systems is + one example where a simple coordination infrastructure can be useful: + In a variety of conferencing scenarios, a local communication channel + can provide conference-related information exchange between co- + located but otherwise independent application entities, for example + those taking part in application sessions that belong to the same + conference. In loosely coupled conferences such a mechanism allows + for coordination of application entities, e.g., to implement + synchronization between media streams or to configure entities + without user interaction. It can also be used to implement tightly + coupled conferences enabling a conference controller to enforce + conference wide control within an end system. + + Conferencing systems such as IP telephones can also be viewed as + components of a distributed system and can thus be integrated into a + group of application modules: For example, an IP telephony call that + is conducted with a stand-alone IP telephone can be dynamically + extended to include media engines for other media types using the + coordination function of an appropriate coordination mechanism. + Different individual conferencing components can thus be combined to + build a coherent multimedia conferencing system for a user. + + Other possible scenarios include the coordination of application + components that are distributed on different hosts in a network, for + example, so-called Internet appliances. + +1.1 Mbus Overview + + Local coordination of application components requires a number of + different interaction models: some messages (such as membership + information, floor control notifications, dissemination of conference + state changes, etc.) may need to be sent to all local application + entities. Messages may also be targeted at a certain application + class (e.g., all whiteboards or all audio tools) or agent type (e.g., + all user interfaces rather than all media engines). Or there may be + any (application- or message-specific) subgrouping defining the + intended recipients, e.g., messages related to media synchronization. + Finally, there may be messages that are directed at a single entity: + for example, specific configuration settings that a conference + controller sends to a particular application entity, or query- + response exchanges between any local server and its clients. + + The Mbus protocol as defined here satisfies these different + communication needs by defining different message transport + mechanisms (defined in Section 6) and by providing a flexible + addressing scheme (defined in Section 4). + + + +Ott, et. al. Informational [Page 3] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + Furthermore, Mbus messages exchanged between application entities may + have different reliability requirements (which are typically derived + from their semantics). Some messages will have a rather transient + character conveying ephemeral state information (which is + refreshed/updated periodically), such as the volume meter level of an + audio receiver entity to be displayed by its user interface agent. + Certain Mbus messages (such as queries for parameters or queries to + local servers) may require a response from the peer(s), thereby + providing an explicit acknowledgment at the semantic level on top of + the Mbus. Other messages will modify the application or conference + state and hence it is crucial that they do not get lost. The latter + type of message has to be delivered reliably to the recipient, + whereas messages of the first type do not require reliability + mechanisms at the Mbus transport layer. For messages confirmed at + the application layer it is up to the discretion of the application + whether or not to use a reliable transport underneath. + + In some cases, application entities will want to tailor the degree of + reliability to their needs, others will want to rely on the + underlying transport to ensure delivery of the messages -- and this + may be different for each Mbus message. The Mbus message passing + mechanism specified in this document provides a maximum of + flexibility by providing reliable transmission achieved through + transport-layer acknowledgments (in case of point-to-point + communications only) as well as unreliable message passing (for + unicast, local multicast, and local broadcast). We address this + topic in Section 4. + + Finally, accidental or malicious disturbance of Mbus communications + through messages originated by applications from other users needs to + be prevented. Accidental reception of Mbus messages from other users + may occur if either two users share the same host for using Mbus + applications or if they are using Mbus applications that are spread + across the same network link: in either case, the used Mbus multicast + address and the port number may be identical leading to reception of + the other party's Mbus messages in addition to the user's own ones. + Malicious disturbance may happen because of applications multicasting + (e.g., at a global scope) or unicasting Mbus messages. To eliminate + the possibility of processing unwanted Mbus messages, the Mbus + protocol contains message digests for authentication. Furthermore, + the Mbus allows for encryption to ensure privacy and thus enable + using the Mbus for local key distribution and other functions + potentially sensitive to eavesdropping. This document defines the + framework for configuring Mbus applications with regard to security + parameters in Section 12. + + + + + + +Ott, et. al. Informational [Page 4] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +1.2 Purpose of this Document + + Three components constitute the message bus: the low level message + passing mechanisms, a command syntax and naming hierarchy, and the + addressing scheme. + + The purpose of this document is to define the protocol mechanisms of + the lower level Mbus message passing mechanism which is common to all + Mbus implementations. This includes the specification of + + o the generic Mbus message format; + + o the addressing concept for application entities (note that + concrete addressing schemes are to be defined by application- + specific profiles); + + o the transport mechanisms to be employed for conveying messages + between (co-located) application entities; + + o the security concept to prevent misuse of the Message Bus (such as + taking control of another user's conferencing environment); + + o the details of the Mbus message syntax; and + + o a set of mandatory application independent commands that are used + for bootstrapping Mbus sessions. + +1.3 Areas of Application + + The Mbus protocol can be deployed in many different application + areas, including but not limited to: + + Local conference control: In the Mbone community a model has arisen + whereby a set of loosely coupled tools are used to participate in + a conference. A typical scenario is that audio, video, and shared + workspace functionality is provided by three separate tools + (although some combined tools exist). This maps well onto the + underlying RTP [8] (as well as other) media streams, which are + also transmitted separately. Given such an architecture, it is + useful to be able to perform some coordination of the separate + media tools. For example, it may be desirable to communicate + playout-point information between audio and video tools, in order + to implement lip-synchronization, to arbitrate the use of shared + resources (such as input devices), etc. + + A refinement of this architecture relies on the presence of a + number of media engines which perform protocol functions as well + as capturing and playout of media. In addition, one (or more) + + + +Ott, et. al. Informational [Page 5] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + (separate) user interface agents exist that interact with and + control their media engine(s). Such an approach allows + flexibility in the user-interface design and implementation, but + obviously requires some means by which the various involved agents + may communicate with one another. This is particularly desirable + to enable a coherent response to a user's conference-related + actions (such as joining or leaving a conference). + + Although current practice in the Mbone community is to work with a + loosely coupled conference control model, situations arise where + this is not appropriate and a more tightly coupled wide-area + conference control protocol must be employed. In such cases, it + is highly desirable to be able to re-use the existing tools (media + engines) available for loosely coupled conferences and integrate + them with a system component implementing the tight conference + control model. One appropriate means to achieve this integration + is a communication channel that allows a dedicated conference + control entity to "remotely" control the media engines in addition + to or instead of their respective user interfaces. + + Control of device groups in a network: A group of devices that are + connected to a local network, e.g., home appliances in a home + network, require a local coordination mechanism. Minimizing + manual configuration and the the possibility to deploy group + communication will be useful in this application area as well. + +1.4 Terminology for requirement specifications + + In this document, the key words "MUST", "MUST NOT", "REQUIRED", + "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", + and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and + indicate requirement levels for compliant Mbus implementations. + +2. Common Formal Syntax Rules + + This section contains definitions of common ABNF [13] syntax elements + that are later referenced by other definitions in this document: + + base64 = base64_terminal / + ( 1*(4base64_CHAR) [base64_terminal] ) + + base64_char = UPALPHA / LOALPHA / DIGIT / "+" / "/" + ;; Case-sensitive + + base64_terminal = (2base64_char "==") / (3base64_char "=") + + UPALPHA = %x41-5A ;; Uppercase: A-Z + + + + +Ott, et. al. Informational [Page 6] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + LOALPHA = %x61-7A ;; Lowercase: a-z + + + ALPHA = %x41-5A / %x61-7A ; A-Z / a-z + + CHAR = %x01-7E + ; any 7-bit US-ASCII character, + excluding NUL and delete + + OCTET = %x00-FF + ; 8 bits of data + + CR = %x0D + ; carriage return + + CRLF = CR LF + ; Internet standard newline + + DIGIT = %x30-39 + ; 0-9 + + DQUOTE = %x22 + ; " (Double Quote) + + HTAB = %x09 + ; horizontal tab + + LF = %x0A + ; linefeed + + LWSP = *(WSP / CRLF WSP) + ; linear white space (past newline) + + SP = %x20 + ; space + + WSP = SP / HTAB + ; white space + + Taken from RFC 2234 [13] and RFC 2554 [14]. + +3. Message Format + + An Mbus message comprises a header and a body. The header is used to + indicate how and where a message should be delivered and the body + provides information and commands to the destination entity. The + following pieces of information are included in the header: + + + + +Ott, et. al. Informational [Page 7] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + A fixed ProtocolID field identifies the version of the message bus + protocol used. The protocol defined in this document is + "mbus/1.0" (case-sensitive). + + A sequence number (SeqNum) is contained in each message. The + first message sent by a source SHOULD set SeqNum to zero, and it + MUST increment by one for each message sent by that source. A + single sequence number is used for all messages from a source, + irrespective of the intended recipients and the reliability mode + selected. The value range of a sequence number is (0,4294967295). + An implementation MUST re-set its sequence number to 0 after + reaching 4294967295. Implementations MUST take into account that + the SeqNum of other entities may wrap-around. + + SeqNums are decimal numbers in ASCII representation. + + The TimeStamp field is also contained in each message and SHOULD + contain a decimal number representing the time of the message + construction in milliseconds since 00:00:00, UTC, January 1, 1970. + + A MessageType field indicates the kind of message being sent. The + value "R" indicates that the message is to be transmitted reliably + and MUST be acknowledged by the recipient, "U" indicates an + unreliable message which MUST NOT be acknowledged. + + The SrcAddr field identifies the sender of a message. This MUST + be a complete address, with all address elements specified. The + addressing scheme is described in Section 4. + + The DestAddr field identifies the intended recipient(s) of the + message. This field MAY be wildcarded by omitting address + elements and hence address any number (including zero) of + application entities. The addressing scheme is described in + Section 4. + + The AckList field comprises a list of SeqNums for which this + message is an acknowledgment. See Section 7 for details. + + The header is followed by the message body which contains zero or + more commands to be delivered to the destination entity. The syntax + for a complete message is given in Section 5. + + If multiple commands are contained within the same Mbus message + payload, they MUST to be delivered to the Mbus application in the + same sequence in which they appear in the message payload. + + + + + + +Ott, et. al. Informational [Page 8] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +4. Addressing + + Each entity in the message has a unique Mbus address that is used to + identify the entity. Mbus addresses are sequences of 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 ...) + + The formal ABNF syntax definition for Mbus addresses and their + elements is as follows: + + mbus_address = "(" *WSP *1address_list *WSP ")" + address_list = address_element + / address_element 1*WSP address_list + + address_element = address_tag ":" address_value + + address_tag = 1*32(ALPHA) + + address_value = 1*64(%x21-27 / %x2A-7E) + ; any 7-bit US-ASCII character + ; excluding white space, delete, + ; control characters, "(" and ")" + + Note that this and other ABNF definitions in this document use the + non-terminal symbols defined in Section 2. + + An address_tag MUST be unique within an Mbus address, i.e., it MUST + only occur once. + + Each entity has a fixed sequence of address elements constituting its + address and MUST only process messages sent to addresses that either + match all elements or consist of a subset of its own address + elements. The order of address elements in an address sequence is + not relevant. Two address elements match if both their tags and + their values are equivalent. Equivalence for address element and + address value strings means that each octet in the one string has the + same value as the corresponding octet in the second string. For + example, an entity with an address of: + + (conf:test media:audio module:engine app:rat id:4711-1@192.168.1.1) + + will process messages sent to + + (media:audio module:engine) + + + + +Ott, et. al. Informational [Page 9] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + and + + (module:engine) + + but must ignore messages sent to + + (conf:test media:audio module:engine app:rat id:123-4@192.168.1.1 + foo:bar) + + and + + (foo:bar) + + A message that should be processed by all entities requires an empty + set of address elements. + +4.1 Mandatory Address Elements + + Each Mbus entity MUST provide one mandatory address element that + allows it to identify the entity. The element tag is "id" and the + value MUST be be composed of the following components: + + o The IP address of the interface that is used for sending messages + to the Mbus. For IPv4 this is the address in dotted decimal + notation. For IPv6 the interface-ID-part of the node's link-local + address in textual representation as specified in RFC 2373 [3] + MUST be used. + + In this specification, this part is called the "host-ID". + + o An identifier ("entity-ID") that is unique within the scope of a + single host-ID. The entity comprises two parts. For systems + where the concept of a process ID is applicable it is RECOMMENDED + that this identifier be composed using a process-ID and a per- + process disambiguator for different Mbus entities of a process. + If a process ID is not available, this part of the entity-ID may + be randomly chosen (it is recommended that at least a 32 bit + random number is chosen). Both numbers are represented in decimal + textual form and MUST be separated by a '-' (ASCII x2d) character. + + Note that the entity-ID cannot be the port number of the endpoint + used for sending messages to the Mbus because implementations MAY use + the common Mbus port number for sending to and receiving from the + multicast group (as specified in Section 6). + + The complete syntax definition for the entity identifier is as + follows: + + + + +Ott, et. al. Informational [Page 10] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + id-element = "id:" id-value + + id-value = entity-id "@" host-id + + entity-id = 1*10DIGIT "-" 1*5DIGIT + + host-id = (IPv4address / IPv6address) + + Please refer to [3] for the productions of IPv4address and IPv6address. + + An example for an id element: + + id:4711-99@192.168.1.1 + +5. Message Syntax + +5.1 Message Encoding + + 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 + that a message encoded with UTF-8 will not contain zero bytes. + + Each Message MAY be encrypted using a secret key algorithm as + defined in Section 11. + +5.2 Message Header + + The fields in the header are separated by white space characters, + and followed by CRLF. The format of the header is as follows: + + msg_header = "mbus/1.0" 1*WSP SeqNum 1*WSP TimeStamp 1*WSP + MessageType 1*WSP SrcAddr 1*WSP DestAddr 1*WSP AckList + + The header fields are explained in Message Format (Section 3). Here + are the ABNF syntax definitions for the header fields: + + SeqNum = 1*10DIGIT ; numeric range 0 - 2^32-1 + + TimeStamp = 1*13DIGIT + + MessageType = "R" / "U" + + ScrAddr = mbus_address + + DestAddr = mbus_address + + + + + + +Ott, et. al. Informational [Page 11] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + AckList = "(" *WSP *1(1*DIGIT *(1*WSP 1*10DIGIT)) *WSP ")" + + See Section 4 for a definition of "mbus_address". + + The syntax definition of a complete message is as follows: + + mbus_message = msg_header *1(CRLF msg_payload) + + msg_payload = mbus_command *(CRLF mbus_command) + + The definition of production rules for an Mbus command is given in + Section 5.3. + +5.3 Command Syntax + + The header is followed by zero, one, or more, commands to be + delivered to the Mbus entities indicated by the DestAddr field. Each + command consists of a command name that is followed by a list of + zero, or more parameters and is terminated by a newline. + + command ( parameter parameter ... ) + + Syntactically, the command name MUST be a `symbol' as defined in the + following table. The parameters MAY be any data type drawn from the + following table: + + val = Integer / Float / String / List / + Symbol / Data + + Integer = *1"-" 1*DIGIT + + Float = *1"-" 1*DIGIT "." 1*DIGIT + + String = DQUOTE *CHAR DQUOTE + ; see below for escape characters + + List = "(" *WSP *1(val *(1*WSP val)) *WSP ")" + + Symbol = ALPHA *(ALPHA / DIGIT / "_" / "-" / + ".") + + Data = "<" *base64 ">" + + Boolean values are encoded as an integer, with the value of zero + representing false, and non-zero representing true. + + + + + + +Ott, et. al. Informational [Page 12] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + String parameters in the payload MUST be enclosed in the double quote + (") character. Within strings, the escape character is the backslash + (\), and the following escape sequences are defined: + + +----------------+-----------+ + |Escape Sequence | Meaning | + +----------------+-----------+ + | \\ | \ | + | \" | " | + | \n | newline | + +----------------+-----------+ + + List parameters do not have to be homogeneous lists, i.e., they can + contain parameters of different types. + + Opaque data is represented as Base64-encoded (see RFC 1521 [7]) + character strings surrounded by "< " and "> " + + The ABNF syntax definition for Mbus commands is as follows: + + mbus_command = command_name arglist + + command_name = Symbol + + arglist = List + + Command names SHOULD be constructed hierarchically to group + conceptually related commands under a common hierarchy. The + delimiter between names in the hierarchy MUST be "." (dot). + Application profiles MUST NOT define commands starting with "mbus.". + + The Mbus addressing scheme defined in Section 4 allows specifying + incomplete addresses by omitting certain elements of an address + element list, enabling entities to send commands to a group of Mbus + entities. Therefore, all command names SHOULD be unambiguous in a + way that it is possible to interpret or ignore them without + considering the message's address. + + A set of commands within a certain hierarchy that MUST be understood + by every entity is defined in Section 9. + +6. Transport + + All messages are transmitted as UDP messages, with two possible + alternatives: + + + + + + +Ott, et. al. Informational [Page 13] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + 1. Local multicast/broadcast: + This transport class MUST be used for all messages that are not + sent to a fully qualified target address. It MAY also be used for + messages that are sent to a fully qualified target address. It + MUST be provided by conforming implementations. See Section 6.1 + for details. + + 2. Directed unicast: + This transport class MAY be used for messages that are sent to a + fully qualified destination address. It is OPTIONAL and does not + have to be provided by conforming implementations. + + A fully qualified target address is an Mbus address of an existing + Mbus entity in an Mbus session. An implementation can identify an + Mbus address as fully qualified by maintaining a list of known + entities within an Mbus session. Each known entity has its own + unique, fully qualified Mbus address. + + Messages are transmitted in UDP datagrams, a maximum message size of + 64 KBytes MUST NOT be exceeded. It is RECOMMENDED that applications + using a non host-local scope do not exceed a message size of the link + 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. + +6.1 Local Multicast/Broadcast + + In general, the Mbus uses multicast with a limited scope for message + transport. Two different Mbus multicast scopes are defined, either + of which can be configured to be used with an Mbus session: + + 1. host-local + + 2. link-local + + Participants of an Mbus session have to know the multicast address in + advance -- it cannot be negotiated during the session since it is + already needed for initial communication between the Mbus entities + during the bootstrapping phase. It also cannot be allocated prior to + an Mbus session because there would be no mechanism to announce the + allocated address to all potential Mbus entities. Therefore, the + multicast address has to be assigned statically. This document + defines the use of statically assigned addresses and also provides a + + + +Ott, et. al. Informational [Page 14] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + specification of how an Mbus session can be configured to use non- + standard, unassigned addresses (see Section 12). + + The following sections specify the use of multicast addresses for + IPv4 and IPv6. + +6.1.1 Mbus multicast groups for IPv4 + + For IPv4, a statically assigned, scope-relative multicast address as + defined by RFC 2365 [11] is used. The offset for the scope relative + address for Mbus is 8 (MBUS, see + http://www.iana.org/assignments/multicast-addresses [19]). + + Different scopes are defined by RFC 2365 [11]. The IPv4 Local Scope + (239.255.0.0/16) is the minimal enclosing scope for administratively + scoped multicast (as defined by RFC 2365 [11]) and not further + divisible -- its exact extent is site dependent. + + For the IPv4 Local Scope, applying the rules of RFC 2365 [11] and + using the assigned offset of 8, the Mbus multicast address is + therefore 239.255.255.247. + + For IPv4, the different defined Mbus scopes (host-local and link- + local) are to be realized as follows: + + host-local multicast: Unless configured otherwise, the assigned + scope-relative Mbus address in the Local Scope (239.255.255.247 as + of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent + with a TTL of 0. + + link-local multicast: Unless configured otherwise, the assigned + scope-relative Mbus address in the Local Scope (239.255.255.247 as + of RFC 2365 [11]) MUST be used. Mbus UDP datagrams SHOULD be sent + with a TTL of 1. + +6.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 [3]). 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. + + + +Ott, et. al. Informational [Page 15] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + The permanent IPv6 multicast address for Mbus/Ipv6 is + FF0X:0:0:0:0:0:0:300. + + FF0X:0:0:0:0:0:0:300 SHOULD be used for Mbus/IPv6 where the X in FF0X + indicates that the scope is not fixed because this is an all scope + address. This means, for node-local scope, FF01:0:0:0:0:0:0:300 + SHOULD be used and for link-local scope FF02:0:0:0:0:0:0:300 SHOULD + be used. See RFC 2375 [4] for IPv6 multicast address assignments. + + If a single application system is distributed across several co- + located hosts, link local scope SHOULD be used for multicasting Mbus + messages that potentially have recipients on the other hosts. The + Mbus protocol is not intended (and hence deliberately not designed) + for communication between hosts not on the same link. See Section 12 + for specifications of Mbus configuration mechanisms. + +6.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 12 for configuring the use of broadcast. + +6.1.4 Mbus UDP Port Number + + The registered Mbus UDP port number is 47000. + +6.2 Directed Unicast + + Directed unicast (via UDP) to the port of a specific application is + an alternative transport class to multicast. Directed unicast is an + OPTIONAL optimization and MAY be used by Mbus implementations for + delivering messages addressed to a single application entity only -- + the address of which the Mbus implementation has learned from other + message exchanges before. Note that the DestAddr field of such + messages MUST be filled in properly nevertheless. Every Mbus entity + SHOULD use a single unique endpoint address for sending messages to + the Mbus multicast group or to individual receiving entities. A + + + + +Ott, et. al. Informational [Page 16] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + unique endpoint address is a tuple consisting of the entity's IP + address and a UDP source port number, where the port number is + different from the standard Mbus port number. + + Messages MUST only be sent via unicast if the Mbus target address is + unique and if the sending entity can verify that the receiving entity + uses a unique endpoint address. The latter can be verified by + considering the last message received from that entity. + + Note that several Mbus entities, say within the same process, may + share a common transport address; in this case, the contents of + the destination address field is used to further dispatch the + message. Given the definition of "unique endpoint address" above, + the use of a shared endpoint address and a dispatcher still allows + other Mbus entities to send unicast messages to one of the + entities that share the endpoint address. So this can be + considered an implementation detail. + + Messages with an empty target address list MUST always be sent to all + Mbus entities (via multicast if available). + + The following algorithm can be used by sending entities to determine + whether an Mbus address is unique considering the current set of Mbus + entities: + + let ta=the target address; + iterate through the set of all + currently known Mbus addresses { + let ti=the address in each iteration; + count the addresses for which + the predicate isSubsetOf(ta,ti) yields true; + } + + If the count of matching addresses is exactly 1 the address is + unique. The following algorithm can be used for the predicate + isSubsetOf, that checks whether the second message matches the + first according to the rules specified in Section 4. (A match + means that a receiving entity that uses the second Mbus address + must also process received messages with the first address as a + target address.) + + isSubsetOf(addr a1,a2) yields true, iff + every address element of a1 is contained + in a2's address element list. + + + + + + + +Ott, et. al. Informational [Page 17] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + An address element a1 is contained in an address element list if + the list contains an element that is equal to a1. An address + element is considered equal to another address element if it has + the same values for both of the two address element fields (tag + and value). + +7. Reliability + + While most messages are expected to be sent using unreliable + transport, it may be necessary to deliver some messages reliably. + Reliability can be selected on a per message basis by means of the + MessageType field. Reliable delivery is supported for messages with + a single recipient only; i.e., to a fully qualified Mbus address. An + entity can thus only send reliable messages to known addresses, i.e., + it can only send reliable messages to entities that have announced + their existence on the Mbus (e.g., by means of mbus.hello() messages + as defined in Section 9.1). A sending entity MUST NOT send a message + reliably if the target address is not unique. (See Section 6 for the + specification of an algorithm to determine whether an address is + unique.) A receiving entity MUST only process and acknowledge a + reliable message if the destination address exactly matches its own + source address (the destination address MUST NOT be a subset of the + source address). + + Disallowing reliable message delivery for messages sent to multiple + destinations is motivated by simplicity of the implementation as well + as the protocol. The desired effect can be achieved at the + application layer by sending individual reliable messages to each + fully qualified destination address, if the membership information + for the Mbus session is available. + + Each message is tagged with a message sequence number. If the + MessageType is "R", the sender expects an acknowledgment from the + recipient within a short period of time. If the acknowledgment is + not received within this interval, the sender MUST retransmit the + message (with the same message sequence number), increase the + timeout, and restart the timer. Messages MUST be retransmitted a + small number of times (see below) before the transmission or the + recipient are considered to have failed. If the message is not + delivered successfully, the sending application is notified. In this + case, it is up to the application to determine the specific actions + (if any) to be taken. + + + + + + + + + +Ott, et. al. Informational [Page 18] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + Reliable messages MUST be acknowledged by adding their SeqNum to the + AckList field of a message sent to the originator of the reliable + message. This message MUST be sent to a fully qualified Mbus target + address. Multiple acknowledgments MAY be sent in a single message. + Implementations MAY either piggy-back the AckList onto another + message sent to the same destination, or MAY send a dedicated + acknowledgment message, with no commands in the message payload part. + + The precise procedures are as follows: + + Sender: A sender A of a reliable message M to receiver B MUST + transmit the message either via IP-multicast or via IP-unicast, + keep a copy of M, initialize a retransmission counter N to '1', + and start a retransmission timer T (initialized to T_r). If an + acknowledgment is received from B, timer T MUST be cancelled and + the copy of M is discarded. If T expires, the message M MUST be + retransmitted, the counter N MUST be incremented by one, and the + timer MUST be restarted (set to N*T_r). If N exceeds the + retransmission threshold N_r, the transmission is assumed to have + failed, further retransmission attempts MUST NOT be undertaken, + the copy of M MUST be discarded, and the sending application + SHOULD be notified. + + Receiver: A receiver B of a reliable message from a sender A MUST + acknowledge reception of the message within a time period T_c < + T_r. This MAY be done by means of a dedicated acknowledgment + message or by piggy-backing the acknowledgment on another message + addressed only to A. + + Receiver optimization: In a simple implementation, B may choose to + immediately send a dedicated acknowledgment message. However, for + efficiency, it could add the SeqNum of the received message to a + sender-specific list of acknowledgments; if the added SeqNum is + the first acknowledgment in the list, B SHOULD start an + acknowledgment timer TA (initialized to T_c). When the timer + expires, B SHOULD create a dedicated acknowledgment message and + send it to A. If B is to transmit another Mbus message addressed + only to A, it should piggy-back the acknowledgments onto this + message and cancel TA. In either case, B should store a copy of + the acknowledgment list as a single entry in the per-sender copy + list, keep this entry for a period T_k, and empty the + acknowledgment list. In case any of the messages kept in an entry + of the copy list is received again from A, the entire + acknowledgment list stored in this entry is scheduled for (re-) + transmission following the above rules. + + + + + + +Ott, et. al. Informational [Page 19] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + Constants and Algorithms: The following constants and algorithms + SHOULD be used by implementations: + + T_r=100ms + + N_r=3 + + T_c=70ms + + T_k=((N_r)*(N_r+1)/2)*T_r + +8. Awareness of other Entities + + Before Mbus entities can communicate with one another, they need to + mutually find out about their existence. After this bootstrap + procedure that each Mbus entity goes through all other entities + listening to the same Mbus know about the newcomer and the newcomer + has learned about all the other entities. Furthermore, entities need + to be able to to notice the failure (or leaving) of other entities. + + Any Mbus entity MUST announce its presence (on the Mbus) after + starting up. This is to be done repeatedly throughout its lifetime + to address the issues of startup sequence: Entities should always + become aware of other entities independent of the order of starting. + + Each Mbus entity MUST maintain the number of Mbus session members and + continuously update this number according to any observed changes. + The mechanisms of how the existence and the leaving of other entities + can be detected are dedicated Mbus messages for 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 + message the respective entity is considered to have left the Mbus as + well and MUST be excluded from the set of currently known entities + immediately. + + Each Mbus entity MUST send hello messages to the Mbus after startup. + After transmission of the hello message, it MUST start a timer 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 + dependent on the current number of entities in an Mbus group and can + thus change dynamically in order to avoid congestion due to many + entities sending hello messages at a constant high rate. + + + +Ott, et. al. Informational [Page 20] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + Section 8.1 specifies the calculation of hello message intervals 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 the number of entities in an Mbus session may vary, care must + be taken to allow the Mbus protocol to automatically scale over a + wide range of group sizes. 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 an + 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 implementors 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 an 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 session and is still learning of the + existence of other entities or when a larger number of entities + leaves the Mbus at once. + + + + + + + + + + +Ott, et. al. Informational [Page 21] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +8.1.1 Calculating the Interval for Hello Messages + + The following variable names 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, denoted + hello_d. The minimum value for hello_d is c_hello_min which yields + + hello_d = max(c_hello_min,c_hello_factor * entities * 1ms). + + 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 as follows: + + hello_e = c_hello_dither_min + + RND * (c_hello_dither_max - c_hello_dither_min) + + with RND being a random function that yields an even distribution + between 0 and 1. See also Section 10. + + hello_n, the time for the next hello message in milliseconds is set + to hello_e + hello_now. + + + +Ott, et. al. Informational [Page 22] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +8.1.2 Initialization of Values + + Upon joining an Mbus session a protocol implementation sets + hello_p=0, hello_now=0 and entities=1, entities_p=1 (the 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 = hello_now + + (entities/entities_p)*(hello_n - hello_now) + + 2. The value for hello_p is updated by setting hello_p = hello_now - + (entities/entities_p)*(hello_now - hello_p) + + 3. The currently active timer for the next hello messages 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. + + 1. IF hello_e + hello_p <= hello_now THEN 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. + + + +Ott, et. al. Informational [Page 23] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + 2. ELSE IF hello_e + hello_p > hello_now THEN hello_n is set 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 Mbus Entities + + 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. See Section 8.1.4 for details. 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; these messages are + required for proper operation of the Mbus. This specification does + not contain application-specific messages. These are to be defined + outside of the basic Mbus protocol specification in separate Mbus + profiles. + +9.1 mbus.hello + + Syntax: + mbus.hello() + + Parameters: - none - + + mbus.hello messages MUST be sent unreliably to all Mbus entities. + + Each Mbus entity learns about other Mbus entities by observing their + mbus.hello messages and tracking the sender address of each message + and can thus calculate the current number of entities. + + mbus.hello messages MUST be sent periodically in dynamically + calculated intervals as specified in Section 8. + + Upon startup the first mbus.hello message MUST be sent after a delay + hello_delay, where hello_delay be a randomly chosen number between 0 + and c_hello_min (see Section 10). + + + + +Ott, et. al. Informational [Page 24] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +9.2 mbus.bye + + Syntax: mbus.bye() + + Parameters: - none - + + An Mbus entity that is about to terminate (or "detach" from the Mbus) + SHOULD announce this by transmitting an mbus.bye message. The + mbus.bye message MUST be sent unreliably to all entities. + +9.3 mbus.ping + + Syntax: mbus.ping() + + Parameters: - none - + + mbus.ping can be used to solicit other entities to signal their + existence by replying with an mbus.hello message. Each protocol + implementation MUST understand mbus.ping and reply with an 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). Several mbus.ping messages MAY be + answered by a single mbus.hello: if one or more further mbus.ping + messages are received while the entity is waiting hello_delay time + units before transmitting the mbus.hello message, no extra mbus.hello + message need be scheduled for those additional mbus.ping messages. + + As specified in Section 9.1 hello messages MUST be sent unreliably to + all Mbus entities. This is also the case for replies to ping + messages. 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. + + + + + + + + + + + +Ott, et. al. Informational [Page 25] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +9.4 mbus.quit + + Syntax: + mbus.quit() + + Parameters: - none - + + The mbus.quit message is used to request other entities to terminate + themselves (and detach from the Mbus). Whether this request is + honoured by receiving entities or not is application specific and + not defined in this document. + + The mbus.quit message can be multicast or sent reliably via unicast + to a single Mbus entity or a group of entities. + +9.5 mbus.waiting + + Syntax: + mbus.waiting(condition) + + Parameters: + + symbol condition + The condition parameter is used to indicate that the entity + transmitting this message is waiting for a particular event to + occur. + + An Mbus entity SHOULD be able to indicate that it is waiting for a + certain event to happen (similar to a P() operation on a semaphore + but without creating external state somewhere else). In conjunction + with this, an Mbus entity SHOULD be capable of indicating to another + entity that this condition is now satisfied (similar to a semaphore's + V() operation). + + The mbus.waiting message MAY be broadcast to all Mbus entities, MAY + be multicast to an arbitrary subgroup, or MAY be unicast to a + particular peer. Transmission of the mbus.waiting message MUST be + unreliable and hence MUST be repeated at an application-defined + interval (until the condition is satisfied). + + If an application wants to indicate that it is waiting for several + conditions to be met, several mbus.waiting messages are sent + (possibly included in the same Mbus payload). Note that mbus.hello + and mbus.waiting messages may also be transmitted in a single Mbus + payload. + + + + + + +Ott, et. al. Informational [Page 26] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +9.6 mbus.go + + Syntax: + mbus.go(condition) + + Parameters: + + symbol condition + This parameter specifies which condition is met. + + The mbus.go message is sent by an Mbus entity to "unblock" another + Mbus entity -- which has indicated that it is waiting for a certain + condition to be met. Only a single condition can be specified per + mbus.go message. If several conditions are satisfied simultaneously + multiple mbus.go messages MAY be combined in a single Mbus payload. + + The mbus.go message MUST be sent reliably via unicast to the Mbus + entity to unblock. + +10. Constants + + The following values for timers and counters mentioned in this + document SHOULD be used by implementations: + + +-------------------+------------------------+--------------+ + |Timer / Counter | Value | Unit | + +-------------------+------------------------+--------------+ + |c_hello_factor | 200 | - | + |c_hello_min | 1000 | milliseconds | + |c_hello_dither_min | 0.9 | - | + |c_hello_dither_max | 1.1 | - | + |c_hello_dead | 5 | - | + +-------------------+------------------------+--------------+ + + T_r=100ms + + N_r=3 + + T_c=70ms + + T_k=((N_r)*(N_r+1)/2)*T_r + + + + + + + + + + +Ott, et. al. Informational [Page 27] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +11. Mbus Security + +11.1 Security Model + + In order to prevent accidental or malicious disturbance of Mbus + communications through messages originated by applications from other + users, message authentication is deployed (Section 11.3). For each + message, a digest MUST be calculated based on the value of a shared + secret key value. Receivers of messages MUST check if the sender + belongs to the same Mbus security domain by re-calculating the digest + and comparing it to the received value. The messages MUST only be + processed further if both values are equal. In order to allow + different simultaneous Mbus sessions at a given scope and to + compensate defective implementations of host local multicast, message + authentication MUST be provided by conforming implementations. + + Privacy of Mbus message transport can be achieved by optionally using + symmetric encryption methods (Section 11.2). Each message MAY be + encrypted using an additional shared secret key and a symmetric + encryption algorithm. Encryption is OPTIONAL for applications, i.e., + it is allowed to configure an Mbus domain not to use encryption. But + conforming implementations MUST provide the possibility to use + message encryption (see below). + + Message authentication and encryption can be parameterized: the + algorithms to apply, the keys to use, etc. These and other + parameters are defined in an Mbus configuration object that is + accessible by all Mbus entities that participate in an Mbus session. + In order to achieve interoperability conforming implementations + SHOULD use the values provided by such an Mbus configuration. + Section 12 defines the mandatory and optional parameters as well as + storage procedures for different platforms. Only in cases where none + of the options mentioned in Section 12 is applicable alternative + methods of configuring Mbus protocol entities MAY be deployed. + + The algorithms and procedures for applying encryption and + authentication techniques are specified in the following sections. + +11.2 Encryption + + Encryption of messages is OPTIONAL, that means, an Mbus MAY be + configured not to use encryption. + + + + + + + + + +Ott, et. al. Informational [Page 28] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + Implementations can choose between different encryption algorithms. + Every conforming implementation MUST provide the AES [18] algorithm. + In addition, the following algorithms SHOULD be supported: DES [16], + 3DES (triple DES) [16] and IDEA [20]. + + For algorithms requiring en/decryption data to be padded to certain + boundaries octets with a value of 0 SHOULD be used for padding + characters. + + The length of the encryption keys is determined by the currently used + encryption algorithm. This means, the configured encryption key MUST + NOT be shorter than the native key length for the currently + configured algorithm. + + DES implementations MUST use the DES Cipher Block Chaining (CBC) + mode. DES keys (56 bits) MUST be encoded as 8 octets as described in + RFC 1423 [12], resulting in 12 Base64-encoded characters. IDEA uses + 128-bit keys (24 Base64-encoded characters). AES can use either + 128-bit, 192-bit or 256-bit keys. For Mbus encryption using AES only + 128-bit keys (24 Base64-encoded characters) MUST be used. + +11.3 Message Authentication + + For authentication of messages, hashed message authentication codes + (HMACs) as described in RFC 2104 [5] are deployed. In general, + implementations can choose between a number of digest algorithms. + For Mbus authentication, the HMAC algorithm MUST be applied in the + following way: + + The keyed hash value is calculated using the HMAC algorithm + specified in RFC 2104 [5]. The specific hash algorithm and the + secret hash key MUST be obtained from the Mbus configuration (see + Section 12). + + The keyed hash values (see RFC 2104 [5]) MUST be truncated to 96 + bits (12 octets). + + Subsequently, the resulting 12 octets MUST be Base64-encoded, + resulting in 16 Base64-encoded characters (see RFC 1521 [7]). + + Either MD5 [15] or SHA-1 [17] 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. + + + + +Ott, et. al. Informational [Page 29] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +11.4 Procedures for Senders and Receivers + + The algorithms that MUST be provided by implementations are AES and + SHA-1. + + See Section 12 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 11.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 16 + Base64-characters as specified in Section 11.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 (encrypted) 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 be discarded without further processing. + + 4. If encryption is enabled, the message MUST be decrypted using the + configured algorithm and the configured encryption key. Trailing + octets with a value of 0 MUST be deleted. If the message does not + + + +Ott, et. al. Informational [Page 30] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + start with the string "mbus/" the message MUST be discarded + without further processing. + +12. Mbus Configuration + + An implementation MUST be configurable by the following parameters: + + Configuration version + + The version number of the given configuration entity. Version + numbers allow implementations to check if they can process the + entries of a given configuration entity. Version number are + integer values. The version number for the version specified + here is 1. + + Encryption key + + The secret key used for message encryption. + + Hash key + + The hash key used for message authentication. + + Scope + + The multicast scope to be used for sent messages. + + The above parameters are mandatory and MUST be present in every Mbus + configuration entity. + + The following parameters are optional. When they are present they + MUST be honored. When they are not present implementations SHOULD + fall back to the predefined default values (as defined in Transport + (Section 6)): + + Address + + The non-standard multicast address to use for message + transport. + + 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 6.1.3) + instead of the standard multicast address. + + + + + +Ott, et. al. Informational [Page 31] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + Port Number + + The non-standard UDP port number to use for message transport. + + Two distinct facilities for parameter storage are considered: For + Unix-like systems a per-user configuration file SHOULD be used and + for Windows-95/98/NT/2000/XP systems a set of registry entries is + defined 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 remains + the same for both configuration facilities. The following defines a + set of ABNF (see RFC 2234 [13]) productions that are later re-used + for the definitions for the configuration file syntax and registry + entries: + + algo-id = "NOENCR" / "AES" / "DES" / "3DES" / "IDEA" / + "HMAC-MD5-96" / "HMAC-SHA1-96" + + scope = "HOSTLOCAL" / "LINKLOCAL" + + key = base64 + + version_number = 1*10DIGIT + + key_value = "(" algo-id "," key ")" + + address = IPv4address / IPv6address / "BROADCAST" + + port = 1*5DIGIT ; values from 0 through 65535 + + Given the definition above, a key entry MUST be specified using this + notation: + + "("algo-id","base64string")" + + algo-id is one of the character strings specified above. For algo- + id=="NOENCR" the other fields are ignored. The delimiting commas + MUST always be present though. + + A Base64 string consists of the characters defined in the Base64 + char-set (see RFC 1521 [7]) including all possible padding + characters, 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 + may be set to either "HOSTLOCAL" or "LINKLOCAL". Implementations + SHOULD choose an appropriate IP-Multicast scope depending on the + + + +Ott, et. al. Informational [Page 32] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + value of this parameter and construct an effective IP-Address + considering the specifications of Section 6.1. + + The use of broadcast is configured by providing the value "BROADCAST" + for the address field. If broadcast has been configured, + implementations SHOULD use the network broadcast address for the used + IP version instead of the standard multicast address. + + The version_number parameter specifies a version number for the used + configuration entity. + +12.1 File based parameter storage + + The file name for an Mbus configuration file is ".mbus" in the user's + home-directory. If an environment variable called MBUS is defined + implementations SHOULD interpret the value of this variable as a + fully qualified file name that is to be used for the configuration + file. Implementations MUST ensure that this file has appropriate + file permissions that prevent other users to read or write it. The + file MUST exist before a conference is initiated. Its contents MUST + be UTF-8 encoded and MUST comply to the following syntax definition: + + mbus-file = mbus-topic LF *(entry LF) + + mbus-topic = "[MBUS]" + + entry = 1*(version_info / hashkey_info + / encryptionkey_info / scope_info + / port_info / address_info) + + version_info = "CONFIG_VERSION=" version_number + + hashkey_info = "HASHKEY=" key_value + + encrkey_info = "ENCRYPTIONKEY=" key_value + + scope_info = "SCOPE=" scope + + port_info = "PORT=" port + + address_info = "ADDRESS=" address + + The following entries are defined: CONFIG_VERSION, HASHKEY, + ENCRYPTIONKEY, SCOPE, PORT, ADDRESS. + + The entries CONFIG_VERSION, HASHKEY and ENCRYPTIONKEY are mandatory, + they MUST be present in every Mbus configuration file. The order of + entries is not significant. + + + +Ott, et. al. Informational [Page 33] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + An example for an Mbus configuration file: + + [MBUS] + CONFIG_VERSION=1 + HASHKEY=(HMAC-MD5-96,MTIzMTU2MTg5MTEy) + ENCRYPTIONKEY=(DES,MTIzMTU2MQ==) + SCOPE=HOSTLOCAL + ADDRESS=224.255.222.239 + PORT=47000 + +12.2 Registry-based parameter storage + + For systems lacking the concept of a user's home-directory as a place + for configuration files the suggested database for configuration + settings (e.g., the Windows9x, Windows NT, Windows 2000, Windows XP + registry) SHOULD be used. The hierarchy for Mbus related registry + entries is as follows: + + HKEY_CURRENT_USER\Software\Mbus + + The entries in this hierarchy section are: + + +---------------+--------+----------------+ + |Name | Type | ABNF production| + +---------------+--------+----------------| + |CONFIG_VERSION | DWORD | version_number | + |HASHKEY | String | key_value | + |ENCRYPTIONKEY | String | key_value | + |SCOPE | String | scope | + |ADDRESS | String | address | + |PORT | DWORD | port | + +---------------+--------+----------------+ + + The same syntax for key values as for the file based configuration + facility MUST be used. + +13. Security Considerations + + The Mbus security mechanisms are specified in Section 11.1. + + It should be noted that the Mbus transport specification defines a + mandatory baseline set of algorithms that have to be supported by + implementations. This baseline set is intended to provide reasonable + security by mandating algorithms and key lengths that are considered + to be cryptographically strong enough at the time of writing. + + However, in order to allow for efficiency it is allowable to use + cryptographically weaker algorithms, for example HMAC-MD5 instead of + + + +Ott, et. al. Informational [Page 34] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + HMAC-SHA1. Furthermore, encryption can be turned off completely if + privacy is provided by other means or not considered important for a + certain application. + + Users of the Mbus should therefore be aware of the selected security + configuration and should check if it meets the security demands for a + given application. Since every implementation MUST provide the + cryptographically strong algorithm it should always be possible to + configure an Mbus in a way that secure communication with + authentication and privacy is ensured. + + In any way, application developers should be aware of incorrect IP + implementations that do not conform to RFC 1122 [2] and do send + datagrams with TTL values of zero, resulting in Mbus messages sent to + the local network link although a user might have selected host local + scope in the Mbus configuration. When using 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. + +14. IANA Considerations + + The IANA has assigned a scope-relative multicast address with an + offset of 8 for Mbus/IPv4. The IPv6 permanent multicast address is + FF0X:0:0:0:0:0:0:300. + + The registered Mbus UDP port number is 47000. + +15. References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [2] Braden, R., "Requirements for Internet Hosts -- Communication + Layers", STD 3, RFC 1122, October 1989. + + [3] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + + [4] Hinden, R. and S. Deering, "IPv6 Multicast Address + Assignments", RFC 2375, July 1998. + + [5] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing + for Message Authentication", RFC 2104, February 1997. + + [6] Resnick, P., Editor, "Internet Message Format", RFC 2822, April + 2001. + + + + +Ott, et. al. Informational [Page 35] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + + [7] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail + Extensions) Part One: Mechanisms for Specifying and Describing + the Format of Internet Message Bodies", RFC 1521, September + 1993. + + [8] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobsen, + "RTP: A Transport Protocol for Real-Time Applications", RFC + 1889, January 1996. + + [9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, + "SIP: Session Initiation Protocol", RFC 2543, March 1999. + + [10] Handley, M. and V. Jacobsen, "SDP: Session Description + Protocol", RFC 2327, April 1998. + + [11] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC + 2365, July 1998. + + [12] Balenson, D., "Privacy Enhancement for Internet Electronic + Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, + February 1993. + + [13] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [14] Myers, J., "SMTP Service Extension for Authentication", RFC + 2554, March 1999. + + [15] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [16] 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. + + [17] U.S. DEPARTMENT OF COMMERCE/National Institute of Standards and + Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995. + + [18] Daemen, J.D. and V.R. Rijmen, "AES Proposal: Rijndael", March + 1999. + + [19] IANA, "Internet Multicast Addresses", URL + http://www.iana.org/assignments/multicast-addresses, May 2001. + + [20] Schneier, B., "Applied Cryptography", Edition 2, Publisher John + Wiley & Sons, Inc., status: non-normative, 1996. + + + + +Ott, et. al. Informational [Page 36] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +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. + + + + + + + + + + + + + + + +Ott, et. al. Informational [Page 37] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +Authors' Addresses + + Joerg Ott + TZI, Universitaet Bremen + Bibliothekstr. 1 + Bremen 28359 + Germany + + Phone: +49.421.201-7028 + Fax: +49.421.218-7000 + EMail: jo@tzi.uni-bremen.de + + + Colin Perkins + USC Information Sciences Institute + 3811 N. Fairfax Drive #200 + Arlington VA 22203 + USA + + EMail: csp@isi.edu + + + Dirk Kutscher + TZI, Universitaet Bremen + Bibliothekstr. 1 + Bremen 28359 + Germany + + Phone: +49.421.218-7595 + Fax: +49.421.218-7000 + EMail: dku@tzi.uni-bremen.de + + + + + + + + + + + + + + + + + + + + +Ott, et. al. Informational [Page 38] + +RFC 3259 A Message Bus for Local Coordination April 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Ott, et. al. Informational [Page 39] + |