Requirements for the XCON-DCON Synchronization Protocol
University of Napoli
Via Claudio 21
80125
Napoli
Italy
spromano@unina.it
University of Napoli
Via Claudio 21
80125
Napoli
Italy
alessandro.amirante@unina.it
University of Napoli
Via Claudio 21
80125
Napoli
Italy
tobia.castaldi@unina.it
University of Napoli
Via Claudio 21
80125
Napoli
Italy
lorenzo.miniero@unina.it
Ansaldo Trasporti e Sistemi Ferroviari
Via Argine, 425
80147
Napoli
Italy
alfonso.buono@atsf.it
RAI
Network Working Group
Distributed
Conferencing
Centralized Conferencing (XCON)
Protocol
The Distributed Conferencing (DCON) framework provides the means to
distribute Centralized Conference (XCON) information by appropriately
orchestrating a number of centralized focus entities (clouds).
The mechanism we propose to make each XCON cloud communicate
with its related DCON peer is based on the use of some kind
of XCON-DCON Synchronization Protocol (XDSP). This
document gives the requirements for XDSP.
The Distributed Conferencing framework
describes the requirements for the overall architecture, terminology, and protocol components needed
for distribuited conferencing. DCON is based on the idea that a distributed
conference can be setup and accessed by appropriately orchestrating the
operation of a number of XCON "focus" elements, each in charge of
managing a certain number of participants. Each pair composed of a centralized
focus entity (XCON) and its related distributed counterpart (namely, a DCON
focus) is called "island", or "cloud". These islands are then made part of an
overlay network composed of several inter-communicating clouds.
Interaction between each participant and the corresponding conference
focus is based on the standard XCON framework
, whereas inter-focus interaction
is based on a peer-to-peer paradigm. The interaction between the
centralized conference focus and the distributed conference focus, instead,
has requirements that are defined in this document.
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",
"NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 and indicate
requirement levels for compliant implementations.
Distributed conferencing uses, when appropriate, and expands on the
terminology introduced in the both the SIPPING
and XCON conferencing frameworks.
The following additional terms are defined for specific use within the
distributed conferencing work.
A specific pair composed of a centralized focus entity (XCON) and
its associated distributed focus (DCON). We will herein indifferently
use both "cloud" and "island" to refer to a conferencing cloud.
A specific entity enabling communication of a centralized conferencing
system with the outside world. A DCON focus allows for the construction
of a distributed conferencing system as a federation of centralized
conferencing components.
The capability to detect the presence of new focus entities in a
distributed conferencing framework.
The spreading of conference related information
among the focus entities in a distributed environment.
The capabilty of appropriately forwarding/distributing messages of
a natively centralized protocol in order to let them spread across a
distributed environment.
The opportune swap of labels assigned to a specific resource, needed
to avoid conflicts in the assignment of labels across several point-to-point
communications regarding the same resource.
This section describes requirements for the XCON-DCON synchronization
protocol (XDSP).
XDSP protocol MUST be a reliable client-server protocol. Hence, it
MUST have a positive response indicating that the request has been
received, or an error response in case an error has occurred.
It MUST be possible for the XCON focus entity, the server, to
authenticate the related DCON focus entity, the client.
It MUST be possible for the DCON focus entity to be authenticated by
the server, the related XCON focus entity.
It MUST be possible to ensure message integrity between
each pair of XCON and DCON focus entities.
It MUST be possible for the involved XCON and DCON entities
to communicate on a stateless synchronous request-response based
mechanism.
An error message MUST be sent back to the entity placing the
request, in case the message couldn't be processed
for any reason.
An authentication mechanism SHOULD be made possible on the basis
of such stateless synchronous request-response based interaction
between the two involved entities.
It SHOULD be possible for the XCON focus entity to request access
to remote (e.g. avaliable on different islands) resources by means
of an answer sent to the related DCON focus entity. This includes
requesting a join to a remote conference for a local user,
setting up distributed conferences, actively requesting the
list of all the remote conferences and/or the list of all users
(remote and local) in a currently running conference, etc..
The DCON focus entity SHALL forward any request directed to resources
available in the related XCON cloud to the related XCON focus entity
which will manage it and properly answer the request.
It SHOULD be possible for the DCON focus entity to subscribe
to the related XCON focus entity for events related to the
conference system state, in order to receive asynchronous
notifications.
The XCON focus entity SHALL generate new asynchronous
notifications every time there is any change in the
state of any of the conferences it is currently handling.
It SHOULD be possible for the DCON focus entity to receive
full state updates from the related XCON focus entity, in case
some of the events were missed, to make the known
state consistent with the actual conference system internal state.
Both partial notifications and full updates SHOULD be
sent through the same authenticated channel used for XDSP
communication. In case a separate channel and/or a separate
protocol are used (e.g. by means of the XCON event package,
when it is available, or of the already available SIPPING conference
event package ), the same issues
about security and integrity SHOULD be addressed to avoid attacks
and exploits by unauthenticated users.
Since state changes might happen in both the involved focus entities
(even though related to different situations) the same requirements
just described for notifications generated by XCON focus entities
should be addressed for their related DCON focus entities. It
SHOULD be possible for the XCON focus entity to subscribe
to the related DCON focus entity for events related to the
conference system state, in order to receive asynchronous
notifications.
The DCON focus entity SHALL generate new asynchronous
notifications every time there is any change in its internal
state, e.g. whenever new remote conferences have been created
or become active, etc.
It SHOULD be possible for the XCON focus entity to receive
full state updates from the related DCON focus entity, in case
some of the events were missed, to make the known
state consistent with the actual conference system internal state.
The XCON focus entity MUST forward any centralized protocol message
to its related DCON focus entity whenever the message is to be
received by a peer who is not a local entity of the centralized
system. Natively centralized protocol messages include, but are not
limited to, any protocol defined and specified in the XCON
framework (e.g. conference control management and floor control)
as well as DTMF messages propagation. An example is represented by
BFCP messages the local floor control server might need to send to a
user who is remotely (i.e. a user who does not belong to the current
XCON cloud) participating in the conference. Another example concerns
BFCP messages a local user might want to send to the remote floor
control server handling the remote, distributed, conference the user
is participating in.
Any message sent by local entities to local entities has to be treated
in the usual centralized way according to the relative protocol
specifications (i.e. dispatching shall not be involved).
The DCON focus entity MUST forward any natively centralized protocol
message it receives from DCON focus peers in the distributed
overlay (routing) to the related XCON focus entity (dispatching),
whenever the message is addressed to any of the local entities of
the centralized cloud.
The XCON and DCON focus entities MUST establish and mantain
opportune labels to correctly address and identify local entities
involved in routed and dispatched messages. These labels MUST
be appropriately swapped whenever they leave a DCON focus
entity and reach a foreign one, so to avoid conflicts upon assigned
labels in different islands.
Message dispatching between the two involved focus entities SHOULD
occur on an request-response based communication mechanism, and
opportune errors should be generated in case any exceptional condition
happens while processing the messages.
The communication between each DCON focus entity and its related
XCON entity contains sensitive information, since it envisages the
possibility to spread important information that only authorized entities
should be aware of (e.g. the full internal state of the centralized conference
objects and relevant privacy information about users authenticated
by the system).
Hence it is very important that protocol messages be protected because
otherwise an attacker might spoof the legitimate identity of the DCON focus
entity and/or inject messages on his behalf. Many obvious consequences
could come out of such an undesirable situation.
To mitigate the above threats, both the DCON focus entity and the XCON
focus entity SHOULD be authenticated upon initial contact. All protocol
messages SHOULD be authenticated and integrity-protected to prevent
third-party intervention and MITM (Man-In-The-Middle) attacks.
All messages SHOULD be encrypted to prevent eavesdropping.