[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

INTERNET-DRAFT                                           Carsten Bormann
Expires: January 1996                                Universitaet Bremen
                                                               Joerg Ott
                                                               TU Berlin
                                                               July 1995

                 MMUSIC/ITU Interoperability Scenarios

Status of this memo

   This document is an Internet-Draft.  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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).


   This memo is a (very rough) summary of potential scenarios where
   teleconferencing systems based on ITU standards (H.320, T.120)
   interoperate with teleconferencing systems based on RTP and MMUSIC
   style (``Internet'') standards.

   This memo is a submission to the IETF MMUSIC working group.
   Comments should be addressed to the confctrl@isi.edu mailing list.

1.  Introduction

   Within the ITU (formerly known as CCITT), a number of
   ``recommendations'' (ITU name for standards) have recently been
   generated that cover audiographic and video teleconferencing over
   telephone (ISDN) lines.  These recommendations are commonly subsumed
   by the names of the two overview recommendations, H.320 (narrow-band
   visual telephone systems and terminal equipment, 1993) and T.120
   (data protocols for multimedia conferencing).  Products conforming to
   these recommendations are appearing on the marketplace rapidly.

   With the increasing interest in multicast based teleconferencing
   based on standards being developed by the AVT and MMUSIC working
   groups of the IETF, it seems prudent to examine the potential of

Bormann, Ott                                                    [Page 1]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   interoperability between systems conforming to each of the two
   protocol suites.  Since the two suites are significantly different
   not only in protocol details but also in fundamental approach and
   assumptions, we propose to first examine the possible scenarios under
   which such interoperation would occur.

   In this memo, we will assume basic knowledge of the work of the IETF
   working groups, and only provide some text to explain a few basics of
   the ITU teleconferencing work.

2.  Terminology

   This memo will use a mixed terminology, with some ITU terms and some
   terms as they are used in the Internet world.  As some readers will
   not be familiar with ITU terms, this table provides a reference.

          ITU Term                         Equivalent term(s)
   recommendation               standard
   terminal                     host, end system
                                     (including video telephones)
   MCU (multipoint              (application) gateway,
        control unit)                intermediate system
   PSTN (public switched        POTS (plain old telephone service)
        telephone network)
   LAN                          LAN (possibly with bridges and routers),
                                     (small i) internet
   application                  media agent
   conference profile           session description

3.  State of standardization

   As of now, ITU has standards for ISDN interconnection of pairs of
   H.320 systems, as well as for ISDN interconnections of multiple H.320
   systems (terminals) via intermediate systems called MCU (multipoint
   control units).  Extensions of these standards for PSTN (POTS)
   interconnection, for operation over LAN protocols as well as over ATM
   are in preparation (according to the current state of discussion,
   even in LANs, MCUs are likely to be used when more than two
   participants are involved).  The T.120 family of standards defines
   conference control and ``data'' applications for these environments,
   based on point-to-point multicasting trees defined by MCS

   In the ITU context, using IP implies a (possibly bridged or routed)
   LAN (so far); the assumption is that wide area traffic will be
   circuit-switched via ISDN with H.221 (a frame based bit allocation
   protocol) being used for multiplexing.  Note that it is not decided
   yet whether ITU will use RTP over LANs (even if the new protocols are
   based on IP or possibly IP multicast -- see below).  The use of
   reservation protocols within a LAN currently is considered a local
   matter -- only a mechanism to request bandwidth from some (MCU-style)

Bormann, Ott                                                    [Page 2]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   well-defined entity is being defined.

   The IETF has standards for AV multicast (RTP and RTP payload data
   formats) and is working on control (MMUSIC).  These standards do not
   explicitly differentiate between LAN and WAN applications; they were
   designed with WAN considerations in mind.

4.  ITU Basic Assumptions

   T.120 conferences are tightly coupled.  The general assumption is
   that all participants know about all other participants, as well as
   their characteristics such as the set of applications available to
   them and the applications' capabilities.  This knowledge is kept
   consistent throughout the course of the conference by a conference
   management system (GCC, T.124) using a reliable multicast transport
   (MCS, T.122/T.125).

