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

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 June 13, 2009.

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.

Table of Contents

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

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 [I‑D.ietf‑xcon‑framework] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” April 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 [I‑D.ietf‑xcon‑framework] (Barnes, M., Boulton, C., and O. Levin, “A Framework for Centralized Conferencing,” April 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

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.