Requirements for the XCON-DCON Synchronization Protocol

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.