Network Working Group S P. Romano
Internet-Draft A. Amirante
Expires: July 26, 2008 T. Castaldi
L. Miniero
University of Napoli
A. Buono
CRIAI Consortium
January 23, 2008
Requirements for the XCON-DCON Synchronization Protocol
draft-romano-dcon-xdsp-reqs-02.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 July 26, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
The Distributed Conferencing (DCON) framework provides the means to
distribute Centralized Conference (XCON) information by appropriately
orchestrating a number of centralized focus entities (clouds). The
mechanism we propose to make each XCON cloud communicate with its
Romano, et al. Expires July 26, 2008 [Page 1]
Internet-Draft XDSP Requirements January 2008
related DCON peer is based on the use of some kind of XCON-DCON
Synchronization Protocol (XDSP). This document gives the
requirements for XDSP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. XDSP Requirements . . . . . . . . . . . . . . . . . . . . . . 4
4.1. General Protocol Requirements . . . . . . . . . . . . . . 4
4.2. Requests and responses . . . . . . . . . . . . . . . . . . 5
4.3. Updates and asynchronous notifications . . . . . . . . . . 6
4.4. Centralized protocols routing and dispatching . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. References . . . . . . . . . . . . . . . . . . . . . . . . 9
7.2. Informational References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Romano, et al. Expires July 26, 2008 [Page 2]
Internet-Draft XDSP Requirements January 2008
1. Introduction
The Distributed Conferencing framework [6] describes the overall
architecture, terminology, and protocol components needed for
distribuited conferencing. DCON is based on the idea that a
distributed conference can be setup and accessed by appropriately
orchestrating the operation of a number of XCON "focus" elements,
each in charge of managing a certain number of participants. Each
pair composed of a centralized focus entity (XCON) and its related
distributed counterpart (namely, a DCON focus) is called "island", or
"cloud". These islands are then made part of an overlay network
composed of several inter-communicating clouds.
Interaction between each participant and the corresponding conference
focus is based on the standard XCON framework [7], whereas inter-
focus interaction is based on a peer-to-peer paradigm. The
interaction between the centralized conference focus and the
distributed conference focus, instead, has requirements that are
defined in this document.
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 the both the SIPPING [4] and XCON [7]
conferencing frameworks. The following additional terms are defined
for specific use within the distributed conferencing work.
Conferencing Cloud:
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.
Romano, et al. Expires July 26, 2008 [Page 3]
Internet-Draft XDSP Requirements January 2008
DCON Focus:
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.
Focus Discovery:
The capability to detect the presence of new focus entities in a
distributed conferencing framework.
Information Spreading:
The spreading of conference related information among the focus
entities in a distributed environment.
Protocol Dispatching:
The capabilty of appropriately forwarding/distributing messages of
a natively centralized protocol in order to let them spread across
a distributed environment.
Label Swapping:
The opportune swap of labels assigned to a specific resource,
needed to avoid conflicts in the assignment of labels across
several point-to-point communications regarding the same resource.
4. XDSP Requirements
This section describes requirements for the XCON-DCON synchronization
protocol (XDSP).
4.1. General Protocol Requirements
REQ-A1:
XDSP protocol MUST be a reliable client-server protocol.
Hence, it MUST have a positive response indicating that the
request has been received, or an error response in case an
error has occurred.
Romano, et al. Expires July 26, 2008 [Page 4]
Internet-Draft XDSP Requirements January 2008
REQ-A2:
It MUST be possible for the XCON focus entity, the server,
to authenticate the related DCON focus entity, the client.
REQ-A3:
It MUST be possible for the DCON focus entity to be
authenticated by the server, the related XCON focus entity.
REQ-A4:
It MUST be possible to ensure message integrity between each
pair of XCON and DCON focus entities.
4.2. Requests and responses
REQ-B1:
It MUST be possible for the involved XCON and DCON entities
to communicate on a stateless synchronous request-response
based mechanism.
REQ-B2:
An error message MUST be sent back to the entity placing the
request, in case the message couldn't be processed for any
reason.
REQ-B3:
An authentication mechanism SHOULD be made possible on the
basis of such stateless synchronous request-response based
interaction between the two involved entities.
REQ-B4:
It SHOULD be possible for the XCON focus entity to request
access to remote (e.g. avaliable on different islands)
resources by means of an answer sent to the related DCON
focus entity. This includes requesting a join to a remote
conference for a local user, setting up distributed
conferences, actively requesting the list of all the remote
conferences and/or the list of all users (remote and local)
in a currently running conference, etc..
Romano, et al. Expires July 26, 2008 [Page 5]
Internet-Draft XDSP Requirements January 2008
REQ-B5:
The DCON focus entity SHALL forward any request directed to
resources available in the related XCON cloud to the related
XCON focus entity which will manage it and properly answer
the request.
4.3. Updates and asynchronous notifications
REQ-C1:
It SHOULD be possible for the DCON focus entity to subscribe
to the related XCON focus entity for events related to the
conference system state, in order to receive asynchronous
notifications.
REQ-C2:
The XCON focus entity SHALL generate new asynchronous
notifications every time there is any change in the state of
any of the conferences it is currently handling.
REQ-C3:
It SHOULD be possible for the DCON focus entity to receive
full state updates from the related XCON focus entity, in
case some of the events were missed, to make the known state
consistent with the actual conference system internal state.
REQ-C4:
Both partial notifications and full updates SHOULD be sent
through the same authenticated channel used for XDSP
communication. In case a separate channel and/or a separate
protocol are used (e.g. by means of the XCON event package,
when it is available, or of the already available SIPPING
conference event package [5]), the same issues about
security and integrity SHOULD be addressed to avoid attacks
and exploits by unauthenticated users.
REQ-C5:
Since state changes might happen in both the involved focus
entities (even though related to different situations) the
same requirements just described for notifications generated
by XCON focus entities should be addressed for their related
DCON focus entities. It SHOULD be possible for the XCON
Romano, et al. Expires July 26, 2008 [Page 6]
Internet-Draft XDSP Requirements January 2008
focus entity to subscribe to the related DCON focus entity
for events related to the conference system state, in order
to receive asynchronous notifications.
REQ-C6:
The DCON focus entity SHALL generate new asynchronous
notifications every time there is any change in its internal
state, e.g. whenever new remote conferences have been
created or become active, etc.
REQ-C7:
It SHOULD be possible for the XCON focus entity to receive
full state updates from the related DCON focus entity, in
case some of the events were missed, to make the known state
consistent with the actual conference system internal state.
4.4. Centralized protocols routing and dispatching
REQ-D1:
The XCON focus entity MUST forward any centralized protocol
message to its related DCON focus entity whenever the
message is to be received by a peer who is not a local
entity of the 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 is represented by
BFCP messages the local floor control server might need to
send to a user who is remotely (i.e. a user who does not
belong to the current XCON cloud) participating in the
conference. Another example concerns BFCP messages a local
user might want to send to the remote floor control server
handling the remote, distributed, conference the user is
participating 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-D2:
The DCON focus entity MUST forward any natively centralized
protocol message it receives from DCON focus peers in the
distributed overlay (routing) to the related XCON focus
entity (dispatching), whenever the message is addressed to
Romano, et al. Expires July 26, 2008 [Page 7]
Internet-Draft XDSP Requirements January 2008
any of the local entities of the centralized cloud.
REQ-D3:
The XCON and DCON focus entities MUST establish and mantain
opportune labels to correctly address and identify local
entities involved in routed and dispatched messages. These
labels MUST be appropriately swapped whenever they leave a
DCON focus entity and reach a foreign one, so to avoid
conflicts upon assigned labels in different islands.
REQ-D4:
Message dispatching between the two involved focus entities
SHOULD occur on an request-response based communication
mechanism, and opportune errors should be generated in case
any exceptional condition happens while processing the
messages.
5. Security Considerations
The communication between each DCON focus entity and its related XCON
entity contains sensitive information, since it envisages the
possibility to spread important information that only authorized
entities should be aware of (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 DCON focus entity and/or inject messages on his behalf. Many
obvious consequences could come out of such an undesirable situation.
To mitigate the above threats, both the DCON focus entity and the
XCON focus entity SHOULD be authenticated 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.
6. Acknowledgements
7. References
Romano, et al. Expires July 26, 2008 [Page 8]
Internet-Draft XDSP Requirements January 2008
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.
7.2. Informational References
[4] Rosenberg, J., "A Framework for Conferencing with the Session
Initiation Protocol (SIP)", RFC 4353, February 2006.
[5] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference State",
RFC 4575, August 2006.
[6] Buono, A., "A Framework for Distributed Conferencing",
draft-romano-dcon-framework-01 (work in progress), July 2007.
[7] Barnes, M., Boulton, C., and O. Levin, "A Framework for
Centralized Conferencing", draft-ietf-xcon-framework-10 (work in
progress), November 2007.
Authors' Addresses
Simon Pietro Romano
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: spromano@unina.it
Alessandro Amirante
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: alessandro.amirante@unina.it
Romano, et al. Expires July 26, 2008 [Page 9]
Internet-Draft XDSP Requirements January 2008
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 July 26, 2008 [Page 10]
Internet-Draft XDSP Requirements January 2008
Full Copyright Statement
Copyright (C) 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Romano, et al. Expires July 26, 2008 [Page 11]