Network Working Group S P. Romano
Internet-Draft T. Castaldi
Expires: February 1, 2008 L. Miniero
University of Napoli
A. Buono
CRIAI Consortium
July 31, 2007
Requirements for Distributed Conferencing
draft-romano-dcon-requirements-01.txt
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 February 1, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
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
Romano, et al. Expires February 1, 2008 [Page 1]
Internet-Draft Distributed Conferencing Requirements July 2007
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Related work: Cascaded Conferencing . . . . . . . . . . . . . 4
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7.1. References . . . . . . . . . . . . . . . . . . . . . . . . 8
7.2. Informational References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Romano, et al. Expires February 1, 2008 [Page 2]
Internet-Draft Distributed Conferencing Requirements July 2007
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 [8][4].
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 [2] and indicate requirement levels for
compliant implementations.
3. Terminology
Distributed conferencing uses, when appropriate, and expands on the
terminology introduced in both the SIPPING [2] and XCON [8]
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
Romano, et al. Expires February 1, 2008 [Page 3]
Internet-Draft Distributed Conferencing Requirements July 2007
"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) [5] 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
[6] (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) [6], 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
Romano, et al. Expires February 1, 2008 [Page 4]
Internet-Draft Distributed Conferencing Requirements July 2007
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
Romano, et al. Expires February 1, 2008 [Page 5]
Internet-Draft Distributed Conferencing Requirements July 2007
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
Romano, et al. Expires February 1, 2008 [Page 6]
Internet-Draft Distributed Conferencing Requirements July 2007
messages propagation. An example could be BFCP [7] 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
Romano, et al. Expires February 1, 2008 [Page 7]
Internet-Draft Distributed Conferencing Requirements July 2007
7.1. References
[1] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[5] Levin, O. and R. Even, "High-Level Requirements for Tightly
Coupled SIP Conferencing", RFC 4245, November 2005.
[6] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[7] Camarillo, G., Ott, J., and K. Drage, "The Binary Floor Control
Protocol (BFCP)", RFC 4582, November 2006.
7.2. Informational References
[8] Barnes, M., "A Framework for Centralized Conferencing",
draft-ietf-xcon-framework-08 (work in progress), May 2007.
Authors' Addresses
Simon Pietro Romano
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: spromano@unina.it
Romano, et al. Expires February 1, 2008 [Page 8]
Internet-Draft Distributed Conferencing Requirements July 2007
Tobia Castaldi
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: tobia.castaldi@unina.it
Lorenzo Miniero
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: lorenzo.miniero@unina.it
Alfonso Buono
CRIAI Consortium
Piazzale E. Fermi
Napoli 80100
Italy
Email: alfonso.buono@criai.it
Romano, et al. Expires February 1, 2008 [Page 9]
Internet-Draft Distributed Conferencing Requirements July 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Romano, et al. Expires February 1, 2008 [Page 10]