Interfacing DAVIC with the Internet to Implement a Real-Time Information Infrastructure

Hiroyuki Yamada <hiro-y@gctech.co.jp>
Tsuyoshi Hanamura <hana@gctech.co.jp>
Takao Kasahara <kasahara@gctech.co.jp>
Shingo Ueda <zombi@gctech.co.jp>
Harutaka Fukutome <haru-f@gctech.co.jp>
Hiroshi Fujiwara <fujiwara@gctech.co.jp>
Graphics Communication Laboratories
6F Annex Thoshin Bldg., 4-36-19, Yoyogi, Shibuya-Ku, Tokyo 151, Japan
Tel.: 81-3-5351-0181
Fax: 81-3-5351-0185

Introduction

Real-time Internet protocols generally place inordinate loads on existing networks when used to transfer large data, such as MPEG video.

Demand for this real-time data on the Internet could be supported in a much more efficient manner by the system developed by the Digital Audio-Visual Council (DAVIC) [1]. This system delivers high-quality, real-time video data, using fast core networks such as ATM. But since DAVIC is still in its youth, it has yet to produce any applications with the extreme popularity required to drive the implementation of such an expensive independent network.

We will describe a hybrid system in which not-so-resource-demanding DAVIC content is made available over the Internet for easy and inexpensive accessibility, while resource-demanding content is provided over the real-time DAVIC networks. Users access the nonresource-demanding DAVIC information such as content introductions or previews via a gateway that converts protocols between DSM-CC [2] and Hypertext Transfer Protocol (HTTP) [3], while users who need high-quality, real-time video data access it directly through DAVIC networks, avoiding unnecessary loads on the Internet.

We begin with a brief description of the DAVIC system, followed by our proposal for a hybrid system interfacing DAVIC with the Internet to implement a real-time information infrastructure.

Figure 1 shows a general architecture of this hybrid DAVIC Internet access.

+-------------------------------- INTERNET ----------------------------------+
|                                                                            |
|                                                                            |
|                   +====================================+                   |
|                   |                                    |                   |
|                   |          DSM-CC / HTTP             |                   |
|                   |                                    |                   |
|              +----------------------------------------------+              |
|              |    |                                    |    |              |
| +------------------------------------------------------------------------+ |
| |            |    |              DSM-CC                |    |            | |
| |            |    +====================================+    |            | |
| |            |                                              |            | |
| | +--------+ | +----------------+      +------------------+ | +--------+ | |
| | |        | | |                |      |                  | | |  STB   | | |
| | | Server |-|-|  Core Network  |------|  Access Network  |-|-|  PC    | | |
| | |        | | |                |      |                  | | |  WS    | | |
| | +--------+ | +----------------+      +------------------+ | +--------+ | |
+-|------------+                                              +------------|-+
  |                                                                        |
  +------------------------------- DAVIC ----------------------------------+
Figure 1. General architecture of DAVIC Internet access

DAVIC

DAVIC, a nonprofit association established in June 1994 in Switzerland, is promoting global standards for broadband digital services using a variety of delivery media, such as the information superhighway or satellite broadcasts, ensuring compatibility and interoperability on a worldwide basis. Applications being considered for the DAVIC system are mainly those that require real-time multimedia interaction, such as video on demand, teleshopping, broadcasting, games, telework, and karaoke on demand.

DAVIC system overview

According to the DAVIC system reference model, DAVIC consists of two major subsystems called the Service Provider System (SPS) and the Service Consumer System (SCS). In addition, a Delivery System exists between SPS and SCS in order to connect them. SPS provides a service gateway that manages sessions and resources to transmit real-time multimedia streams such as MPEG video and audio. Finally, a Content Provider System (CPS) provides the processing required by SPS when content-information is being loaded to the server. Figure 2 shows this DAVIC system reference model.

  +--------------+                                        +--------------+
  |   Service    |                                        |   Service    |
  |   Provider   |                    +----------+        |   Consumer   |
  |   System     |                    | Delivery |        |   System     |
  |   ( SPS )    |--------------------| System   |--------|   ( SCS )    |
  |              | Principal Services |          |   S1   |              |
  |              | Layer Interface    |          |        |              |
  |              |                    |          |        |              |
  |              |<-------------------|          |------->|              |
  |              | Application        |          |   S2   |              |
  |              | Services Layer     |          |        |              |
  |              | Interface          |          |        |              |
  |              |                    |          |        |              |
  |              |<------------------>|          |<------>|              |
  |              | Session/Transport  |          |   S3   |              |
  |              | Services Layer     |          |        |              |
  |              | Interface          |          |        |              |
  |              |                    |          |        |              |
  |              |<------------------>|          |<------>|              |
  |              | Network Services   |          |   S4   |              |
  |              | Layer Interface    |          |        |              |
  |              |                    |          |        |              |
  |              |--------------------|          |--------|              |
  |              | Physical Interface |          |        |              |
  |              |                    |          |        |              |
  +--------------+                    +----------+        +--------------+
