Skip to main content

Requirements for the XCON-DCON Synchronization Protocol
draft-romano-dcon-xdsp-reqs-10

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Simon Pietro Romano , Alessandro Amirante , Tobia Castaldi , Lorenzo Miniero , Alfonso Buono
Last updated 2011-12-19 (Latest revision 2011-06-20)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-romano-dcon-xdsp-reqs-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 the XCON-DCON Synchronization Protocol
                     draft-romano-dcon-xdsp-reqs-10

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

Copyright Notice

   Copyright (c) 2011 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 21, 2012                 [Page 1]
Internet-Draft              XDSP Requirements              December 2011

   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 21, 2012                 [Page 2]
Internet-Draft              XDSP Requirements              December 2011

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 21, 2012                 [Page 3]
Internet-Draft              XDSP Requirements              December 2011

   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 21, 2012                 [Page 4]
Internet-Draft              XDSP Requirements              December 2011

   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 21, 2012                 [Page 5]
Internet-Draft              XDSP Requirements              December 2011

   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 21, 2012                 [Page 6]
Internet-Draft              XDSP Requirements              December 2011

            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 21, 2012                 [Page 7]
Internet-Draft              XDSP Requirements              December 2011

            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 21, 2012                 [Page 8]
Internet-Draft              XDSP Requirements              December 2011

              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-09 (work in progress),
              June 2011.

   [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 21, 2012                 [Page 9]
Internet-Draft              XDSP Requirements              December 2011

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