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

Network Working Group                                        S P. Romano
Internet-Draft                                               A. Amirante
Expires: June 21, 2012                              University of Napoli
                                                             T. Castaldi
                                                              L. Miniero
                                                                Meetecho
                                                                A. Buono
                                             Ansaldo Trasporti e Sistemi
                                                              Ferroviari
                                                       December 19, 2011

               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 21, 2012.

Copyright Notice

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

Romano, et al.            Expires June 21, 2012                 [Page 1]
Internet-Draft    Distributed Conferencing Requirements    December 2011

   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 Simplified BSD License.

Table of Contents

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

Romano, et al.            Expires June 21, 2012                 [Page 2]
Internet-Draft    Distributed Conferencing Requirements    December 2011

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

Romano, et al.            Expires June 21, 2012                 [Page 3]
Internet-Draft    Distributed Conferencing Requirements    December 2011

   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

Romano, et al.            Expires June 21, 2012                 [Page 4]
Internet-Draft    Distributed Conferencing Requirements    December 2011

   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.

Romano, et al.            Expires June 21, 2012                 [Page 5]
Internet-Draft    Distributed Conferencing Requirements    December 2011

   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.

Romano, et al.            Expires June 21, 2012                 [Page 6]
Internet-Draft    Distributed Conferencing Requirements    December 2011

   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]
           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

Romano, et al.            Expires June 21, 2012                 [Page 7]
Internet-Draft    Distributed Conferencing Requirements    December 2011

   intervention and MITM (Man-In-The-Middle) attacks.  All messages
   SHOULD be encrypted to prevent eavesdropping.

7.  References

   [RFC2234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 2234, November 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

   [RFC4575]  Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
              Initiation Protocol (SIP) Event Package for Conference
              State", RFC 4575, August 2006.

   [RFC4245]  Levin, O. and R. Even, "High-Level Requirements for
              Tightly Coupled SIP Conferencing", RFC 4245,
              November 2005.

   [RFC4353]  Rosenberg, J., "A Framework for Conferencing with the
              Session Initiation Protocol (SIP)", RFC 4353,
              February 2006.

   [RFC4582]  Camarillo, G., Ott, J., and K. Drage, "The Binary Floor
              Control Protocol (BFCP)", RFC 4582, November 2006.

   [RFC5239]  Barnes, M., Boulton, C., and O. Levin, "A Framework for
              Centralized Conferencing", RFC 5239, June 2008.

Authors' Addresses

   Simon Pietro Romano
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   Email: spromano@unina.it

Romano, et al.            Expires June 21, 2012                 [Page 8]
Internet-Draft    Distributed Conferencing Requirements    December 2011

   Alessandro Amirante
   University of Napoli
   Via Claudio 21
   Napoli  80125
   Italy

   Email: alessandro.amirante@unina.it

   Tobia Castaldi
   Meetecho
   Via Carlo Poerio 89
   Napoli  80100
   Italy

   Email: tcastaldi@meetecho.com

   Lorenzo Miniero
   Meetecho
   Via Carlo Poerio 89
   Napoli  80100
   Italy

   Email: lorenzo@meetecho.com

   Alfonso Buono
   Ansaldo Trasporti e Sistemi Ferroviari
   Via Argine, 425
   Napoli  80147
   Italy

   Email: alfonso.buono@atsf.it

Romano, et al.            Expires June 21, 2012                 [Page 9]