Figure 2. DAVIC system reference model

At present, both cabled networks and wireless networks are being considered for the Delivery System, but the most likely candidate for DAVIC's core network is ATM over cabled networks.

There are multiple information flows modeled for DAVIC. The primary flows are as follows:

In S2 and S3, DAVIC uses the Digital Storage Media Command and Control (DSM-CC) protocol to provide the control functions and operations specific to managing MPEG bitstreams. DSM-CC manages resources and sessions in the network. One example of a resource is network bandwidth. Sessions are an associated collection of resources required to deliver a service. DSM-CC defines a logical entity called the Session and Resource Manager (SRM), which provides a centralized management of the DSM-CC sessions and resources.

Interfacing DAVIC with the Internet

In order to access DAVIC resources without directly connecting to the DAVIC core network, interface resources must be made available on the Internet. These would include gateways between DSM-CC and HTTP, as well as SRM and Content Service Element (CSE) services.

An Internet user could use an ordinary Web browser to access a gateway and receive content previews or access content program database from the DAVIC system. The previews or the content information would be nonresource-demanding objects, including documents or images and possibly video if resources permit. We propose three implementations.

In the first, DAVIC data is requested of the gateway via HTTP (*1 in Figure 3 ). The gateway converts HTTP requests to DSM-CC, requests SRM and CSE services via S2 (*2) and S3 (*3) paths, and gets results from CSE via an S1 and S2 path (*2). The gateway then converts this data into HTTP for return to the user. This first scenario is the simplest and should be most convenient for most ordinary Web users. S2 is mainly used for retrieving free content data from DAVIC network in this case. If S1 data flows in this scenario, it should be limited to very low bit rate data for users with strict bandwidth limitations, and the user's browser should be MPEG aware. If necessary, the browser should be able to construct another data path in addition to the HTTP path.

In the second scenario, it is possible for a CSE to send the user S1 data directly through the Internet by using ReSerVation setup Protocol (RSVP) [4]. The requesting procedure is the almost the same as in the first scenario, except for the S1 path, which uses a dedicated line with RSVP or ATM support, and the S4 path for RSVP setup. Higher service quality will be obtained by using the RSVP option.

The final scenario is that only users who require high-quality, real-time video data can get it by connecting directly to a CSE via the DAVIC network and using an S1 path. This connection will be expensive and IP is not used here, but the user can obtain REAL real-time, high-bandwidth services without overloading the Internet.

In each of these cases, flow control of S1 data--such as stop, resume, or pause--could be managed from the Web browser by providing buttons that the user can click.

+-------------------------------- INTERNET ----------------------------------+
|                      .                                                     |
|   +--------------+   .                                    +--------------+ |
|   | Session and  |   .   S3 (*3)                          | Other server | |
|   | Resource     |----------------+                   +------------+     | |
|   | Manager (SRM)|   .            |                   | FTP server |     | |
|   +--------------+   .   +------------------+      +----------+    |-----+ |
|           |          .   |  DSMCC/HTTP      |      |  Other   |    |       |
|   S3 (*3) |          .   |  Gateway         |      |  WEB     |----+       |
|           |          .   |  ( DAVIC httpd ) |      |  Server  |            |
|   +--------------+   .   +------------------+      +----------+            |
+---| Content      |  S2/S1 (*2)  |    |                   |                 |
.   | Service      |--------------+    | HTTP              |HTTP             |
+---| Element(CSE) |--------------+    | (*1)              |FTP              |
|   +----------+-+-+  S1/S4 (*4)  |    |                   |Others           |
|        |     | |      .         |    |                   |                 |
|        |     | +----------------|----|-------------------|-----------------+
|        |     |          .       |    |                   |
|        |     +-----------+  +----------------------------------------------+
|        |                 |  |                                              |
|        | ATM or other    |  |              WEB Browser                     |
|        +-----------------|--|                                              |
|          S1 (*5) (w/S2)  |  |         PC / WS / Set-Top-Box                |
|                          |  |  ( MPEG2 decoder needed for receiving it )   |
+---- DAVIC Network -------+  +----------------------------------------------+
Figure 3. Data flow of proposed system

Protocol stacks using an HTTP gateway

Figure 4 shows examples of protocol stacks for the proposed system. Stack (*4)-S4 is especially useful for supporting RSVP and Integrated Services in the Internet Architecture (Int-Serv).