5.  ITU Interconnection Models

   [The following text is a slightly edited quote from one of the
   authors' previous contributions to SG15, AVC-797.]

     Figure 1 shows a complex scenario how terminals may be
     interconnected through WANs and LANs, either in a point-to-point
     call or in a multipoint conference.

                         _______                      ________
      +-+      +-+      /       |   +-+      +-+     /        |   +-+
      | |      | |------  WAN #1 ---| |      | |-----  WAN #2  ---| |
      +-+      +-+      |_______/   +-+      +-+     |________/   +-+
       |        |         /          |        |          |   |
     --+---+----+---   +-+        ---+----+---+---      +-+   +-+
           |           | |                |             | |   | |
          +-+  LAN #1  +-+        LAN #2 +-+            +-+   +-+
          | |                            | |
          +-+                            +-+

             Figure 1: Interconnection Models for LANs and WANs

     This figure is a generalization of the following possible

     a)   WAN only terminals (listed here for completeness)

     b)   LAN terminal(s) connected to WAN terminal(s) through a gateway

     c)   LAN terminals within a single LAN only

     d)   LAN terminal(s) connected to other LAN terminal(s); the LANs
          are interconnected by a WAN

     e)   WAN terminal(s) connected to WAN terminal(s); different WANs
          are used; the different WANs are interconnected through a LAN

Bormann, Ott                                                    [Page 3]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

     The design of any transport for T.120 data information should
     consider the existence of all the above scenarios.  This means that
     any extension of the T.123 protocol stacks has to be able to
     interwork with all other T.120 terminals that do not implement this
     extension.  As a corollary, the service offered by the T.122/T.125
     Multipoint Communication Service must not be affected.

   [End of quote].  The latter comment obviously also applies to audio
   and video streams.

   Note that each of the "LANs" in the ITU scenarios could be an
   internet in the interoperability case; appropriate gateways would be
   used for bridging.  A LAN-to-WAN gateway would need to perform at
   least the following functions:

   -    conversion from ISDN multiplexing (H.221) to a format more
        suitable for LANs (H.223 =?= RTP)

   -    conversion of audio/video encoding formats (e.g., deletion of
        BCH envelopes for H.261 to obtain RTP payload data formatting),
        as required

   -    filtering of data streams to keep only those absolutely
        necessary (e.g., the LAN could use ``continuous presence'' of
        all participants by their video streams, while on the WAN only
        the streams of the speaker and the previous speaker are

   -    transport layer gatewaying (e.g., X.224/RFC1006/TCP/IP to

6.  Types of interoperation

   Based on these interconnection scenarios, the following scenarios for
   interoperation between ITU and IETF conferencing systems could be

   1)   T.120 ISDN terminal users "phone in" to a classical IETF-style
        WAN internet multicast session (e.g. an IETF broadcast).

        1a)  Actually, not just one terminal but a whole T.120
             conference network is built on the T.120 side.

        1b)  The internet WAN session becomes more controlled than a
             ``classical'' session -- more information needs to be
             relayed to the T.120 session control.  (This, obviously,
             depends on what kind of session control is used on the
             Internet side.)

        The assumption here is that the IETF style conference is the one
        "in control" and "phoners-in" are accepting some semantic
        lossage.  E.g., the T.124 (GCC) conference roster (attendance
        list) could be incomplete, it might not be possible to perform

Bormann, Ott                                                    [Page 4]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

        certain actions (such as addressing single participants), etc.

        Note that for a conference in which #apps applications (such as
        whiteboard etc.) are used, MCS/GCC runs into a hard limit of
        64535/(#apps+1) participants.

   2)   LAN-wide internet multicast sessions are used behind a local
        T.120 MCU (i.e., LAN systems don't speak T.120 but support
        classical IETF sessions only)

        2a)  Internet multicast sessions with additional T.120
             consciousness are used behind a local T.120 MCU (different
             from 2?).  In the simplest case, they would have to be able
             to take part in and make use of the T.124 conference roster
             generation process; applications could announce their
             capabilities in the application roster, etc.

        The assumption here is that T.120 is "in control" and the LAN
        group has to cope.

   3)   A group of internet WAN participants and a group T.120 WAN
        participants are joined by a gateway/MCU.  Both parts get the
        illusion of a homogeneous conferencing environment.

        The "gateway/MCU" would be a much more sophisticated form of the
        same gateway referred to above.  Achieving a homogeneous
        conferencing environment certainly would require a high degree
        of semantic compatibility of the IETF conference control
        protocol with those of the ITU.

7.  Technical implications

   For all these scenarios, special consideration must be given to the
   following aspects.

   [Note: These items must be sorted into those relevant specifically to
   MMUSIC and those relevant only for a broader discussion.]

7.1.  Type of mapping within a gateway

   A gateway may attempt to map a semantic feature of one domain into an
   equivalent feature of the other domain and vice-versa (bidirectional
   mapping).  Alternatively/additionally, it may attempt to tunnel
   information only supported by one domain through the other domain in
   A-B-A configurations (e.g., it could attempt encoding the T.120
   application capabilities in an RTCP text attribute).

7.2.  Agreement protocol vs. conducted mode behavior

   The ITU-T conference control distinguishes two different modes of
   operation: a conducted and a non-conducted mode.  In conducted mode,
   a single participant largely controls the conference requiring the
   others to query for permission to perform certain actions (which

Bormann, Ott                                                    [Page 5]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   actions are affected is defined in the session description as well as
   the respective recommendations for conferencing applications).  In
   non-conducted mode no such restrictions are imposed.

   These two modes represent the two extremes that can be thought of
   when using the MMUSIC agreement protocol.  However, within the ITU-T
   conference control no intermediate modes are defined.

7.3.  Resource control (bandwidth management)

   The current approach pursued by SG 15 is to limit the number of AV
   connections gatewayed into a LAN.

   In addition, possibly, recoding will be required between high and low
   bandwidth environments.

7.4.  Addressing

   Participants will have to be addressed by POTS/ISDN numbers
   (generally E.164) as well as by addresses from internets and the
   Internet.  This is confounded further by ITU embracing IPX as well as

7.5.  Session description

   In the ITU model, a session is ``described'' by participants that
   update roster information and that actually start applications based
   on the capabilities in that roster information.  Currently, only a
   small static information base may be configured at conference startup
   time (part of which remains unchanged throughout the course of the
   conference).  This information base describes the conference (e.g.
   the conference name) and defines some attributes of the conference
   (conducted or not, some authentication mechanism, e.g. a password in
   the simplest case, etc.).

   In the classical IETF model, the session description is broadcast
   beforehand; it cannot be changed during the session or adapted to the
   capabilities of the participants.  Other uses of the IETF session
   description language SDP are being considered; note that currently
   multicast address allocation (see also below) is intertwined with
   session description broadcasting.

7.6.  Authentication

   Internet applications generally will use cryptography based end-to-
   end authentication and confidentiality.

   MCS does not use authentication within the conference; instead,
   unwanted participants cannot obtain transport connections to the MCS
   domain (data part of the conference) at all.  The T.120 conference
   control protocol GCC currently allows for a challenge-response
   mechanism for authentication to the MCS domain.  Confidentiality can
   be achieved using H.233/H.234 by enciphering the entire transport

Bormann, Ott                                                    [Page 6]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   stream, i.e., hop-by-hop based enciphering.  This requires trusted
   MCUs (proposals for operations with non-trusted MCUs are being made).

7.7.  Use of Multicasting

   Given the intent of ITU SG15 to generate a draft standard by
   November, (to be voted on in 1996) complications such as multicasting
   have a relatively low priority.  It seems unlikely that SG8 will come
   around to extending MCS to incorporate multicast subtrees (based on
   multicast transports such as MTP-2 or RMP).  Multicast *might* be an
   option for ITU's RTP replacement, but note that ITU needs a handle on
   IP multicast address allocation for this to become real (see next

   In any case, for operational use of multicasting in environments that
   may or may not have multicast capable routers (or operating systems,
   or protocol stacks) it must be possible to use point-to-point meshes
   as a fallback.  This fallback should be automatic; manual
   configuration is unlikely to be workable.  One solution currently
   being offered within the ITU environment is to start a conference as
   a point-to-point mesh and to allocate a multicast address and to
   start testing multicast connectivity simultaneously.  Terminals that
   do have multicast connectivity withdraw from the point-to-point mesh.

7.8.  Multicast address allocation

   In IETF conferences, the allocation of multicast address is done
   administratively (by applying for an address at IANA) or by global
   broadcasting of address claims.  Administratively scoped multicast
   may alleviate the problem for conferences confined to a site only.
   For operational use, an address allocation mechanism must be found
   that scales to large numbers of conferences and avoids conflicts
   quite reliably.  Note that conferences that must be protected from
   denial-of-service attacks will need a form of authentification that
   might make conflicts less of a problem.

8.  Security Considerations

   Any interoperation between ITU-based systems and Internet-based
   systems must take care to preserve the point-to-point link based
   security model underlying the ITU standards.  In T.120, much of the
   access control relies on being able to reject the attempt to join a
   conference via an ISDN connection to an MCU.  See also
   ``Authentication'' above.

9.  Authors' Addresses

   Carsten Bormann
   Universitaet Bremen FB3 MZH 5180
   Postfach 330440
   D-28334 Bremen

Bormann, Ott                                                    [Page 7]

INTERNET-DRAFT    MMUSIC/ITU Interoperability Scenarios        July 1995

   Joerg Ott
   Technische Universitaet Berlin FR 6-3
   Franklinstr. 28/29
   D-10587 Berlin

Appendix: Pertinent standards bodies

   ITU-T SG8: T.120 standardization (MCS, application protocols,
   conference control)

   ITU-T SG15: defines LAN-WAN gateway

   IMTC LAN-WG: defines LAN-WAN interworking

   IETF AVT WG: defines real-time transport and payload data formats

   IETF MMUSIC WG: defines conference control

Bormann, Ott                                                    [Page 8]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/