Internet DRAFT - draft-romano-dcon-xdsp-reqs
draft-romano-dcon-xdsp-reqs
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 the XCON-DCON Synchronization Protocol
draft-romano-dcon-xdsp-reqs-12
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
related DCON peer is based on the use of some kind of XCON-DCON
Synchronization Protocol (XDSP). This document gives the
requirements for XDSP.
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.
This document is subject to BCP 78 and the IETF Trust's Legal
Romano, et al. Expires June 17, 2013 [Page 1]
Internet-Draft XDSP Requirements December 2012
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. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Romano, et al. Expires June 17, 2013 [Page 2]
Internet-Draft XDSP Requirements December 2012
1. Introduction
The Distributed Conferencing framework [I-D.romano-dcon-requirements]
describes the requirements for 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 [RFC5239], 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 [RFC2119] 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 [RFC4353] and XCON
[RFC5239] 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 June 17, 2013 [Page 3]
Internet-Draft XDSP Requirements December 2012
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 June 17, 2013 [Page 4]
Internet-Draft XDSP Requirements December 2012
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 June 17, 2013 [Page 5]
Internet-Draft XDSP Requirements December 2012
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 [RFC4575]), 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 June 17, 2013 [Page 6]
Internet-Draft XDSP Requirements December 2012
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 June 17, 2013 [Page 7]
Internet-Draft XDSP Requirements December 2012
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
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Romano, et al. Expires June 17, 2013 [Page 8]
Internet-Draft XDSP Requirements December 2012
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.
[RFC4353] Rosenberg, J., "A Framework for Conferencing with the
Session Initiation Protocol (SIP)", RFC 4353,
February 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[I-D.romano-dcon-requirements]
Romano, S., Amirante, A., Castaldi, T., Miniero, L., and
A. Buono, "Requirements for Distributed Conferencing",
draft-romano-dcon-requirements-11 (work in progress),
June 2012.
[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
Alessandro Amirante
University of Napoli
Via Claudio 21
Napoli 80125
Italy
Email: alessandro.amirante@unina.it
Romano, et al. Expires June 17, 2013 [Page 9]
Internet-Draft XDSP Requirements December 2012
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 10]
