GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3259

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3259.txt · Last modified: 2002/05/10 20:21 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki