Requirements for Distributed Conferencing
draft-romano-dcon-requirements-06

Abstract

This document examines the requirements for Distributed Conferencing (DCON). Separate documents will map the requirements to existing protocol primitives, define new protocol extensions, and introduce new protocols as needed. Together, these documents will provide a guideline for building interoperable conferencing applications. The current works in SIPPING and XCON working groups marginally address the matter, which is nonetheless considered as out-of-scope. The requirements listed in this document are in part based on thoughts derived from the cited working groups activities.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on July 11, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License.

Table of Contents

1.  Introduction
2.  Conventions
3.  Terminology
4.  Related work: Cascaded Conferencing
5.  Requirements
6.  Security Considerations
7.  References
§  Authors' Addresses

1.  Introduction

This document examines the requirements for an architecture capable to provide a distributed conferencing service. It draws inspiration from a number of existing research efforts inside the IETF, mainly in the context of both the SIPPING and the XCON WGs. We will herein present high-level requirements, starting from considerations upon the well-known concept of cascaded conferencing [RFC5239] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” June 2008.)[RFC4575] (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.).

2.  Conventions

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 [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) and indicate requirement levels for compliant implementations.

3.  Terminology

Distributed conferencing uses, when appropriate, and expands on the terminology introduced in both the SIPPING [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) and XCON [RFC5239] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” June 2008.) conferencing frameworks. The following additional terms are defined for specific use within the distributed conferencing work.

Focus Discovery -- this term refers to the capability to detect the presence of new focus entities in a distributed conferencing framework.

Information Spreading -- this term refers to the spreading of conference related information among the focus entities in a distributed environment.

Protocol Dispatching -- this term refers to the capabilty of appropriately forwarding/distributing messages of a natively centralized protocol in order to let them spread across a distributed environment.

DCON Focus -- this term refers to 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.

Conferencing Cloud -- this term refers to 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.

4.  Related work: Cascaded Conferencing

The requirements for a distributed conferencing framework have already been partially addressed in previous works within the IETF. Specifically, RFC 4245 (High-Level Requirements for Tightly Coupled SIP Conferencing) [RFC4245] (Levin, O. and R. Even, “High-Level Requirements for Tightly Coupled SIP Conferencing,” November 2005.) introduces the concept of cascading of conferences and illustrates three different scenarios to which it might be applied: (i) peer-to-peer chaining of signaling; (ii) conferences having hierarchal signaling relations; (iii) cascading as a means to distribute the media "mixing". For the three scenarios above, a number of possible requirements are identified, among which the availability of a SIMPLE-based Presence and Instant Messaging architecture plays a major role.

The concept of cascaded conferences is further expanded in RFC 4353 [RFC4353] (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.) (A Framework for Conferencing with the Session Initiation Protocol (SIP)), where the term "Cascaded Conferencing" is used to indicate "a mechanism for group communications in which a set of conferences are linked by having their focuses interact in some fashion". In the same document, a specific scenario called "Simplex Cascaded Conferences" is presented as a typical interaction paradigm envisaging that the user agent representing the focus of one conference is a conference-unaware participant in another conference. In other terms, a conference "calls" another conference and gets connected to it as if it were a simple participant. For both such conferences, the peering party is just like any other user participating in the conferencing session. For the sake of completeness, we remark that the previous observation is somehow confuted by RFC 4575 (A Session Initiation Protocol Event Package for Conference State) [RFC4353] (Rosenberg, J., “A Framework for Conferencing with the Session Initiation Protocol (SIP),” February 2006.), which explicitely states:

"It is possible that a participant in the conference may in fact be another focus. In order to provide a more complete participant list, the focus MAY subscribe to the conference package of the other focus to discover the participant list in the cascaded conference. This information can then be included in notifications by use of the <cascaded-focus> element as specified by this package".

Even though the simplex cascaded conferencing is an established way to concatenate conferences, we claim that it is not flexible enough to effectively cope with a number of potential distributed conferencing scenarios. More precisely, we envisage a situation where an overlay network infrastructure is in charge of managing distributed conferences, whereas the sinlge focus entities keep on managing their own centralized "realm". As it will come out in the next section, this entails that a specific requirement is formulated about the need for explicit management of distributed conference information.

5.  Requirements

In the following we are going to list the requirements we have identified for distributed conferencing. Each requirement is presented in general terms and some examples about its applicability are provided.

REQ-1:

Overlay Creation and Management
To enable effective operation of the distributed conferencing framework, an overlay network made of all interconnected conferencing clouds MUST be created. As an example, the mentioned overlay MAY be built by interconnecting all focus entities (with each such entity being the root of a local centralized conferencing cloud) through a full-meshed topology. Once the overlay is created, appropriate management of its structure SHOULD be envisaged; this includes, for example, dynamic updating of the topology information at the occurrence of relevant events (grafting/pruning of new centralized conferencing islands, etc.).

REQ-2:

Focus Discovery
An appropriate mechanism for the discovery of peering focus entities SHOULD be provided. Given the sensitive nature of the shared information, an appropriate authentication mechanism SHOULD be adopted. The trigger of the discovery process MAY be related to the concept of "presence"; in such case, an Instant Messaging (IM) based paradigm is RECOMMENDED. Alternatively, a logically centralized, physically distributed repository (e.g. UDDI) MAY be employed as a single reference point for the discovery of peering entities. A pure peer-to-peer approach can also be exploited for the same purpose.

REQ-3:

Self-configuration
At the occurrence of events like the grafting of a new cloud onto the overlay distributed conferencing network, the needed configuration steps SHOULD be performed in an automated fashion. This entails that all the news are appropriately exchanged across the overlay and, if needed, notified to the underlying centralized clouds as well.

REQ-4:

Information Sharing
The core of the operation of a distributed conferencing framework resides in the possibility to exchange information among all involved entities. The information sharing process SHOULD be made as effective as possible, e.g. by limiting the information that is forwarded outside a single centralized conferencing cloud to the data that are strictly necessary in order to guarantee that the overall state of the overaly is consistent, yet not redundant. Information sharing MAY be achieved either by exploiting a request/response paradigm, or through the adoption of asynchronous notification messages. A combined use of both the aforementioned paradigms is RECOMMENDED.

REQ-5:

Dynamic Update
All the clouds participating in the distributed overlay MUST keep the peers updated with respect to worth-noting events happening in their local realm. This MAY be achieved either by exploiting a request/response paradigm, or through the adoption of asynchronous notification messages. A combined use of both the aforementioned paradigms is RECOMMENDED. A pure peer-to-peer approach can also be exploited for the same purpose.

REQ-6:

Distributed Conference Management
In order to allow users' access to remotely created conferences, appropriate mechanisms MUST be provided by the framework. Such mechanisms SHOULD enable transparent management of both locally- and remotely-created conference instances. A pure peer-to-peer approach can be exploited for the same purpose.

REQ-7:

Centralized Protocols Routing and Dispatching
Focus entities MUST forward any centralized protocol message to their related peer in the distributed overlay whenever the message is directed to a receiver who does not belong to the local 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 could be BFCP [RFC4582] (Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP),” November 2006.) messages the local floor control server might need to send to a user who is remotely participating in the conference (because she/he does not belong to the current XCON cloud). Another example concerns BFCP messages a local user might send to the remote floor control server handling the remote distributed conference she/he is involved 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).

REQ-8:

Distributed Mixing
As soon as two or more centralized conferencing islands get connected in order to provide for a distributed conferencing scenario, the need arises to cope with the issue of mixing media flows generated by the conference participants. This challenging issue is currently considered out-of-scope in this document, which mainly focuses on the distribution of conference signalling/control information rather than addressing media management.

6.  Security Considerations

The communication between each distributed focus entity contains sensitive information, since it envisages the possibility to spread important data that only authorized parties should know (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 distributed focus entity or inject messages on its behalf.

To mitigate the above threats, all focus entities SHOULD mutually authenticate 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.

7. References

Authors' Addresses