📄 rfc3259.txt
字号:
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -