idnits 2.17.1 draft-bormann-mmusic-itu-interop-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 74 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1995) is 10389 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 8 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Carsten Bormann 2 Expires: May 1996 Universitaet Bremen 3 Joerg Ott 4 TU Berlin 5 November 1995 7 MMUSIC/ITU Interoperability Scenarios | 8 draft-bormann-mmusic-itu-interop-01.txt | 10 Status of this memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 25 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 26 ftp.isi.edu (US West Coast). 28 Abstract 30 This memo is a rough summary of potential scenarios where | 31 teleconferencing systems based on ITU standards (H.320, T.120) 32 interoperate with teleconferencing systems based on RTP and MMUSIC 33 style (``Internet'') standards. Version 01 is a minor update mainly | 34 based on ITU progress up to, but not including the November 1995 | 35 Geneva SG15 meeting (which extends two days beyond the I-D deadline). | 36 Change bars are provided relative to version 00. 38 This memo is a submission to the IETF MMUSIC working group. 39 Comments should be addressed to the confctrl@isi.edu mailing list. 41 1. Introduction 43 Within the ITU (formerly known as CCITT), a number of 44 ``recommendations'' (ITU name for standards) have recently been 45 generated that cover audiographic and video teleconferencing over 46 telephone (ISDN) lines. These recommendations are commonly subsumed 47 by the names of the two overview recommendations, H.320 (narrow-band 48 visual telephone systems and terminal equipment, 1993) and T.120 49 (data protocols for multimedia conferencing). Products conforming to 50 these recommendations are appearing on the marketplace rapidly. Work | 51 is in progress to accomodate these standards to other transport media | 52 than ISDN, including analog telephone lines, LANs, and ATM circuits. | 54 With the increasing interest in multicast based teleconferencing 55 based on standards being developed by the AVT and MMUSIC working 56 groups of the IETF, it seems prudent to examine the potential of 57 interoperability between systems conforming to each of the two 58 protocol suites. Since the two suites are significantly different 59 not only in protocol details but also in fundamental approach and 60 assumptions, we propose to first examine the possible scenarios under 61 which such interoperation would occur. 63 In this memo, we will assume basic knowledge of the work of the IETF 64 working groups, and only provide some text to explain a few basics of 65 the ITU teleconferencing work. 67 2. Terminology 69 This memo will use a mixed terminology, with some ITU terms and some 70 terms as they are used in the Internet world. As some readers will 71 not be familiar with ITU terms, this table provides a reference. 73 ITU Term Equivalent term(s) 74 ---------------------------------------------------------------------- 75 recommendation standard 76 terminal host, end system 77 (including video telephones) 78 MCU (multipoint (application) gateway, 79 control unit) intermediate system 80 PSTN (public switched POTS (plain old telephone service) 81 telephone network) 82 LAN LAN (possibly with bridges and routers), 83 (small i) internet 84 application media agent 85 conference session, conference || 86 session group of peer media agents || 87 conference profile session description 89 3. State of standardization 91 As of now, ITU has standards for ISDN interconnection of pairs of 92 H.320 systems, as well as for ISDN interconnections of multiple H.320 93 systems (terminals) via intermediate systems called MCU (multipoint 94 control units). Extensions of these standards for PSTN (POTS) 95 interconnection, for operation over LAN protocols as well as over ATM 96 are in preparation (according to the current state of discussion, | 97 even in LANs, special Multipoint Controllers (MCs) are likely to be | 98 used as rendezvous points when more than two participants are | 99 involved). The T.120 family of standards defines conference control 100 and ``data'' applications for these environments, based on point-to- 101 point multicasting trees defined by MCS (T.122/T.125). 103 In the ITU context, using IP implies a (possibly bridged or routed) 104 LAN (so far); the assumption is that wide area traffic will be 105 circuit-switched via ISDN with H.221 (a frame based bit allocation 106 protocol) being used for multiplexing. It has been decided that the | 107 LAN-based multiplex (H.22Z) will use RTP over LANs, probably | 108 augmented by ITU-specific profiling and by special setup protocols | 109 (most likely based on Q.931). The use of reservation protocols 110 within a LAN currently is considered a local matter -- only a 111 mechanism to request bandwidth from some (MCU-style) well-defined 112 entity is being defined. 114 The IETF has standards for AV multicast (RTP and RTP payload data 115 formats) and is working on control (MMUSIC). These standards do not 116 explicitly differentiate between LAN and WAN applications; they were 117 designed with WAN considerations in mind. 119 4. ITU Basic Assumptions 121 T.120 conferences are tightly coupled. The general assumption is 122 that all participants know about all other participants, as well as 123 their characteristics such as the set of applications available to 124 them and the applications' capabilities. This knowledge is kept 125 consistent throughout the course of the conference by a conference 126 management system (GCC, T.124) using a reliable multicast transport 127 (MCS, T.122/T.125). | 129 5. ITU conference model (T.121) | 131 The ITU model of the way applications interact in a conference is | 132 defined in recommendation T.121. As applications themselves are | 133 outside the scope of ITU standardization, this recommendation defines | 134 the term ``application protocol entity'' (APE) as those parts of | 135 applications that engage in the horizontal protocols defined by ITU. | 136 One or more APEs are in an ``Application Protocol Session'', i.e., | 137 they form a group of peer entities engaged in a single instance of | 138 the horizontal protocol. | 140 T.121 defines several types of such sessions within a conference: | 142 a) Default sessions, which are not used for actual application | 143 activity, but as a placeholder for information about | 144 applications not currently in actual sessions as well as a | 145 mechanism to maintain registries for sessions whose parameters | 146 have not been standardized. | 148 b) Static and dynamic multicast sessions, which differ only in | 149 whether their MCS parameters have been standardized or are | 150 maintained in a registry. Both have lifespans independent of | 151 any particular member and are open to any member of the | 152 conference. | 154 c) Dynamic user-id sessions. This type is similar to the previous | 155 type, except that the lifespan of a dynamic user-id session is | 156 bound to the presence of a specific identified creator. This | 157 can e.g. be used for centralized applications. | 159 d) Dynamic private sessions. This type is similar to the previous | 160 type, except that admission to a session of this type is | 161 controlled by its creator. 163 6. ITU Interconnection Models 165 [The following text is a slightly edited quote from one of the 166 authors' previous contributions to SG15, AVC-797.] 168 Figure 1 shows a complex scenario how terminals may be 169 interconnected through WANs and LANs, either in a point-to-point 170 call or in a multipoint conference. 172 _______ ________ 173 +-+ +-+ / | +-+ +-+ / | +-+ 174 | | | |------ WAN #1 ---| | | |----- WAN #2 ---| | 175 +-+ +-+ |_______/ +-+ +-+ |________/ +-+ 176 | | / | | | | 177 --+---+----+--- +-+ ---+----+---+--- +-+ +-+ 178 | | | | | | | | 179 +-+ LAN #1 +-+ LAN #2 +-+ +-+ +-+ 180 | | | | 181 +-+ +-+ 183 Figure 1: Interconnection Models for LANs and WANs 185 This figure is a generalization of the following possible 186 scenarios: 188 a) WAN only terminals (listed here for completeness) 190 b) LAN terminal(s) connected to WAN terminal(s) through a gateway 192 c) LAN terminals within a single LAN only 194 d) LAN terminal(s) connected to other LAN terminal(s); the LANs 195 are interconnected by a WAN 197 e) WAN terminal(s) connected to WAN terminal(s); different WANs 198 are used; the different WANs are interconnected through a LAN | 199 [this scenario is somewhat out of focus for ITU work] 201 The design of any transport for T.120 data information should 202 consider the existence of all the above scenarios. This means that 203 any extension of the T.123 protocol stacks has to be able to 204 interwork with all other T.120 terminals that do not implement this 205 extension. As a corollary, the service offered by the T.122/T.125 206 Multipoint Communication Service must not be affected. 208 [End of quote]. The latter comment obviously also applies to audio 209 and video streams. 211 Note that each of the ``LANs'' in the ITU scenarios could be an | 212 internet in the interoperability case; appropriate gateways would be 213 used for bridging. A LAN-to-WAN gateway would need to perform at 214 least the following functions: 216 - conversion from ISDN multiplexing (H.221) to a format more 217 suitable for LANs (H.22Z, which is based on RTP) | 219 - conversion of audio/video encoding formats (e.g., deletion of 220 BCH envelopes for H.261 to obtain RTP payload data formatting), 221 as required 223 - filtering of data streams to keep only those absolutely 224 necessary (e.g., the LAN could use ``continuous presence'' of 225 all participants by their video streams, while on the WAN only 226 the streams of the speaker and the previous speaker are 227 retained). 229 - transport layer gatewaying (e.g., X.224/RFC1006/TCP/IP to 230 X.224/Q.933/Q.922) | 232 7. Types of interoperation 234 Based on these interconnection scenarios, the following scenarios for 235 interoperation between ITU and IETF conferencing systems could be 236 addressed: 238 1) T.120 ISDN terminal users ``phone in'' to a classical IETF-style | 239 WAN internet multicast session (e.g. an IETF broadcast). 241 1a) Actually, not just one terminal but a whole T.120 242 conference network is built on the T.120 side. 244 1b) The internet WAN session becomes more controlled than a 245 ``classical'' session -- more information needs to be 246 relayed to the T.120 session control. (This, obviously, 247 depends on what kind of session control is used on the 248 Internet side.) 250 The assumption here is that the IETF style conference is the one | 251 ``in control'' and ``phoners-in'' are accepting some semantic | 252 lossage. E.g., the T.124 (GCC) conference roster (attendance 253 list) could be incomplete, it might not be possible to perform 254 certain actions (such as addressing single participants), etc. 256 Note that for a conference in which #apps applications (such as 257 whiteboard etc.) are used, MCS/GCC runs into a hard limit of | 258 64535/(#apps+1) participants (or less than that -- the | 259 denominator may actually be higher). 261 2) LAN-wide internet multicast sessions are used behind a local 262 T.120 MCU (i.e., LAN systems don't speak T.120 but support 263 classical IETF sessions only) 264 2a) Internet multicast sessions with additional T.120 265 consciousness are used behind a local T.120 MCU (different 266 from 2?). In the simplest case, they would have to be able 267 to take part in and make use of the T.124 conference roster 268 generation process; applications could announce their 269 capabilities in the application roster, etc. | 271 2b) Additional LAN participants just listen in to multicast | 272 traffic on their LAN, these don't take an active part in | 273 the T.120 protocols. 275 The assumption here is that T.120 is ``in control'' and the LAN | 276 group has to cope. 278 3) A group of internet WAN participants and a group T.120 WAN 279 participants are joined by a gateway/MCU. Both parts get the 280 illusion of a homogeneous conferencing environment. 282 The ``gateway/MCU'' would be a much more sophisticated form of | 283 the same gateway referred to above. Achieving a homogeneous 284 conferencing environment certainly would require a high degree 285 of semantic compatibility of the IETF conference control 286 protocol with those of the ITU. 288 8. Technical implications 290 For all these scenarios, special consideration must be given to the 291 following aspects. 293 [Note: These items must be sorted into those relevant specifically to 294 MMUSIC and those relevant only for a broader discussion.] 296 8.1. Type of mapping within a gateway 298 A gateway may attempt to map a semantic feature of one domain into an 299 equivalent feature of the other domain and vice-versa (bidirectional 300 mapping). Alternatively/additionally, it may attempt to tunnel 301 information only supported by one domain through the other domain in 302 A-B-A configurations (e.g., it could attempt encoding the T.120 303 application capabilities in an RTCP text attribute). 305 8.2. Agreement protocol vs. conducted mode behavior 307 The ITU-T conference control distinguishes two different modes of 308 operation: a conducted and a non-conducted mode. In conducted mode, 309 a single participant largely controls the conference requiring the 310 others to query for permission to perform certain actions (which 311 actions are affected is defined in the session description as well as 312 the respective recommendations for conferencing applications). In 313 non-conducted mode no such restrictions are imposed. 315 These two modes represent the two extremes that can be thought of 316 when using the MMUSIC agreement protocol; they could be modeled by | 317 specific voting rules in the MMUSIC agreement protocol, which allows | 318 other styles of voting rules as well. Within the ITU-T conference | 319 control no such intermediate modes are defined. 321 8.3. Resource control (bandwidth management) 323 The current approach pursued by SG 15 is to limit the number of AV 324 connections gatewayed into a LAN. 326 In addition, possibly, recoding will be required between high and low 327 bandwidth environments. 329 8.4. Addressing 331 Participants will have to be addressed by POTS/ISDN numbers 332 (generally E.164) as well as by addresses from internets and the 333 Internet. This is confounded further by ITU embracing IPX as well as 334 IP. 336 8.5. Session description 338 In the ITU model, a session is ``described'' by participants that 339 update roster information and that actually start applications based 340 on the capabilities in that roster information. Currently, only a 341 small static information base may be configured at conference startup 342 time (part of which remains unchanged throughout the course of the 343 conference). This information base describes the conference (e.g. 344 the conference name) and defines some attributes of the conference 345 (conducted or not, some authentication mechanism, e.g. a password in 346 the simplest case, etc.). A more detailed a priori description of | 347 the conference will be defined in the new ``T.RES'' advance | 348 reservation work. 350 In the classical IETF model, the session description is broadcast 351 beforehand; it cannot be changed during the session or adapted to the 352 capabilities of the participants. Other uses of the IETF session 353 description language SDP are being considered; note that currently 354 multicast address allocation (see also below) is intertwined with 355 session description broadcasting. 357 8.6. Authentication 359 Internet applications generally will use cryptography based end-to- 360 end authentication and confidentiality. 362 MCS does not use authentication within the conference; instead, 363 unwanted participants cannot obtain transport connections to the MCS 364 domain (data part of the conference) at all. The T.120 conference 365 control protocol GCC currently allows for a challenge-response 366 mechanism for authentication to the MCS domain. Confidentiality can 367 be achieved using H.233/H.234 by enciphering the entire transport | 368 stream, i.e., hop-by-hop based enciphering, possibly separately for | 369 audio, video, and MLP (``data''). This requires trusted MCUs 370 (proposals for operations with non-trusted MCUs are being made). 372 8.7. Use of Multicasting 374 Given the intent of ITU SG15 to generate a draft standard by November | 375 1995 (to be voted on in 1996), complications such as multicasting | 376 have a relatively low priority. It seems unlikely that SG8 will come | 377 around quickly to extending MCS to incorporate multicast subtrees 378 (based on multicast transports such as MTP-2 or RMP). Multicast will | 379 be an option for ITU's usage of RTP, but note that ITU needs a handle | 380 on IP multicast address allocation for this to become real (see next | 381 item). 383 In any case, for operational use of multicasting in environments that 384 may or may not have multicast capable routers (or operating systems, 385 or protocol stacks) it must be possible to use point-to-point meshes 386 as a fallback. This fallback should be automatic; manual 387 configuration is unlikely to be workable. One solution currently 388 being offered within the ITU environment is to start a conference as 389 a point-to-point mesh and to allocate a multicast address and to 390 start testing multicast connectivity simultaneously. Terminals that | 391 do have multicast connectivity withdraw (partially) from the point- 392 to-point mesh. 394 8.8. Multicast address allocation 396 In IETF conferences, the allocation of multicast address is done 397 administratively (by applying for an address at IANA) or by global 398 broadcasting of address claims. Administratively scoped multicast 399 may alleviate the problem for conferences confined to a site only. 400 For operational use, an address allocation mechanism must be found 401 that scales to large numbers of conferences and avoids conflicts 402 quite reliably. Note that conferences that must be protected from 403 denial-of-service attacks will need a form of authentification that 404 might make conflicts less of a problem. 406 9. Security Considerations 408 Any interoperation between ITU-based systems and Internet-based 409 systems must take care to preserve the point-to-point link based 410 security model underlying the ITU standards. In T.120, much of the 411 access control relies on being able to reject the attempt to join a 412 conference via an ISDN connection to an MCU. See also 413 ``Authentication'' above. 415 10. Authors' Addresses 417 Carsten Bormann 418 Universitaet Bremen FB3 MZH 5180 419 Postfach 330440 420 D-28334 Bremen 421 GERMANY 422 cabo@informatik.uni-bremen.de 423 Joerg Ott 424 Technische Universitaet Berlin FR 6-3 425 Franklinstr. 28/29 426 D-10587 Berlin 427 GERMANY 428 jo@cs.tu-berlin.de 430 Appendix: Pertinent standards bodies 432 ITU-T SG8: T.120 standardization (MCS, application protocols, 433 conference control) 435 ITU-T SG15: defines LAN-WAN gateway 437 IMTC CNAG: defines LAN-WAN interworking | 439 IETF AVT WG: defines real-time transport and payload data formats 441 IETF MMUSIC WG: defines conference control