RSVP is a network control protocol that will allow Internet applications to obtain special qualities-of-service (QoS) for their data flows by means of reserving resources on the Internet. Int-Serv is a working group of the Internet Engineering Task Force (IETF) developing QoS classes and formats for the Internet resources deployed by RSVP. They are and will be used both on non-ATM and ATM IP networks. It appears that IETF has come to the consensus that RSVP and Int-Serv should be used for QoS specification of IP over ATM. Thus, for interfacing DAVIC with the Internet, it may be necessary to use RSVP for S4.

        (*1) Internet HTTP

        |--------------------|
        | HTML ...           |
        |--------------------|
        | HTTP               |
        |--------------------|
        | TCP                |
        |--------------------|
        | IP                 |
        |--------------------|

        (*2)-S2                    (*2)-S1

        |------------------|       |------------------------|
        | Application      |       | Real Time Protocol [5] |
        |------------------|       |------------------------|
        | DSM-CC U-U       |       | UDP                    |
        |------------------|       |------------------------|
        | OMG IDL over UNO |       | IP                     |
        |------------------|       |------------------------|
        | TCP              |
        |------------------|
        | IP               |
        |------------------|

        (*3)-S3

        |--------------|
        | DSM-CC U-N   |
        |--------------|
        | TCP / UDP    |
        |--------------|
        | IP           |
        |--------------|

        (*4)-S4                       (*4)-S1

        |--------------------|        |--------------------|
        | RSVP               |        | MPEG2 TS           |
        |--------------------|        |--------------------|
        | IP                 |        | RTP                |
        |--------------------|        |--------------------|
        | PPP                |        | UDP                |
        |--------------------|        |--------------------|
        | Dedicated Line     |        | IP                 |
        |  with RSVP support |        |--------------------|
        |--------------------|        | Dedicated Line     |
                                      |  with RSVP support |
                                      |--------------------|
            or
                                             or

        |----------------|            |---------------|
        | RSVP           |            | MPEG2 TS      |
        |----------------|            |---------------|
        | IP             |            | RTP           |
        |----------------|            |---------------|
        | AAL5           |            | UDP           |
        |----------------|            |---------------|
        | ATM            |            | IP            |
        |----------------|            |---------------|
                                      | AAL5          |
                                      |---------------|
                                      | ATM           |
                                      |---------------|
      (*5)-S1

        |------------|
        | MPEG2      |
        |------------|
        | MPEG2 TS   |
        |------------|
        | AAL5       |
        |------------|
        | ATM        |
        |------------|
Figure 4. Examples of protocol stacks

Conclusion

The ability of IP to solve many problems faced by other network architectures has resulted in significant growth of the Internet. But recent strong demands for real-time applications from traditionally noncomputer fields are stretching the Internet's capacity. It is true that the Internet can provide real-time support as a testbed, but in practice it is an extremely inefficient way to supply the huge data requirements of 6 MBPS MPEG2 streams. The Internet was not designed for such real-time service.

In order to implement an environment of real-time service without placing inordinate loads on existing networks, we propose these hybrid network systems.

For future work, DAVIC will need to specify how to request and select network resources and how to accept relatively expensive S1 service, while Internet will need to consider a new specific uniform resource locator (URL) [6] for this architecture or, alternatively, to utilize Common Gateway Interface with an existing URL.

References

  1. DAVIC, "DAVIC 1.0 Specification", November 1995
  2. ISO/IEC, "Digital Storage Media Command and Control," No:13818-6, November 1995
  3. R. Fielding, H. Nielsen, T. Berners-Lee, "Hypertext Transfer Protocol: HTTP/1.1," IETF Internet Drafts, URL
    ftp://ietf.cnri.reston.va.us/internet-drafts/draft-ietf-http-v11-spec-01.txt, January 1996
  4. R. Braden, L. Zhang, S. Berson, "Resource ReSerVation Protocol (RSVP): Version 1 Functional Specification," IETF Internet Drafts, draft-ietf-rsvp-spec-11.txt,
    ftp://ietf.cnri.reston.va.us/internet-drafts/draft-ietf-rsvp-spec-11.txt, March 1996
  5. H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications," RFC 1889, January 1996
  6. T. Berners-Lee, L. Masinter, M. McCahill, Uniform Resource Locators (URL), RFC 1738, December 1994

Author information

The authors are all at Graphics Communication Laboratories (GCL), 6F Annex Thoshin Bldg., 4-36-19, Yoyogi, Shibuya-Ku, Tokyo, Japan.

Hiroyuki Yamada is a researcher of software and real-time computer network at GCL, which is an R&D company engaged in the development of high-efficiency encoding technology for video and audio and of systems for real-time networks, including the Internet. GCL was established by Japanese Key Technology Center, ASCII, Hitachi, Victor Company of Japan and NTT Electronics Technology in March 1993.