Internet DRAFT - draft-romano-dcon-requirements
draft-romano-dcon-requirements
Network Working Group S P. Romano
Internet-Draft A. Amirante
Expires: June 17, 2013 University of Napoli
T. Castaldi
L. Miniero
Meetecho
A. Buono
Ansaldo Trasporti e Sistemi
Ferroviari
December 14, 2012
Requirements for Distributed Conferencing
draft-romano-dcon-requirements-12
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 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
Romano, et al. Expires June 17, 2013 [Page 1]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 2]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 3]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 4]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 5]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 6]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 7]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 8]
Internet-Draft Distributed Conferencing Requirements December 2012
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 17, 2013 [Page 9]
