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

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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on June 01, 2012.

Copyright Notice

Copyright (c) 2011 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.

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][RFC4575].

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] 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] and XCON [RFC5239] 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] 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] (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], 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.

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