Transcript
Calhoun: The NPS Institutional Archive DSpace Repository Theses and Dissertations
Thesis and Dissertation Collection
1998-03-01
Internetworking : Distance Learning To Sea via desktop videoconferencing tools and IP multicast protocols Glover, Mark V. Monterey, California. Naval Postgraduate School http://hdl.handle.net/10945/8556 Downloaded from NPS Archive: Calhoun
DUDLEY KNOX LIBRARY NAVAL POSTGRADUATE SCHOOL MONTEREY, CA 93943-5101
NAVAL POSTGRADUATE SCHOOL Monterey, California
THESIS INTERNETWORKING: DISTANCE LEARNING "TO SEA" VIA DESKTOP VIDEOCONFERENCING TOOLS AND IP MULTICAST PROTOCOLS by
Mark V. Glover March 1998
Thesis Advisor:
Rex Buddenberg
Associate Advisor:
Don Brutzman
Approved
for public release; distribution
is
unlimited.
REPORT DOCUMENTATION PAGE
Form Approved OMB No. 0704-0188
is estimated to average 1 hour per response, including the time for reviewing searching existing data sources, gathering and maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, including suggestions for reducing this burden, to Washington headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 22202-4302, and to the Office of Management and Budget, Paperwork Reduction Project (0704-
Public reporting burden for this collection of information
instruction,
.
0188) Washington 1.
DC 20503.
AGENCY USE ONLY
(Leave blank)
2.
REPORT DATE
REPORT TYPE AND DATES COVERED Master's Thesis 3.
March 1998 4.
TITLE
AND SUBTITLE
5.
FUNDING NUMBERS
INTERNETWORKING: DISTANCE LEARNING "TO SEA" VIA DESKTOP VIDEOCONFERENCING TOOLS AND D? MULTICAST PROTOCOLS AUTHOR(S) Glover, Mark V.
6.
7.
8.
PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)
Naval Postgraduate School Monterey, CA 93943-5000 9.
10.
SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES)
11.
PERFORMING ORGANIZATION REPORT NUMBER
SPONSORING/MONITORING
AGENCY REPORT NUMBER
SUPPLEMENTARY NOTES
The views expressed
in this thesis are
those of the authors and
do not
reflect the official policy or position of the
Department of Defense or the U.S. Government.
DISTRIBUTION / AVAILABILITY STATEMENT
12a.
Approved 13.
for public release; distribution
is
12b.
DISTRIBUTION
CODE
unlimited.
ABSTRACT
While deployed at sea, sailors are traditionally provided much of their education at sea through correspondence and pace courses. But with recent developments in the Internet and videoconferencing, it is now feasible to deliver realtime educational material anywhere, even to a ship at sea. This thesis investigates the current status of networked
desktop videoconferencing technology, and
its
use in support of Joint Vision 2010, with respect to Distance Learning.
It
provides an analysis of videoconferencing protocols, standards, and applications, as well as a videoconferencing pilot
The objective of the analysis is to determine the viability and economical benefits of using videoconferencing technology and collaboration tools, from the desktop, as a means for simultaneously delivering synchronous and project.
asynchronous distance learning material from an academic location to multiple students at remote locations. The results show that desktop videoconferencing technology, via IP based networks in the Defense Information Infrastructure, is a
numerous economical benefits, such as a decreased spending for room-based systems.
viable tool that can add to rely 14.
on
large,
SUBJECT TERMS
Videoconferencing, Multicast, H.320, H.323, H,324,
MBone, DISN,
travel
and eliminating the need
NUMBER OF PAGES
15.
ADNS
137
17.
SECURITY
CLASSIFICATION OF
REPORT
18.
SECURITY CLASSIFICATION
OF THIS PAGE Unclassified
19. SECURITY CLASSIFICATION OF ABSTRACT
Unclassified
CODE
16.
PRICE
20.
LIMITATION
OF
ABSTRACT
UL
Unclassified
NSN
7540-01-280-5500
Standard Form 298 (Rev. 2-89) Prescribed by ANSI Std. 239-18 298-102
11
Approved
for public release; distribution
is
unlimited
INTERNETWORKING: DISTANCE LEARNING "TO SEA" VIA DESKTOP VIDEOCONFERENCING TOOLS AND IP MULTICAST PROTOCOLS Mark V. Glover Lieutenant, United States
B.S.,
Navy
Norwich University, 1990
Submitted
in partial fulfillment
of the
requirements for the degree of
MASTER OF SCIENCE IN INFORMATION TECHNOLOGY MANAGEMENT from the
NAVAL POSTGRADUATE SCHOOL March 1998
'
U7
DUDLEY KNOX LIBRARY NAVAL POSTGRADUATE SCHOOL Monterey ca 93943-5101
ABSTRACT
While deployed at
at sea, sailors are traditionally
sea through correspondence and pace courses.
Internet and videoconferencing,
it
is
now
material anywhere, even to a ship at sea.
much
of their education
But with recent developments
feasible
to
in the
deliver real-time educational
This thesis investigates the current status of
networked desktop videoconferencing technology, and 2010, with respect to Distance Learning.
provided
It
its
use in support of Joint Vision
provides an analysis of videoconferencing
protocols, standards, and applications, as well as a videoconferencing pilot project.
objective of the analysis
is to
The
determine the viability and economical benefits of using
videoconferencing technology and collaboration tools, from the desktop, as a means for simultaneously delivering synchronous and asynchronous distance learning material from
an academic location
to multiple students at
remote locations.
The
results
show
that
desktop videoconferencing technology, via IP based networks in the Defense Information Infrastructure, is a viable tool that
can add numerous economical benefits, such as a
decreased spending for travel and eliminating the need to rely on large, room-based systems.
VI
TABLE OF CONTENTS
INTRODUCTION
I.
1
A.
INTRODUCTION
1
B.
MOTIVATION
1
C
OBJECTIVE OF THESIS
2
D.
SCOPE OF THE THESIS
3
E.
METHODOLOGY
4
F.
THESIS ORGANIZATION
5
RELATED WORK
H.
7
A.
INTRODUCTION
7
B.
BRIEF HISTORY OF VIDEOTELECONFERENCING
7
C
DISTANCE LEARNING
8
Methods
1.
Traditional Educational
2.
The Value of Distance Learning
3.
Distance Learning via the Internet
10
4.
Videoconferecing in the Department of Defense
11
8
in the
Navy
IH MAJOR VIDEOCONFERENCING STANDARDS
10
15
A.
INTRODUCTION
15
B.
BACKGROUND DMFROMATION
15
vii
st
C.
1
D.
2
GENERATION STANDARDS
nd
16
GENERATION STANDARDS
17
H.320
17
a.
Picture Resolution
18
b.
Frame Rate
19
c.
Preprocessing and Postprocessing
19
d.
Motion Compensation
19
H.320 and ISDN
20
1.
2.
3
E.
rd
GENERATION STANDARDS
1.
Internet Videoconferencing
2.
Plain
22
Old Televeision System (POTS)
VIDEO COMPRESSION
F.
22
23
24
1.
H.261 Structure
2.
Discrete Cosine Transform
3.
Quantization
31
4.
Motion Compensation and Estimation
32
5.
MPEG
36
28
(DCT)
30
G.
AUDIO COMPRESSION
36
H.
DATA STANDARDS
38
I.
SUMMARY
39
MULTICASTING AND THE MBone
41
A.
INTRODUCTION
41
B.
BACKGROUND
41
IV.
IP
viii
IP
C. 1.
MULTICASTING
42
IP Multicast Protocols
45
Group Management Protocol (IGMP)
46
a.
Internet
b.
Real-Time Transport Protocol Version 2 (RTP)
48
c.
Real-Time Control Protocol (RTCP)
49
d.
Resource Reservation Protocol (RSVP)
50
e.
Real-Time Streaming Protocol (RTSP)
53
2.
Reliable IP Multicast
53
3.
Group Setup Protocols
54
4.
Other IP Multicast Issues
55
a.
Router Support
55
b.
Other Network Issues
58
MULTICAST BACKBONE (MBone)
D. 1.
MBone Requirements
58
59
E.
MBone ISSUES IN DISTANCE LEARNING
62
F.
SUMMARY
63
IMPLEMENTING IP MULTICAST ACROSS THE NAVAL NETWORK
V.
ARCHITECTURE TO SEA
65
A.
INTRODUCTION
65
B.
BACKGROUND
65
C.
DESKTOP SYSTEMS CONNECTIVITY
66
1.
POTS
66
2.
Asynchronous Digital Subscriber Line (ADSL)
67
ix
Cable
3.
Modems
68
TERRESTRIAL TRANSMISSION
D.
1.
a.
69
Routing
69
Tunneling
69
b.PIM-SM IP over
2.
71
IP Switching
b.
Tag Switching
73
ATM Considerations
74
:
VIDECONFERENCING OVER DISN's SATELLITE SYSTEMS
E.
72
74
1.
Space Segment
75
2.
Terminal Segment
75
3.
Network Cache
at the
Gateways
SHIPBOARD
F.
1.
VI.
ATM
a.
c.
G.
70
ADNS CONCLUSION
VIDEOCONFERENCING APPLICATIONS
76 78 78 78
81
A.
INTRODUCTION
81
B.
VIDEOCONFERENCING APPLICATIONS
81
C.
RECOMMENDED STANDARDS
83
D.
HARDWARE
87
E.
SUMMARY
88
VIDEOCONFERENCING DEMONSTRATION
89
A.
INTRODUCTION
89
B.
OVERVIEW
89
C.
DEMONSTRATION
90
D.
RECORDING A BROADCAST
92
E.
PLAYING BACK AN MBone RECORDED SESSION
93
Vn.
R
EVALUATION OF RESULTS
G.
Vfll.
93
SUMMARY
94
CONCLUSIONS AND RECOMMENDATIONS
97
A SUMMARY OF FINDINGS
97
RECOMMENDATION FOR FUTURE RESEARCH
B.
APPENDIX A. GLOSSARY OF TERMS
98
99
APPENDIX B. INSTRUCTION FOR THE BASIC OPERATION OF THE MBONE
VCR ON DEMAND SERVICE (MVOD)
103
A.
OVERVIEW OF THE MVoD SERVICE
103
B.
DOWNLOADING THE TOOLS
105
C.
USING THE MVoD SERVICE
105
1.
Connect to a Server
2.
Select an
3.
Recording a Session
4.
Editing a Session or
MBone
106
106
session
107
Media
108
XI
Mute a Media
108
5.
Play a Session
108
6.
Fast
7.
Random Access with the
a.
Forward and Rewind
109
Session Slider
109
8.
Loop Mode
109
9.
Quick-Keys
110
D.
KNOWN BUGS and SHORTFALLS
1
F.
SUMMARY
Ill
10
LIST OF REFERENCES
113
INITIAL DISTRIBUTION LIST
117
xn
LIST
OF FIGURES
Figure 2-1 Productive applications of a distance education approach [Biggs, 94]
10
Figure 3-1 Encoder Flow Diagram
28
Figure 3-2 H.261 Data Structure
[Jin,
Figure 3-3 Macro Block Structure Figure 3-4
Two
[Jin,
96]
29
96]
[Jin,
30
96]
dimensional Discrete Cosine Transform
Figure 3-5 P-coding (interframe)
[Jin,
[Jin,
96]
31
33
96]
Figure 3-6 I-coding (intraframe) [Jin,96]
34
Figure 3-7 H.261 frame sequence encoding [Jin,96]
34
Figure 3-8 Run-Length Encoding [Jin,96]
35
Figure 3-9 Frame Rate vs. Bit Rate for compressed data
36
Figure 4-1 Requirements for IP Multicasting
44
Figure 4-2
IGMP Messages on a LAN
Figure 4-3
RSVP Protocol
Figure 5-1
DISN Architecture
67
Figure 7-1
MVoD Architecture [Holfelder, 97]
91
[Johnson, 97]
47 53
[Johnson, 97]
Xlll
XIV
LIST OF TABLES
Table 3-1
:
Videoconferencing Standards
15
Table 3-2: H.320 Recommendations [Nerino, 94]
18
Table 3-3: Levels of H.320 compliance [Nerino, 94]
20
Table 5-1: Estimated Digital Storage Requirements
77
Table 6-1: Videoconferencing Standards over IP
xv
QoS Networks
86
XVI
ACKNOWLEDGEMENTS
First
and foremost,
encouragement and patience, I
wish
acknowledge
I
this
time
at
my
wife Anitra.
Without your continued
NPS would not have been
to express sincere appreciation to Professors
Their keen insight and enthusiasm for the subject matter enjoyable learning experience.
xvn
as successful.
Buddenberg and Brutzman.
made
this a
very worthwhile and
XV111
I.
A.
INTRODUCTION
INTRODUCTION This thesis investigates the current status of networked desktop videoconferencing
technology, and
It
its
use in support of Joint Vision 2010, with respect to Distance Learning.
provides an analysis of videoconferencing protocols, standards, and applications, as well
as a videoconferencing pilot project.
It
also follows
work from
the thesis "Internetworking:
Economical Storage and Retrieval of Digital Audio and Video for distance learning, [Tiddy, 96].
B.
MOTIVATION DoD
learning
has implemented various videoconferencing systems in order to
more
The
available, but there are
still
major obstacles.
room
model
or roll-about system, with proprietary hardware and software. Also,
required to travel to the room-based systems in order to participate in the
training sessions.
Surveys of room videoconferencing system users have identified desired
features such as shared drawing area, the ability to connect to multiple sites,
incorporate computer applications into the conference [Retinger, 95]. large geographical dispersion of military personnel across
also the
distance
current systems that have been put into place are usually based upon a
using a dedicated users are
still
make
problem of coordination of class times between the
and ways
to
Since there can be a
numerous time zones, there instructor and the student.
is
Using desktops
become more
the
videoconferencing has multiple advantages:
familiar with the use of PCs, they will not need to learn
instruction using a
the equipment.
to deliver
room based system, which
The
how
As to
users
provide
usually requires a dedicated person to
mange
instructor does not have to deal with scheduling blocks of time to use
room-based systems. Conferencing over the desktop can be more relaxed and
impromptu, contributing
to better
human
interaction.
Most desktop videoconferencing
software has whiteboard capabilities, allowing the student and instructor to share data in real-time.
C.
OBJECTIVE OF THESIS The primary
objective of this thesis
is
to describe
how desktop
videoconferencing
technology and collaboration tools can be used either synchronously or asynchronously to deliver Distance Learning content over an IP based network to multiple students at remote
Instructors
locations.
Pacific, an
(NPS).
Admiral
The
in
might be a Chief Petty Officer (CPO)
Washington D.C., or a professor
at
the
topics of desktop videoconferencing in regard to
at Fleet
Training Center
Naval Postgraduate School
human/computer
interaction
aspect and social issues will not be discussed here, but can be found in [Rettinger, 95]. Test
and evaluation of a prototype system
at
distance learning can be achieved via the
NPS
PC
to
provides an example demonstration
how
any remote user's desktop. Specifically, the
research and experiments for this thesis were designed to collect data to address the
following research questions:
•
How can we
leverage the Defense Information Systems Network (DISN) to
implement desktop videoconferencing distance learning •
What
are
some of the
to the sea?
current protocols and standards available in order to
multicast desktop videoconferencing applications via an IP based network?
•
JMCOMMS/ADNS program to implement desktop videoconferencing distance learning to a shipboard LAN at How can we
leverage the Navy's current
sea?
•
•
What
are the technical and
management concerns
in order multicast
videoconferencing applications to the user
at
What impact will
DISN have on
multicasting video over
sea?
the system
bandwidth/availability?
•
What
are the hardware and software requirements for the instructor
in order to
and student,
maintain reliable communications throughout a
course of instruction?
•
What that
•
are
some of the
available videoconferencing applications
can be used for distance learning?
How much will desktop videoconferencing
(distance learning) offset travel
expenses for resident education?
Preliminary results are evaluated for each of these questions.
SCOPE OF THE THESIS
D.
The scope of
this
thesis includes:
(1)
Show how
multicasting across IP-based
networks can be used to deliver desktop videoconferencing distance learning to sea.
Review some of the currently
available videoconferencing products and
be leveraged for distance learning,
(3)
Using a prototype,
test
how
and evaluate the
their use
is
to evaluate
can
feasibility of
the delivery and storage of videoconferencing data over an IP based architecture to-sea.
goal
(2)
The
and determine the economical and technical benefits of using currently 3
available desktop videoconferencing applications (versus cart and room-based systems) as
an alternative tool that an instructor and student can use to exchange course material over an IP-based Internet and DISN.
The demonstration card, audio card,
incorporates desktop workstations with cameras, video capture
and a network connection to IP multicast capable
routers.
standard Internet protocols normally found on current desktop computers,
videoconferencing
applications
capable
of
multicasting
synchronously or asynchronously, to naval students
E.
at
video
it
and
remote locations and
Besides the also contains
audio,
either
at sea.
METHODOLOGY The methodology used •
Conduct a
to
produce
literature search
this thesis included the following tasks:
of books, magazines,
articles, Internet
resources and
other library information services describing videoconferencing technology and current software/hardware that can be applied to distance learning in the military.
•
Conduct a search of books, magazines,
articles, Internet resources,
and consult
with companies to determine the current videoconferencing software and
hardware that are best suited for Internet-to-the-sea videoconferencing. •
Develop a model
to
demonstrate
how
distance learning courses can be
seamlessly transported from the instructor to the Internet and the Navy's
communication networks videoconferencing.
infrastructure, in order to provide Internet-to-sea
Develop a prototype videoconferencing system
that
might be used as a part of a
"toolbox" that can be used export a correspondence course or graduate school class to a ship.
Consult with the Space and Naval Warfare Systems the Research, Testing
Command (SPARWAR)
and Evaluation Division of the Naval
and Ocean Surveillance Center
(NRAD) on
and
Command Control
current developments of the Joint
Maritime Communications System/ Automated Digital Network System
(JMCOMMS/ADNS)
F.
and
its
current use with videoconferencing technology.
THESIS ORGANIZATION This thesis
is
composed of
eight chapters.
objectives, research questions, scope
Chapter
II
This chapter provides the motivation,
and methodology employed
to
conduct the research.
provides the history of videoconferencing, and related work.
Chapter
III
discusses the current video and audio compression protocols and standards that are required for current videoconferencing systems.
Chapter IV describes the various multicasting
protocols and standards necessary to provide scalability, cross-platform support and quality
of service (QoS) necessary
to
provide distance learning from the desktop over the
commercial and naval IP based networks. Chapter applied over the
sea.
DISN
V
describes various options that can be
architecture that will support IP based desktop videoconferencing to
Chapter VI compares some of the desktop videoconferencing applications and
protocols required to
deliver distance
demonstration project and findings.
recommendation for future research.
education to sea.
Chapter VII discusses the
Chapter VIII provides the conclusion, summary and
RELATED WORK
II.
INTRODUCTION
A.
This chapter provides a brief history of videoconferencing and the traditional
methods used
to provide distance learning to personnel in
remote locations.
It
gives a brief
overview of the various methods that can be employed to deliver distance learning across a
network (WAN). solutions used in the
Finally,
it
some of
describes
the current VTC/videoconferencing
Navy and DoD.
BRIEF HISTORY OF VIDEOTELECONFERENCING
B.
when AT&T's
President, Walter S.
Gifford, used Video Teleconferencing to speak with the Secretary of
Commerce, Herbert
Videoconferencing was
Hoover. [Nerino, 94]
Not
first
introduced in 1926
until the late forties
and early
fifties,
with the advent of the
television,
did the next major breakthrough in video technology
television,
videoconferencing
introduced
its
did
not
picture telephone at the
see
1964
videoconferencing contained frequencies
networks
at that time,
expensive
satellites
New York
By
affordable.
World's
Fair.
Even
until
After
AT&T
then, because
to provide the
medium needed
for high
1983, full-bandwidth satellite transmissions
cost over $1 million per year [Nerino, 94].
more
major breakthrough
about.
were beyond those used by telephone
that
were used
bandwidths required for videoconferencing. still
another
come
Today such
satellite links are
becoming
As
new advances
the 1970's progressed,
in
computing power and improved methods
for converting analog signals to digital formats resulted in telephone service providers
transitioning to digital transmission
systems.
methods
to
compliment the existing analog processing
Although videoconferencing has become more widely used for services
business meetings, collaborative research, distance learning,
performed over dedicated leased
lines
etc.,
like
these service are generally
and usually requires expensive room-based or
roll-
about videoconferencing systems.
Today, due to faster desktop computers and the rapid expansion of the World Wide
Web
and the
locations has
Internet, transmitting real-time video using
become
Although there
practical.
is
desktop computers to remote
currently an explosion in the
number of
applications that can transmit and receive streaming audio and video to and from a
PC
over
the Internet, there continues to be significant interoperability, protocol and architectural
issues that
must be addressed
if
videoconferencing
is
to
become commonplace from
the
desktop.
C.
DISTANCE LEARNING
1.
Traditional Educational
Methods
Educational development has been always been required in the career progression of naval personnel.
This training
is
essential to achieving
as well as national strategic objectives [Emswiler,
methods of providing the necessary education following methods:
8
to
and maintaining national
1995].
security,
Traditionally, the primary
Naval personnel has been through the
•
Short-term temporary duty seminars
•
Resident education
at
technical schools (A, B, and
•
Resident education
at
undergraduate or graduate educational institutions,
e.g.
•
C
schools)
War College.
Naval Postgraduate School (NPS) or Naval
Postal-based correspondence courses by postal mail.
Courses that require travel on a
TAD basis are useful
type training nevertheless, this approach
is
for initial or technical refresher
costly and requires travel
by the
instructor,
student or both.
Resident education for
two
years,
at
on average.
NPS
requires students to stay
away from
the operational forces
Although many courses require the student to be present
to
obtain the desired educational benefit, others can be easily and readily exported to sea or a
remote shore location. Traditionally, postal-based correspondence courses have been necessary
remote locations
that naval personnel are often stationed.
resident course, however,
If the
course
management of the correspondence course
is
will
due
to the
the equivalent to a
be substantial. In
order for the correspondence course to be successful, not only must there be a sustained
commitment from
the student, but the feedback loop to the student
continuing, timely instruction.
may be
Often such a feedback loop
is
must be amenable
not the case, as sometimes
weeks, due to numerous reasons, before the student receives feedback or
modules. As a result
many
students
do not
finish.
to
it
new
2
The Value of Distance Learning in
.
Distance learning in the
Navy can be
the
Navy
beneficial in
two important
global reach.
In a decreasing defense budget, the allocation of
pay for
and education,
travel
is
ever decreasing.
areas; cost
MILPERS
and
which
dollars,
Besides costs, the naval environment
requires personnel to be deployed at remote or isolated settings that are far from traditional
educational resources.
A
more time
efficient delivery of course material
and feedback to
the student can markedly improve the dedication of the student to complete the course of
instruction.
Figure 2-1 outlines the general situations
when
distance learning can be
advantageous to traditional methods.
•
Target audience is widely scattered and it them travel to a central training location.
•
Content or consistency in delivery is so for accuracy or correct interpretation.
•
Content
is
is
not cost effective or possible to have
critical that it
too dangerous for novices to participate in
must be carefully controlled
and distance education
will
allow for familiarization and confidence building prior to the actual situation. •
Scheduling difficulties arise because the student cannot take extended time from other critical missions to attend a normally conducted training program.
•
The expense
•
There are a limited number of qualified
of conducting live training
is
cost prohibitive.
trainers.
Figure 2-1 Productive applications of a distance education approach [Biggs, 94]
3.
Distance Learning via the Internet
The World Wide course
material
Web (WWW)
and research
tools.
provides a means of providing both time-efficient
Distance
10
education
can be
as
a
simple as a
correspondence course offered through electronic mail, something as complex as interactive video teleconferencing over the Internet, or combinations of both [Tiddy, 96].
As more
ships,
commands, and
individual units
become connected
to local area
networks (LAN's) and wide-area networks (WAN's), distance learning programs can be
more
easily implemented, ultimately providing
[Emswiler, 95].
become more
more economical resources
for training
Also, as video/audio application and transport protocols and standards
established, commercially produced products
become more
to furnish the tools necessary to provide distance learning over
of Defense (DoD) networks.
To
date,
commercial and Department
however, the growth of Internet and
applications and users are outpacing growth of bandwidth.
education and travel,
DoD
can not wait until
to use well-developed standards
readily available
With limited
this trend reverses itself.
and protocols,
i.e.
DoD
Therefore
network
dollars for
it is
critical
multicasting, compression, etc., along
with existing network infrastructures, in order to get the most efficient delivery to remote users.
Videoconferecing in the Department of Defense
4.
DoD Some
has used videoconferencing technology in a wide variety of applications.
of the major areas where
this
technology
•
Training
•
Telemedicine
•
Group Conferences/Meetings
•
Crisis
is
being used
is in:
Response
Videoconferencing technology has started to bring significant savings to DoD,
mainly
in travel expenses.
The need
for military personnel to travel to attend meetings,
11
conferences, training, and exercises has been greatly reduced for
to
equipment.
videoconferencing
descriptions of areas
The
following
commands
examples
where videoconferencing technology
that
have access
more
contain
specific
being or has been applied in
is
DoD: Training
a.)
NPS
system:
NPS
:
Distance Learning via the Multicast Backbone
has conducted "Distance Learning" or remote classroom instruction, through
the use of videoconferencing technology over the
Emswiler,
it
(MBone)
was demonstrated
that
MBone.
In a 1995 thesis
by Tracy
videoconferencing technology could be an economically
feasible approach to distance learning.
It
documented Dr. Richard Hamming's course,
"Learning to Learn", being transmitted worldwide over the
MBone
for
an entire quarter.
[Emswiler, 95]
NPS
is
also currently delivering distance learning in
4000 Video conferencing Systems over Integrated Services Interface
(ISDN BRI)
Computer Science,
lines.
Electrical
Courses, and even
Engineering,
Root
Hall, using a PictureTel
Digital Network, Basic Rate
some degree programs,
Aerospace
Engineering
are offered in
and
Information
Technology Management.
The Chief of Naval Education and Training (CNET) Electronic Schoolhouse Network (CESN) network.
It
is
a two-way video and audio multipoint, secure distance learning
allows simultaneous instruction to multiple shore and shipboard
individuals can interact both verbally and visually in a real-time mode.
provide effective training to a large number of personnel
at
Its
sites,
where
purpose
is
to
or near their duty stations,
eliminating the need for travel to distant schoolhouses, thereby reducing travel and per diem
costs.
12
The Navy's Video a
fractional
T-l
data
(VTT)
Tele-training
rate
of 384
CESN
linked via land lines and operates at
is
Communication
Kbps.
provided
is
through
government's long-haul communications network using FTS2000. Satellite capability available for shipboard
site
on board the
VTT. The network
inroads. Basically, the
:
This
is
"remotely" to a distant
97].
e.
learning
A
in
most U.
used on the
significant
applied to telemedicine:
A central
huge potential
for this technology
S.
Navy and Coast Guard
ships have medical
provide a only a basic level of care.
when Telemedicine was
is
making
is
physicians, surgical staff, etc.) can provide care
videoconferencing.
site via
exists in afloat applications, since
who can
(i.
is
16 sites nationwide and includes a
a field where videoconferencing
same idea from distance
care facility with medical expertise
personnel
made up of
USS George Washington [CNET,
Telemedicine
b.)
is
the
One
practical use
was demonstrated
USS George Washington (CVN
73) to provide
mental health examinations, during a 1997 deployment. Psychiatrists successfully evaluated
onboard 97].
patients, capturing their
Additionally, during
(NMIMC),
JWID
97, the
to questions [Koenig,
Naval Medical Information Management Center
Bethesda, Maryland sponsored a demonstration of telemedicine technologies
aboard the submarine
USS
Atlanta
outfitted with this technology, a
c.)
mood, body language and response
(SSN 712)
in Norfolk, Virginia.
tremendous benefit
Group Conferencing
:
In
in
Once
ships are routinely
Telemedicine will surely be realized.
September 1995, a major Joint Task Force (JTF)
Exercise was conducted in Panama: Exercise "Fuertes Defensas" (Strong Defense). Led by the
Commander,
18th Airborne Corps, this exercise
readiness to support and defend the
Army LGEN) was
Panama
Canal.
was conducted Each day,
able to keep advised of exercise progress
13
the
to test
United States
JTF Commander
(an
by conducting a morning
Videoconference with his Army, Navy, Air Force, and Marine Component Commanders.
These commanders were sometimes physically separated by hundreds of miles. Because of videoconferencing technology, the exercise progress, and also
was
commander was
able to both remain well informed of
able to promulgate his
own
directives and intentions for the
day.
d.)
Crisis
Response
:
There
a
is
huge
potential
videoconferencing technology for Crisis Response Management.
for
further
use
of
For example, Navy and
Marine Corps Afloat and Expeditionary Commanders might receive real-time combat instructions
from
their
Commanders might promulgate the
same
fashion,
all
for this technology in
their
way down
the
via
superiors
non-combat
videoconferencing.
own
these
Task
Force
guidance to their attached ships and elements in
the chain of
crisis
Also,
command. There
management
disaster relief operations.
14
is
also a large potential
situations, such as humanitarian
IIL
MAJOR VIDEOCONFERENCING STANDARDS
INTRODUCTION
A.
This chapter will discuss the major videoconferencing standards, as they are significant issues
when implementing
distance learning to sea from the desktop.
BACKGROUND INFROMATION
B.
The that focuses
International
Telecommunications Union (ITU), a body of the United Nations
on developing standards, tasks the Telecommunications Standardization Sector
(ITU-T) with developing telephony standards. are used
It
develops some of the major protocols that
by IP-based videoconferencing systems today, such
as H.320, H.323,
and H.324.
Table 3-1 provides an overview of those standards.
Standard H.320
Remarks
Description
H.320
is
an
"umbrella"
standard that covers audio,
Mandatory standard by the Federal Government in 1993.
videoconferencing,
video,
graphics, and multicasting
H.323
Addresses audiovisual
Visual (audiovisual)
communications over
LANs
communications across LANs and gateways that connect
LANs to the H.324
Defines a multimedia
communication terminal operating over the Switched Telephone Network. It includes H.261, T.120, and
Incorporates the most
:
- (POTS)
ITU-T Videoconferencing Standards
15
common
global communications facility
today
V.34. Table 3-1
Internet.
The videoconferencing systems and standards described above can be viewed The
have evolved over three generations.
st
1
generation systems were generally point-to-
point, proprietary systems that usually required dedicated T-l
coding
Videoconferencing
and
compression
was
There were not
compressors/decompressors (codecs). interoperability of the various systems
to
(1.5Mbps) networks or
usually
many
was not perceived
done
by
better.
hardware
standards initially because
as an issue.
2
nd
Generation
systems were driven by Integrated Services Digital Network (ISDN). The compression was also usually
done by proprietary, hardware codecs.
compatibility
became more of an
As
the technology matured, and
issue, videoconferencing application developers
began
adopt universal standards, ultimately migrating towards ITU-T's H.320 protocol.
ISDN's
inability to scale to a large
number of
users limited
network-centric computing has migrated to the core of
many
its
to
Also,
Today, as
acceptance.
organizations, compatibility
has become a focal point in the development of videoconferencing systems, thus bringing
about 3 the
rd
generation system protocols. These
ISO seven-layer
MPEG-4
st
1
st
1
Now, advances
coming
in
modeling and simulation (such as 4
th
generation
about.
GENERATION STANDARDS generation videoconferencing systems are usually large room-based systems that
are connected via dedicated circuit switched or
point,
standards are generally designed to match
compression), and improved scalability due to multicasting,
standards are
C.
reference model.
new
Tl connections. These systems
and use proprietary system standards to deliver and receive content.
16
are point-to-
Additionally
they are not very scalable, and
many of the
international standards-based systems
are not are not backwards compatible with them.
used today
Therefore they would be not be feasible
for providing IP based distance learning to sea.
D.
nd
2
GENERATION STANDARDS H.320
1.
H.320
-
"Narrow-Band Visual Telephone Systems and Terminal Equipment"
is
the
umbrella standard that covers audio, video, videoconferencing, graphics and multicasting.
ITU-T recommends
it
as the
minimum
standard that will ensure that videoconferencing
systems will communicate with each other. H.320 covers a family of standards that governs videoconferencing systems that use coder/decoders (codecs) between 64 Kbps to 1920Kbps
(64Kbps x
30).
It
became
the
mandatory standard for the Federal Government in 1993
[Nerino, 94].
The difference between
the various videoconferencing systems will
depend upon the
optional requirements that each can support, which will ultimately effect the quality of the
audio and video.
How
well the features are implemented
Table 3-2 shows H.320 recommendations and their
17
titles.
is left
up the each manufacturer.
Video Codec
H.261:
Audio Codec
G.711: Pulse Code Modulator (PCM) of Voice frequencies G.722: 7 Khz audio-coding with 64 Kbps G.728: Coding of speech at 16 Kbps using low delay code excited linear prediction
Frame
Structure
H.221:
Control and Indication
H.230:
Video Codec services at p x 64
for
audiovisual
Frame structure for a 64 1920Kbps in audiovisual teleservices Frame-synchronous
control
to
and
indication signals for audiovisual systems
Communication Procedure
System for communication between H.242:
using
terminals
digital
establishing
audiovisual
channels
up
to
2Mbps Table
3-2:
H.320 Recommendations [Nerino, 94]
H.320 only requires vendors
to support the
minimum
standards.
When
deciding
between systems, there are currently three classes of videoconferencing systems: Class 1 -
minimum
level of support
Class 2 - Class
1
+ support of some
Class 3 - Class
1
+
The major
all
optional features
optional features
[VTEL, 95]
factors that affect system quality are picture resolution, frame rate,
preprocessing and postprocessing, motion compensation, audio, data rate and quality.
a.
Picture Resolution
Picture Resolution
Television Systems Committee picture elements (pixels)
is
the frame format of the video picture.
(NTSC) standard
and 480 active
picture frame consists of
vertical lines.
Due
to
X
144 pixel resolution, and
common
common
is
not practical for current
intermediate format (QCIF) - 176
intermediate format (CEF)
18
780 horizontal
bandwidth constraints of the
standard videoconferencing channels used today, that picture size
videoconferencing systems. H.320 uses quarter
The National
- 352
X
288
pixel
If there is
resolution.
a connection between different classes of picture resolution, systems
negotiate a resolution to the lowest one.
Frame Rate
Jr.
H.320 can support frame Class
1
rates of 7.5, 10, 15,
systems can support a frame rate of 7.5
QCIF; and
when two
class 3 supports
or
more
30
fps,
classes are used.
using CIF.
fps;
Class
Frame
and 30 frame per seconds 2, typically
about 15 fps, using
rate negotiation uses the
lower class
[VTEL, 95]
Preprocessing and Postprocessing
c.
Preprocessing reduces the amount of re-coding in the background.
poor camera
lighting, video "noise"
background when
(fps).
in fact there
is
can make the system think
none.
that there is
If there is
motion
in the
Preprocessing prevents the video encoder from
wasting time encoding "noise" caused by the poor lighting, ultimately ensuring that only real
motion gets encoded [VTEL, 95]. Postprocessing compensates for the picture degradation due to fast motion.
can help reduce the "blocking" and noisy effects caused by video codecs (discussed detail
under H.261).
Postprocessing
is
in
It
more
also can be used to enhance the frame rate, thus
reducing jerky motion [VTEL, 95].
Motion Compensation
d.
Motion Compensation aspects of motion compensation:
Motion estimation
is
performed
at
is
another video quality enhancement.
There are two
motion estimation and actual motion compensation. the video encoder to determine the motion vector of the
19
Motion compensation
subject.
is
performed
moving blocks of video data around based on estimation.
at
both encoder and decoder.
encoded section of video where motion has occurred rather than the
H.320 systems have
All
consists of
the motion vector determined during motion
moves only
Especially important at lower bit rates, motion compensation
each frame.
It
the ability to
the
entire video area of
decode a motion compensation
signal.
Providing encoded motion compensation (where the real video quality improvements are
made)
is
optional
[VTEL,
95].
Although the aforementioned factors
affect
H.320 system
quality,
many
other
elements also affect quality. Table 3-3 provides a summary of H.320 compliance.
Level 2
Level 3
(Minimum)
(Medium)
(High)
QCIF
CIF
CIF
Level
Frame Format
(176 X
(Pixels)
1
(352 x 288)
144)
Frame Speed
Up to
5
(frames/sec)
56
Data Rate
Motion Compensation Pre and post processing on both |
encoder and decoder
/
Not
X 288)
Up to 30
15
Up
Up to
64 Kbps
No
(352
384 Kbps
1.544
to
Mbps
Motion (30X30 = 900) Pre and post processing on both
Limited
Full
(6X6 = 36) Not Applicable
Applicable
encoder and decoder
Table 3-3: Levels of H.320 compliance [Nerino, 94]
2.
ISDN
H.320 and ISDN
is
a connection-oriented circuit-switched digital communication service that
provided by telephone companies and network providers.
20
It
is
provides end-to-end digital
ISDN
connectivity between local area networks (LANs).
also connect
is
LANs
128 kbps,
split
to
connects users to
widearea networks (WANs). The basic
among two
ISDN
LANs
and ca
connection bandwidth
bearer (video, audio) channels at 64 kbps each. There
an
is
additional 16kbps data channel that provides connectivity data.
Implementation of services that allow
channels
to
ISDN
provide
ISDN
channels
channels to
low-fidelity
is fairly
split
(i.e.
digitized
Telephone companies provide
flexible.
64kbps channel or
voice),
bonded
split into
two 32kbps
together.
Bonding
is
accomplished by creating one logical channel out of multiple virtual channels. For example, the
Navy's Video Information Exchange System (VDCS) uses bonding to provide bandwidth
of 112-384kbps in order to allow afloat and ashore nodes to conduct face-to-face meetings in real-time.
ISDN
offers
systems, because
it
improved videoconferencing connectivity over dedicated, point-to-point
works over existing phone
an extensive network backbone.
lines
Unfortunately
and does not require the installation of
some major reasons remain why ISDN
not a good long-range alternative for distance learning. users in a globally dispersed military environment.
deal with
(MCUs).
how
haul architecture in the
Common
Navy
ISDN
implement is
at
Operating Environment (DII
is
the lack of access to remote
Also, in order to multicast, you must
the end points are going to be handled,
Finally, continuing to
One
is
i.e.
adding multipoint control units
as the primary videoconferencing long-
odds with the Defense Information Infrastructure
COE)
migration towards the consolidation of voice,
video and data networks.
21
Recent versions of videoconferencing systems that use
although the H.320 standard
One
marketplace, consequently bundling H.320 with
its
transport
medium
use proprietary
still
possible reason:
technically sound,
is
as
many vendors
have begun to migrate to the H.320 protocol, but protocols in their videoconferencing systems.
ISDN
ISDN
ISDN
has had a poor showing in the
has inhibited
initial
acceptance of
H.320.
E.
3
rd
GENERATION STANDARDS Internet Videoconferencing
1.
As
the Internet and client-server
systems for
LANs
and
computing continued
WANs began to be developed.
videoconferencing over narrow-band
WANs
upon the IETF's Real-Time Protocol (RTP)
~
Chapter IV the Internet.
it
to grow, videoconferencing
H.323 (an extension of H.320) covers
and also over LANs.
~ which
will
Since H.323
be discussed
in
more
is
based
detail in
can be applied to streaming video over packet-switched networks such as
H.323 also applies
to point-to-point
and multipoint sessions.
Some
of the
other components of H.323 include:
•
Specifying
messages for
call
control
including
signaling,
registration
and
admissions, and packetization/ synchronization of media streams.
•
Specifying messages for opening and closing channels for media streams, and other
commands,
requests and indications.
•
H.261 (video codecs)
•
H.263
—
Specifies a
new video codec 22
for video
over
POTS
(< 64Kbps).
G.722, G.728 and G.729 standards
•
G.7 1
•
H.230 Frame Synchronous Control Standards
•
H.245 Link Control Standards
•
T. 1 20
,
1
Data Sharing Standard
2.
Plain
POTS
is
Old Television System (POTS) acronym
the
for Plain
infrastructure of telephone lines
Old Telephone
and was designed
Service.
to address the
It
utilizes the existing
need for an inexpensive,
high-quality solution for video conferencing over the existing infrastructure.
standard
addresses
connections.
data,
high
Specifically
quality
it
telephone
common method
to the
POTS
connections over a single
has been the least attractive of the
Even though
less of
the actual
POTS
medium
an obstacle, since today's
processors have
modem
POTS
common
hasn't
grown much,
rate video
make
are
now performed
15 frames per second (under optimal
conditions), full duplex video and audio, with real-time responsiveness.
23
is still
and voice over a single
become more capable, codec functions
are:
it
technology and data compression
low frame
primarily in software, often achieving full-color,
components of H.324
options
currently has a broad impact on the current
bandwidth of
technically feasible to transmit both very
As
for sharing video,
bandwidth constraints. However, because H.324 incorporates the most
marketplace.
becoming
modem
POTS modem
line.
global communications facility today,
line.
compression over
audio
addresses and specifies a
Video conferencing over
it
and
and voice simultaneously using high-speed (V.34)
POTS
due
video
The H.324
Some
of the major
~
than 64 Kbps.
•
H.263
•
H.261 - Video Compression from 64
•
H.223
~
Defines a Multiplexing protocol for low
•
H.245
~
Defines control of communications between multimedia terminals.
•
G.723
~
Defines speech coding for multimedia telecommunications transmitting
Defines speech coding
at 5.3/6.3
at rates less
to
2Mbps bit rate
multimedia terminals.
Kbps.
VIDEO COMPRESSION
F.
In the past,
due
to the
method
traditional
and
technical
improvements
reliable
videoconferencing
can
bandwidth constraints of
in
also
terrestrial
mediums,
for transporting videoconferencing
routing
be
and
realized
switching,
with
however,
satellite
between
users.
optimal
the
Due
to
high-quality
circuit-switched
dedicated
was
channels.
Unfortunately, due the high cost and lack of widespread availability of these channels, most
desktop computer users do not have access to a dedicated videoconferencing link that can transfer data at the necessarily data rates.
average computer user has access to
is
The chief
the Internet,
digital transportation
which
is
medium
based upon a non-guaranteed
bandwidth, packet-switching technology often connected to an end user via POTS.
more capable
routers,
switches
and modems are used
that the
to
deliver
Even
as
videoconferencing,
providing coherent end-to-end video and audio streams across the Internet remains a major obstacle, due to lack of guaranteed bandwidth.
due
to
Internet
Video and audio quality can be very poor
congestion, routing delay, packet
loss/retransmission,
rerouting, limited multicasting capabilities, and other factors.
24
packet constant
One way
improve bandwidth
to
is
to the
compress the data prior to
traversing a
its
network. This can generally be accomplished using two types of data compression schemes: lossless
Lossless compression schemes are generally used in algorithms like,
and "lossy."
zip, gzip
and gif
file types.
When
using these types of algorithms, no data
is lost
during the
The
compression and subsequent decompression of the data with approximations. compression algorithms search for and replace redundant inability of the
human eye
lossy
Fortunately, due to the
data.
to discern small losses of data in a digital
image (notably the
that small color details aren't perceived as well as small details of light
fact
and dark) lossy
compression techniques are very suitable for videoconferencing. There
a
are
number
of
H.261
is
and
videoconferencing,
videoconferencing products.
H.261
prevalent.
less
bandwidth
is
compression
techniques
one
most
of
the
available
widely
MPEG1,
Motion JPEG, Indeo,
used
and
in
use
for
in
commercial
MPEG2
optimized for bandwidth efficiency and low delay, whereas
are
also
MPEG
is
MPEG is editable and provides the high visual quality required by
efficient.
movie-type applications. Indeo compression, offered by
Intel, is
optimized for low decode
processing requirements. In order provide an appreciation of video compression algorithms, an overview
H.261
same
will
Audio compression
be given.
will not be discussed in detail since
basic principles used for video compression.
A
good reference
it
uses the
for their details
is
[Rettinger, 95].
The H.261
is
videoconferencing that
networks as
a
is
widely
used
international
video
compression
standard
for
designed for applications which use synchronous circuit switched
their transmission channels, e.g.
ISDN.
25
It
was approved by
the International
Telecommunication Union (ITU), (formerly CCITT) conjunction with H.320, H.323 and H.324. pertains to
is
currently used in
is
an interoperability standard that
communication between encoders/decoders (codecs) used by videoconferencing often called Px64, where
systems.
It
64Kbps.
H.261
MPEG.
Although similar to
still
H.261
1990, and
in
pictures,
is
is
P
(1-30) represents multiples of frames sent
similar to other "lossy" compression standards like
whereas
MPEG
MJPEG
and
MPEG, JPEG
is
and
a compression standard used for
Motion JPEG (MJPEG)
and H.261 deal with motion video.
generally uses H.261 techniques, such as Discrete Cosine Transform quantization, macroblocks, etc.
MJPEG
JPEG,
at
(DCT) encoding,
Using "lossy" compression algorithms, H.261 has provided
a major advantage in dealing with the bandwidth constraints of various transmission media,
without losing any significant picture quality (as least as far as the
Although both
MPEG
and H.261 handle motion pictures,
human eye
MPEG
is
is
concerned).
designed to handle
compressed bitstreams for the moving picture components of audio/visual services
Mbps.
H.261, designed to target videoconferencing applications where
from 0.9
to 1.5
motion
naturally limited, is specified
is
Due
the
at rates
from 64 Kbps
computation-intensive
to
algorithm
approximately 2 Mbps.
used
codecs,
the
early
videoconferencing systems they were implemented in a separate piece of hardware.
With
today's
to
more powerful processors, however,
the
in
in
computations can be done by the
computer's onboard processor.
H.261 uses Discrete Cosine Transform (DCT), to take advantage of the intraframe spatial
and interframe temporal redundancy found
track of the similarities in information in the
same
in picture data.
picture frame.
Spatial
redundancy keeps
relies
on a small number
It
of bits to describe areas (pixels) on a picture that are the same color, therefore eliminating
26
the need to code each pixel for every transmission of data across the channel.
Temporal
redundancy, using motion compensation, takes advantage of similarities of information
between adjacent frames
in a
changed from one frame
group of moving pictures, therefore only pixels that have
to the next are transmitted.
In
summary,
DCT
gets rid of
redundant data bits in each block of picture frame data.
H.261 also takes advantage of limitations standard for transmitting moving pictures
discern
movement up
to about
-25 frames per second
is
is
in the
human
eye.
Even though NTSC's
30 frames per second, the human eye can only
24 frames per second.
Actually, for the
human eye even
15
considered smooth motion.
Using "lossy" compression algorithms
in
H.261 has provided a major advantage
in
dealing with the bandwidth constraints of various transmission mediums, without losing any significant picture quality.
27
H.261 Structure
1.
Figure 3-1 depicts a flow diagram of a typical H.261 standards based system encoder.
Ktw tamryTnacrgblock in
mi image:
IrjtTrK:
y
Cb reference
*-
Cr
ra ^ % &
48
».
'-V
>.,,
64.
-besi
match
DCT + Quan
+ RLE-
motion vector-
Hullman coder \
0100110
Figure 3-5 P-coding (interframe)
Figure 3-6 shows
how
each macroblock
is
[Jin, 96]
intra-frame encoded.
used as an accessing point. Figure 3-7 shows the frame sequencing used
33
The intra-frame in
H.261.
is
.
Cr For each
*
macroblock
Cb
DCT
for each
.Quant,
O-^CMIh
SxS block
,
.
Zig-zag
Huffman
I
RLE
01101...
I Figure 3-6 I-coding (intraframe) [Jin,96]
-r-r
p
I*
i
xxxxLocitx
XXXXXxfl^BHlxXK
.
jxicxxxxxi
.
xxxxxic^^^Bxxx
•.
:
.
.
k
jc
x x it
^R^^HK * **
.
!
:x::x:«::x:
r sPTrPP 1
T
f
'
1 '
Figure 3-7 H.261 frame sequence encoding |Jin,96]
After quantization,
to be equal to zero.
this.
it
is
not unusual for more than half of all of the
One coding scheme,
In run length coding, except for the
coefficients are
run-length coding,
DC
coefficients
encoded using the run- length algorithm
is
DCT
coefficients
used to take advantage of
of the intra-coded blocks, in
a ziz-zag fashion, as
all
DCT
shown
in
Figure 3-8. For each non-zero value, the number of zeros that preceded the number and the
amplitude of the number
itself
form a
pair.
If the last
34
nonzero value does not happen to be
the last coefficient in the block, an End-of-Block code there are no
more nonzero
coefficients
In cream Tig ver1.ic«tl
frequency
attached to
tell
the decoder that
the 8 x 8 block.
left in
It
is
creasing
fiorizxrnl.al
IWjquency
P
Figure 3-8 Run-Length Encoding [Jin,96]
The coded its
own code
shorter code
pair will then
go through a variable length encoding where each pair has
word, assigned through a variable length code. The basic idea
words
to represent
to assign
more frequently occurring values and longer code words
the less frequent values, in order to compress data even further.
common. Many Huffman
is
tables used for different types
Huffman coding
of data are specified
is
to
the most
in the
H.261
standard.
H.261 are
many
is
faster
only the baseline video compression standard for videoconferencing. There
and more
efficient codecs,
which
proprietary algorithms. Nevertheless, even a
tremendous compression
ratios (well
are
H.261 compliant,
that use their
minimum H.261 compliant codec can
beyond
100:1).
The
table in Figure 3-9
own
provide
shows how
well data rates can be increased with a 100:1 data compression using H.261 compression
standard.
35
BIT
RATES REQUIRED TO TRANSMIT COMPRESSED VIDEO AND QCIF FORMAT
IN
CIF
300000 250000
200000 0)
"
Bit Rate CIF
150000
Bit
Rate QCIF
100000
50000
Frames per second
Figure 3-9 Frame Rate
Rate for compressed data
MPEG
5.
Many used in the
vs. Bit
of the compression techniques used in the H.261 standard are similar to those
MPEG-1,
frame ordering
but there are three major differences: data structure, coding type, and
[Zin,
96].
Because
MPEG
is
targeted
for
more bandwidth-intensive
applications than H.261, this thesis will not provide and in-depth description of
MPEG
standards.
G
AUDIO COMPRESSION Audio compression standards are the most important function of videoconferencing
systems, across
all
generations.
Currently,
Mu-law and A-law
compression techniques used to condense audio data utilized
36
in
are the
most
common
videoconferencing systems.
Both are non-uniform pulse code modulation (PCM) encoding techniques
that use the
quantized values of the samples in order present a discrete representation of the audio signal.
Each sample represents a code word
that
is
8 bits in length.
transformations allow 8 bits per sample to represent the
achieved with 14 bits per sample using uniform ratio
of approximately 1.75:1.
Due
Mu-law and A-law
same range of values
PCM, which
that
translates to a
would be
compression
to the logarithmic nature of the transformation, the
low
amplitude samples are encoded with greater accuracy than the higher samples.
Major techniques
that are
designed for audio signals:
48 - 64 Kbps Narrow-band
•
G.7 1
•
G.722
•
G.723 - Speech coding
•
1 -
G.728
-
48 - 64 Kbps Wide-band
-
16
at 5.3/6.4
Kbps
Kbps Narrow-band
ITU-T recommendation G.7 11, "Pulse code modulation of voice frequencies" provides telephone quality audio (narrow-band 3khz).
G.722 provides stereo quality (wide-band 7khz). usually
> 256 Kbps,
it
values of adjacent samples.
actual sample and encodes the difference.
It
(ADPCM), which
compared with Mu-law or A-law
56, and
48 Kbps.
If
G.722 uses
uses predictive algorithms to
uses the difference between the predicted and
The adaptive
adapt to changing quantizing or prediction parameters. 2:1 as
typically higher data rate,
provides the best audio quality available. [VTE, 95]
adaptive differential pulse code modulation
predict the
At a
1.75:1.
part is because the encoders can also
ADPCM generally achieves ratios of
G.722 has three modes of operation: 64,
a 64 Kbps communication channel id used, 48 or 56 Kbps modes will
have an additional 8 or 16 Kbps of bandwidth for other
37
data.
over
For audio
compressed 3.4khz
POTS
narrow-band
signal. If defines speech
G.723,
which
coding for audio transmitted
G.728 provides narrow-band audio, which Kbps.
there's
lines,
is
supports
at 5.3/6.4
important for lower
a
Kbps.
bit rates
< 256
designed specifically for speech signals. G.728 uses another type of predictive
It is
coding called code excited linear prediction (CELP), which requires a bandwidth of 16 Kbps
and
is
very computationally complex, requiring special hardware.
As
described in H.320,
less capable
call
H.
if
two
different classes of audio compression are used, the
of the two will be used. For example,
with a Class
1
system, the audio will be G.71
1.
if
a Class 3 system (G.728) establishes a
[VTEL, 95]
DATA STANDARDS The T.120 standard focuses on
applications sharing during any
collaborative computing,
H.32x videoconference.
It
common
whiteboard, and
defines the communication and
application protocols and services that support real-time multipoint data communications.
The
specification also allows data-only
required.
In addition,
transmission media.
T.120 sessions, when no video communications are
T.120 supports multipoint meetings with participants using different
T. 120 recommendations include:
Communication Service
•
T. 122 Multipoint
•
T. 123
•
T. 1 24 Generic Conference Control
•
T. 126 Still
Network Specific Transport Protocols
Image Exchange
38
I.
SUMMARY As network
architectures have evolved,
implemented. But in order
to
newer standards are continually
provide cross-platform capability, flexibility, scalability, and
accommodation of newer technologies
as they emerge, the protocols
and standards used
in
videoconferencing for distance learning must be compatible with the standards from the International
Standards
bodies.
These
standards
should
be
the
baseline
used
in
videoconferencing systems for distance learning.
Using commonly available software codecs, not only will network bandwidth
improve over already strained data pipes, but the allows for storing more data storage device(s).
in a
PC's
This provides the ability for more course material to be streamed-on-
demand, providing the asynchronous capability necessary for distance learning
to sea.
Although software video codecs lack the compression speed of dedicated codecs, they have the advantage of low cost.
Pentium
II
with
Furthermore, more powerful processors like Intel's
MMX technology improve video compression/decompression.
39
40
IP MULTICASTING AND
IV.
A.
THE MBone
INTRODUCTION This chapter focuses upon multicasting videoconferencing sessions over IP-based
networks.
It
must be noted however
network segments, including
(SMDS),
satellite,
frame
The IP Multicast
multi-vendor cooperative Multicast technology,
effort
many
to
relay,
It
can be used over a variety of
switched multimegabit data service
ISDN. This chapter
Initiative (IPMI).
also discusses the major
Founded
in 1996, the
IPMI
is
a
promote the deployment of industry-standard IP
of which are
IETF Requests
for
are leaders in the high technology industry including
Systems, Silicon Graphics, and
B,
ATM,
dial-up asynchronous, and
protocols supported by
members
that IP is very flexible.
GTE, among
Comment
IBM,
Intel,
(RFC).
Many
Microsoft, Cisco
others.
BACKGROUND As shown
in
Chapter
II,
videoconferencing compression algorithms help reduce
network bandwidth requirements, allowing videoconference applications time, quality video and audio data across networks.
of the bandwidth issue.
send data
For example, what
to multiple hosts
if
a videoconferencing application needed to
retransmit identical IP packets to each recipient.
potentially strain the network.
To avoid
But compression solves only one area
One way
simultaneously?
this
to deliver real-
to
accomplish that task would be
If there are
many
to
recipients, this could
problem, the Internet Engineering Task Force
(IETF), an arm of the Internet Architecture Board (LAB) that approves Internet standards,
41
endorsed IP multicast as a standards-based solution to that
make
multicasting practical on the Internet.
the Internet
They
backbone connections, and the widespread
wide global network
infrastructure [Macedonia,
this
problem.
There are two items
are the lack unlimited bandwidth
on
availability of workstations across a
Brutzman
94].
IP MULTICASTING
C.
RFC
1112, "Host Extensions for IP multicasting," authored by Steve Deering in
1989, was designed as an extension of IP Version
an IP datagram to a "host group",
i.e.
many
It is
described as "the transmission of
a set of zero or more hosts identified by a single IP
IP multicast allows applications to send data over the
destination address [Johnson, 97].
Internet to
4.
simultaneous recipients in a more economical fashion than unicast or
broadcast IP transmissions.
Unicast IP
is
from a
single source to a single destination (one-
to-one), so in order to send information to multiple recipients using unicast, an application
needs to send multiple copies of IP datagrams, which might saturate the transmission
medium. Broadcast IP sends data
to all of the participants in a
network whether they want
it
or not.
When
Internet Protocol (IP)
facilitate multicasting.
Class for
D addresses
groups
was developed, Class
D DP addressing was designed to
Unlike unicast IP addresses, which identify specific destinations,
identify a particular transmission session. Class
rather
than
individual
D addresses
are reserved
The addresses range from 224.0.0.0
hosts.
239.255.255.255.
42
to
There are also certain special addresses •
224.0.0.
1,
connected
the "all host group"
224.0.0.2 addresses
•
224.0.0.0 through 224.0.0.225
all
all
1700 - "Assigned Numbers"):
multicast hosts on a directly
is
the
reserved for routing protocols and other low-
maintenance protocols.
224.0. 1 .3 through 224.0. 1 3.255
multicast,
LAN.
routers in a
level topology discovery or
With IP
addresses
RFC
net.
•
•
—
(listed in
source
is
reserved for
application
is
Network News.
not
aware of the
necessarily
Multicast applications send one copy of an IP packet over the network to a
destinations.
group address. session group.
A group of receivers may then participate by joining the particular multicast The
multicast IP datagram
host group (group Class
D
address) with the
is
delivered to
same
all
members of
its
destination
'best effort' reliability as regular unicast
IP datagrams [Johnson, 97].
Some •
of the rudimentary requirements of IP multicast are:
Since hosts
may
leave or join a group at anytime,
membership
in
a host group of
an IP multicast session must be dynamic. •
There should be no restrictions on the location and number of groups that can participate.
At the application level, a host may have multiple data streams on different port numbers, on different sockets, in one or more applications [Johnson, 97].
The minimal hardware/software requirements needed end
are:
43
to deliver IP multicasts end-to-
Support for IP multicast transmission and reception in the host's TCP/IP protocol stack and operating system.
Software supporting Internet Group Management Protocol (IGMP), in order to to join a multicast groups(s), and receive multicast traffic.
communicate requests
Network
interface cards that efficiently filter for
mapped from network
that are
LAN
data link layer addresses
layer IP multicast addresses.
IP multicast application software such as videoconferencing or
file transfer.
The
end-node applications should be flexible in terms of their support for existing compression technologies and accommodation of newer technologies as they emerge. Intermediate routers between the sender(s) and receivers(s) must be IP multicastcapable.
•
Firewalls
(i.e.
IP multicast
Figure 4-1
is
packet-filtering software)
traffic.
may need
to
be reconfigured to permit
[Johnson, 97]
an overview of the requirements.
tiring multicast
Sending, muttit
application
,
/
/
Km
TCMP
protocol stack
protocol stack
/
Network driver
/
,
Network Interface/
Multicast-enabled router
A
Mortkast-enabled server
/
Receiving end-station
iCMP-teterntt control message protocol
K3MP
I
Must be niutocast-enaWed
UDP-
internet group
Universal
management
protocol
datagram protocol
Figure 4-1 Requirements for IP Multicasting
1
2
Windows NT, Windows
95, and the latest versions of
Multicasting capability can be enabled
in
UNIX
support IP multicast.
most routers by simply updating the software and adding memory.
44
When
a host application requests membership in the host group associated with a
particular multicast session, the request
and,
if
is
communicated
to the subnet's multicast router
necessary, on to intermediate routers between the sender and receiver.
requested session
is
found,
the
router delivers
datagrams to the requesting host, passing
it
available as input to the user's application.
hardware
the
to the
When
the
requested incoming multicast IP
TCP/IP
Other stations
stack,
filter
which makes the data
out multicast packets
at the
level.
Multicast routers do not need to
know
the
only requires knowing a group for which there
is
list
of
member
hosts for each group.
A
one member on the subnet.
It
multicast
router attached to an Ethernet need associate only a single Ethernet multicast address with
each host group having a local member.
1.
IP Multicast Protocols
Like any other means of transporting data over network infrastructures, IP multicast
comes with an array of protocols
that help provide the
framework
for multicasting IP
datagrams. The most fundamental of IP multicast protocols, Internet Group Protocol
(IGMP
Ver.
2),
described in
RFC
2236,
learn the existence of host group memberships.
is
Management
used by multicast routers in order to
It is
the baseline protocol necessary to
conduct an IP multicast session.
The protocols used
to ensure that the
needed bandwidth and
QoS
are available
include Real-Time Transport Protocol (RTP), Real -Time Control Protocol (RTCP), Real-
Time Streaming Protocol (RTSP), and Resource Reservation
Protocol (RSVP).
There area
also associated routing protocols such as Protocol Independent Multicast (PIM), Multicast
45
Open
Shortest Path First
(MOSPF), and Distance Vector Multicast Routing Protocol
(DVMRP). There are also transport issues
that
need to be addressed with IP multicast.
Applications that are IP multicast capable are not designed for use with reliable, connectionoriented transports (TCP), therefore layer 3 does not invoke destination addresses in the
datagrams.
They
also
do not require guaranteed in-sequence delivery of IP packets.
Furthermore, since the delivery of IP will not have a fixed path, there
bandwidth needed for video
the
and
audio
will
be
available.
is
no assurance
that
Videoconferencing
applications are better off tolerating missing data than overcoming the lengthy delays caused
by
TCP
retransmissions.
Therefore, a simpler transport framework, such as User Datagram
Protocol (UDP), a transport layer protocol that only provides error detection, does a more
than an adequate job of transporting videoconferencing data.
Internet
a.
Internet
It
is
Group Management Protocol (IGMP)
Group Management Protocol (IGMP) performs two main
functions.
used by hosts to join IP multicast sessions, and by multicast routers to learn the
existence of host group
multicast routers in a
analogous
to
members on
LAN, and
Internet
their directly attached subnets, identify designated
propagate group information over the Internet.
Message Protocol (ICMP), which
Control
is
It is
used
loosely
in
PING
applications. [Johnson, 97]
Each multicast router sends the hosts respond
by reporting
their host
This query and response session
datagram packets. To determine
is
if
IGMP queries
(Host Membership Query), and
group memberships (Host Membership Report).
accomplished by
any hosts on a
46
IGMP
messages encapsulated
in IP
local subnet belongs to multicast group,
one multicast router per subgroup periodically sends a hardware (data link
IGMP
Host Membership Query (network address 224.0.0.1) to
subnet.
all
layer) multicast
IP end nodes on
its
This message asks them to report back on the host group memberships of their
processes. These query messages have a time to live (TTL) of
1
to limit their transmission to
the network directly attached to the router. [Petitt, 96]
Each host then sends back one address, so that
all
group members see
the group transmitted, they cancel their
group
will report
membership
local multicast routers will send
it.
IGMP
When
own
Host Membership Report to the group
hosts see a Host
transmission.
Membership Report
Hence, only one member of the
to the router for a particular
group address.
Periodically,
IGMP Host Membership Queries to the "all hosts"
verify current memberships. Although
the multicast application's traffic,
its
IGMP
for
group, to
packets are routinely transmitted, compared to
bandwidth use
is
insignificant.
Figure 4-2 shows an
IGMP request on a LAN.
IGMP Messages within a
LAN
[
Host
[
Memb er ship Rep ort
for multicast
Host Membership Report
Host Membership Report)
group
adddress(es)
^
Figure 4-2
IGMP Messages on a LAN
47
[Johnson, 97]
]
When
the last station
on a subnet leaves a multicast group,
"prunes" the multicast data stream associated with
it
by ceasing
the router
to forward the data stream
to subnet.
Real-Time Transport Protocol Version 2 (RTP)
b,
Real-Time Transport Protocol (RTP), defined end-to-end
provides
delivery
Among
data.[Johnson,97]
services
support
to
the services that
RTP
applications
RTP protocols.
It is
does not provide
all
is
transmitting
real-time
provide are payload type identification,
packet sequence numbering, and time stamping. The delivery of
by Real-Time Control Protocol (RTCP), which
RFC's 1889 and 1890,
in
discussed
RTP
packets
is
monitored
later.
of the typical functionality of typical transport
a header format running in combination with other transport protocols in
order to take advantage of their functionalities.
The RTP header provides timing
information to synchronize and display audio and video data, and also to determine packets are lost or arrive out of order.
In order to allow multiple data and compression
types, the header specifies the payload type
encoding
is
carried in the
RTP
packet.
by characterizing what type of audio and video
This enables users to have the option to change the
encoding methods during a conferencing session,
in
response to network congestion, or to
accommodate low-bandwidth requirements of a new conference
RTP
does not ensure timely delivery or provide
guarantee delivery or prevent out-of order delivery, nor does
network
is
guarantees,
reliable.
RTP
For applications
if
like
participant [Johnson, 97].
QoS
it
guarantees.
assume
that the
It
does not
underlying
videoconferencing that require these types of
must be accompanied by other mechanisms [Johnson,
48
97].
works
in
c.
Real-Time Control Protocol (RTCP)
RTCP,
also standardized in
conjunction
participant in an
RTP
The information,
with RTP.
session to
all
RFC's 1889 and 1890,
other participants,
is
periodically
is
a control protocol that transmitted
by each
used by the applications to control
the performance of the conference and for diagnostic purposes.
RTCP
performs four primary functions,
a) First,
RTCP
information about the quality of the transmission to the applications. the
number of packets
identifies the
RTP
sent, the
source address through
name (CNAME). The
traffic
its
up
to a large
statistics
lost, interval jitter, etc.
b)
include
RTCP
c)
RTCP
controls
its
transmission intervals in order to
from overwhelming network resources.
number of
session participants,
convey a small amount of information
RTCP
d)
An
control traffic
RTCP
allows
RTP
RTCP
is
to
optional function can be used to
to all session participants.
In distance learning, this
information can be used to identify the participants in a particular training session.
example,
also
transport-level identifier called the canonical
limited to five percent of the overall session traffic. This control on
scale
The
CNAME is used to keep track of participants in a session in order to
synchronize audio and video. prevent control
number of packets
provides feedback
For
might carry a personal name to identify a participant on the user's display.
[Johnson, 97]
Since
RTCP
sends feedback to
individual users can determine
RTP
and
RSVP
information
is
if
a problem
is
all
of the recipients of a multicast stream,
specific to the local
end node or system-wide.
simply data from the point of view of the routers that
the packets to their destinations.
To
prioritize data streams
of service, other protocols must be used [Steinke, 96].
49
move
and provide a guaranteed quality
Resource Reservation Protocol (RSVP)
d.
In an Internet environment with a
queuing can lead
myriad of routers and switches, packet
to variable packet delivery delays in different parts of the
considerations for a multicast application include tolerance to
In order for the
network
to provide
jitter,
QoS
delay, and lost packets.
QoS, applications must be able
network services [Johnson, 97]. This
network.
to reserve
and control
not an issue on networks with sufficient bandwidth,
is
but considering the packet-based networks targeted for use in this thesis,
QoS
is
a major
issue.
The Resource Reservation Protocol (RSVP) reservation,
still
under development [Hurwitz, 97].
dynamic request specifications
It
aims
a draft protocol for resource
Elementary
for end-to-end desired
packets to receive the QoS.
is
QoS and
large
multicast
delivery
reservations can be supported
multicast, a host sends an
message request
RSVP
groups.
by reallocating
IGMP
is
definitions of the set of data
useful
in
(rather than
and
is
expected to scale well
environments where adding) resources.
QoS In
IP
message to join the group and then sends an
RSVP
RSVP
service
to reserve resources along the delivery path(s) of that group.
is initially
requests consist of
up a guaranteed QoS resource
to efficiently set
reservation, supporting unicast and multicast routing protocols,
for
RSVP
sent to a local server.
The
The
local server will validate the request
and then
forward the request.
RSVP
promises access to Internet integrated services.
The
hosts and the
network work together to achieve guaranteed quality of end-to-end transmission. However, in order to achieve
end-to-end QoS,
all
hosts, routers
elements between the receiver and sender must support
50
and other network infrastructure
RSVP. They must
reserve system
resources such as bandwidth,
RSVP
rides
on top of
IP,
CPU
and
is
and memory buffers
in order to satisfy
used by routers to deliver
along the path(s) and to establish and maintain
QoS
statistics in
reservations.
control requests to
all
nodes
order to provide the requested
services.
After the reservation has been made, the router supporting
route and
QoS
class for
QoS
RSVP
determines the
each incoming packet and the scheduler makes forwarding decisions
for every outgoing packet [Johnson, 97].
Since
RSVP
is
receiver initiated, resource requests are in only one direction.
At each node along the reverse path reservation for the requested stream.
messages only up reservation for the
to the receiver,
attempts to
make
a resource
This receiver-initiated propagation delivers control
node of the spanning
to the
RSVP
tree
where they merge with another
same source stream, thus preserving bandwidth. This receiver
initiation
achieves two goals: scalability, because the receiver-initiated joining delivers control
messages only along those
parts of the tree that
need the information; and heterogeneity,
because of the receiver orientation, individual receivers can choose to participate and request different levels of reservation. [Precept, 97]
Based upon the admission and policy controls of the underlying hardware,
at
each node, one of two general actions take place: The host makes a reservation or forwards the request upstream.
equipment.
These controls are not a part of RSVP, but are utilized by the
Admission controls determine whether the node has
sufficient resources,
the policy control determines whether the user has authorization to
the reservation
is rejected,
accepted, the node
is
RSVP
returns an error
message
reservation.
If
to the appropriate receiver(s).
If
configured to provide the desired QoS.
51
make a
and
If the
RSVP
request
is
forwarded upstream,
it
continues to propagate along the reverse path towards the appropriate
senders. [Johnson, 97]
One drawback
of
RSVP
is
the computational requirements required
routers to inspect and handle packets in a priority order.
Approaches such as tag switching
are being developed to help with this drawback.
Another area of research
RSVP
and fixed paths. Finally,
way
to use routing services that provide alternate
to handle
bandwidth
network overload
at the
same time [Andrews,
RSVP (IETF), and
is
that
may
occur
if
is
enhancing
RSVP
multiple users request the
has no
maximum
97].
continues to be under review by the Internet Engineering Task Force
not widely deployed.
Similar
work has been done on
Version 6 (IPv6) to support resource reservation and flow is
by
an illustration of the method.
52
set
Internet
Protocol-
up for multicasting. Figure 4-3
Multicast
Application
RTP|RSVP
Source
RSVP reservation -
- RTP (RTCP
control info is
bidirectional)
Receiver
Group
Group
Member
Group Member)
(Multicast
Member
RSVP Protocol
Figure 4-3
RTPIRSVP Application
[Johnson, 97]
e,
Real-Time Streaming Protocol (RTSP)
RTSP
is
considered more of a framework than a protocol.
It
works
at the
application level for unicast and multicast streaming and to enable operability between
different vendors' clients
and
stream control commands. functionality of a
2.
In
servers.
many
RTSP respects,
essentially encodes and passes multimedia
it
resembles a protocol that describes the
VCR remote control.
Reliable IP Multicast
Reliable connectivity ensures that
all
packets are received by
For unicast IP services, error correction and detection
is
provided
all
of the recipients.
at the
TCP
layer.
But
such traditional techniques for error detection and correction in a large-scale multicast
environment might
result in
an
"ACK
explosion" or a
53
"NAK"
implosion, where the
excessively large numbers of acknowledgement messages from large groups can
swamp
the
originating hosts sending the desired streams.
There are currently no IETF standards for drafts
have been submitted related
reliable IP multicast, but several Internet
to reliable multicasting,
Task Force) working group has been formed
to
and an IRTF
(Internet Research
advance reliable multicast standards efforts
[Johnson, 97]. Cisco's proposed Pretty
intended to
still
make
Good
Multicasting
(PGM)
Reliable Transport Protocol
is
work
is
multicasting appropriate for mission-critical uses.
under development,
this protocol
Although
can be useful in areas such as
this
common
tactical
pictures.
As mentioned data and
still
previously, videoconferencing applications are able to tolerate missing
provide discernable video and audio. They also do not require guaranteed in-
sequence delivery of IP packets.
Therefore, videoconferencing end-systems will not need
acknowledged
bit-perfect, in-order,
more
data.
essential with the
For military purposes, the multicast
common
reliability
and cooperative
requirement
is
engagement
issues. (Petitt, 96) evaluates the design choices of several reliable transport
tactical
architecture
layer multicast protocols that support those requirements.
3.
Group Setup
Protocols
Users of videoconferencing must not only multicast sessions, but also
how
to
media types
or current IP
manage and coordinate them. Parameters
will include information such as the
date, time and duration;
know about upcoming
name and (e.g. audio),
54
topic of the session;
its
for sessions
multicast address;
media encoding, and media
ports; security
parameters;
etc.
There are currently several Internet drafts for these types of protocols, but
a clear standard has not emerged.
session directory tool, sdr,
is
Still
there are current tools available. For example, the
widely used on the MBone.
Program Guide has a directory embedded
in a
Similarly, Precept's
IP/TV
Web page.
Other IP Multicast Issues
4.
a.
Router Support
As with
routing any IP datagram, multicasting requires routers to interact
with each other and exchange information about their neighbors.
One item
considered, in order to most effectively implement IP multicast,
to determine
best possible routing protocol based
upon the network
layout.
is
On
that should
be
what
the
is
a routed network, which
includes native multicast, IP multicast traffic for a particular source and destination group typically transmitted via a spanning tree that connects all of the hosts in the group.
are basically
two approaches
Dense-Mode that the multicast
bandwidth
is
to multicast routing;
There
Dense-Mode or Sparse-Mode.
multicast routing protocols follow an approach that assumes
group members are densely distributed throughout the network and
abundant.
These protocols rely on periodic flooding of the network with
multicast traffic to distribute group
membership information
order to set up and maintain the spanning Shortest Path First
is
(MOSPF), described
Dense Mode (PIM-DM), and
the
tree.
in
earlier
RFC
to
all
nodes in the network in
The protocols include Multicast Open 1584, Protocol-Independent Multicast-
Distance-Vector Multicast Routing Protocol
55
(DVMRP), becoming
described in
RFC
DVMRP
1075.
currently used
is
on the MBone, but
obsolete.
Sparse-Mode protocols
are based
upon the assumption
that the multicast
group members are sparsely distributed throughout the network and bandwidth Flooding in
necessarily widely available.
bandwidth and latency problems regions.
that
They build a
sent
this case is not
single distribution tree,
and rendezvous point
in
tree,
like
Core Based Trees (CBT),
Mode (PIM-SM), RFC
which
2189, and
2117, are possible choices.
traffic for the entire
regardless of the source.
is that
RFC
formed around a focal router (called a core
is
provide significant bandwidth savings for applications that have
Another concern
not
economical because the waste of
PIM-Sparse Mode). Multicast
and received over the same
is
occur when transmitting IP over large geographic
Sparse-Mode routing protocols
Protocol-Independent Multicast-Sparse
CBT
is
many
The use of
many
(IDMR).
group
is
a shared tree can
active senders.
Internet Service Providers (ISP's)
a protocol to deal with inter-domain multicast routing
in
IDMRs
do not have
such as Protocol
Independent Multicast (PIM), Multicast Open Shortest Path First (MOSPF), and Distance
Vector Multicast Routing Protocol
(DVMRP), were
systems that do not necessarily want to share
all their
not designed for multiple autonomous routing information. [Hurwicz, 97]
Although Border Gateway Protocol (BGP) provides inter-domain routing capabilities for IP, there
IGMP
working group
specification.
is
is
no equivalent of
BGP
for DP Multicast.
developing a Border Gateway Multicast Protocol
Until this shortcoming
is
addressed, the lack of an
the scalability of IP Multicast, along with limited bandwidth,
why MBone
Currently the IETF's
is
IDMR
(BGMP)
protocol
protocol limits to
one of the major reasons
has only about 30,000 users. Furthermore, growth will continue to be limited
56
if
—
all
of the routers will have to contain
all
of the routing information for the whole network
[Hurwicz, 97].
Although new routers on the Internet are capable of supporting multicast,
most are not IP multicast enabled, by because of concerns such
as:
default.
Many
ISPs are reluctant to deploy multicast
cost and complexity of upgrading older routers, router
resources consumed, reliability problems, an unclear business model (how does an ISP
charge for
traffic,
who
pays, and
how does
peering
—communications
between ISPs
work?), and lack of diagnostic/simulation/debugging tools. Even with these concerns, some ISP's have already deployed multicast.
value-added service on
(POP) with multicast
its
network.
It
For example,
UUNET
has equipped each of
its
offers IP multicast as a
domestic Point-of-Presence
routers, in order to provide multicast service connections throughout
the continental United States.
By
next year, expect more ISPs to begin implementing
multicasting, especially as backbone traffic continues to rise and cost threshold of user
decreases.
There routing protocols.
is
also the issue of incorporating
QoS
routing with various multicast
Native IP multicast protocols uses various approaches to construct
delivery trees for efficient transmission.
But without additional mechanisms, those routing
approaches are not guaranteed to provide a specified QoS.
mechanisms
are
For example, when QoS
used to reserve and control network resources, the routers must not only
satisfy the
added
destination
when
QoS
requirements, but in addition,
constructing a delivery tree.
57
it
has to find the shortest path to a
Other Network Issues
b.
Many many
IP multicast implementations have not been thoroughly tested because
organizations have not enabled multicast capabilities in their networks [Hurwicz, 97].
Furthermore, there
is
no widely known data on how routers will
volume of multicast multimedia
traffic.
react to a steady, high
Because IP Multicast uses the connectionless User
Datagram Protocol (UDP), the most popular type of
firewall, application
gateways, can not
secure connectionless protocols, essentially rendering IP multicast incompatible with most firewall strategies.
TCP
is
In
some
applications, in order to allow transmissions through a firewall,
used in conjunction with
program running on a
host.
UDP, by
Many
tunneling and the ported mulitcast routing
firewall applications
and routers will need
to be
reconfigured, replaced, or upgraded in order to deal with multicast address reliability and
bandwidth
D.
issues.
MULTICAST BACKBONE (MBone) When LANs, WANs,
and the Internet were
initially
developed and designed,
videoconferencing was not expected to be a viable possibility. Based of limited bandwidth,
sending video or audio was not considered possible or practical.
However,
as
the
technology matured, the Multicast Backbone (MBone) and video/audio compression techniques were developed showing that videoconferencing was not only possible but also practical.
The MBone was
is
initiated in early
an experimental, virtual network that
lies
on top of the
Internet.
It
1992 and named by Steve Casner of the University of Southern
California Information Sciences Institute.
It
58
provides one-to-many and many-to-many
network delivery services for multicast capable applications such as videoconferencing.
MBone
originated from a collaboration in order to multicast audio and video from meetings
of the Internet Engineering Task Force, and has been the testbed for protocols mentioned earlier,
such as
developed by hundreds of researchers
IGMP, RTP
who
MBone
to provide
more
are designing
protocols and applications for videoconferencing.
the
MBone
etc.
many of is
the multicast
continually being
effective
and
efficient
This section gives a brief introduction to
an example of the viability of multicasting video and audio over IP-
based network architectures.
1.
MBone Requirements
The major
technical prerequisite that
makes multicasting possible over
the use of network routers called mrouters.
routers, dedicated
UNIX
[Macedonia, Brutzman, 94]. multicast.
MBone
is
Basically mrouters are upgraded commercial
workstation-class machines, or dedicated
machines running with modified kernels
the
in parallel
UNIX
workstation-class
with standard commercial routers
More and more commercial
routers are
now
supporting
This will help eliminate the inefficiencies and management headaches of
duplicate routers and tunnels [Macedonia, Brutzman, 94].
The mrouters use
the
IGMP
protocol to learn the existence of host group membership on their directly attached subnets, to identify designated multicast routers in a
information over the
MBone. Tunneling
datagrams to be forwarded to other at
LAN, and
further
MBone
to propagate
augments
MBone by
group membership allowing multicast
subnets that support IP multicast. For example,
the sending mrouter, IP multicast datagrams are encapsulated
by
unicast IP datagrams and
forwarded as unicast IP datagrams so that intervening unicast routers and subnets can handle
59
them. The receiving mrouters will "strip" the multicast datagram of IP datagram in order to determine
if
any of
its
encapsulated unicast
attached hosts are requesting to join that
its
multicast group.
As mentioned
overarching issue in videoconferencing
earlier, the
is
bandwidth.
multicasting partly addresses this issue by enabling one packet of information to reach
IP
many
destinations. For example, a 128-kilobit per second video stream (based the typical data rate
of two channels of ISDN) uses the same bandwidth whether 20.
However, there
workstation in the
is
one disadvantage.
MBone,
sending streams to
LANs
If all
video streams might potentially misspend valuable bandwidth by that are not participants.
packet propagation are implemented two ways. packets
or
it
received by one location or
mrouters permitted packets to touch every
For that reason, controls are needed to
limit the propagation of video stream packets across the
multicast
it is
MBone
MBone.
limits the time to live
complex pruning algorithms
uses
Controls of multicast
to
adaptively
restrict
MBone
[Macedonia, Brutzman, 94].
transmission of multicast packets.
(ttl)
of the
protocol
developers are successfully experimenting with automatically pruning and grafting subtrees,
and thresholds can setting the
ttl
set
maximum bandwidth
in a packet.
through an mrouter.
The
ttl
For example,
such as a school campus.
If the
on the MBone. Adjusting the to specific regions or areas.
ttl
ttl
is
limits.
The
truncation
is
accomplished by
decremented, by one or more, each time
if ttl
was
was 128,
set to 16,
it
it
it
passes
would multicast on a smaller
scale
could potentially traverse most of the subnets
can assist in limiting the transmission of video stream data
Consequently, effective controls over the
MBone
precious bandwidth that the uncontrolled transmitted packets might otherwise use.
60
can save
make
In order to
coordination
MBone, mailing
a
is
new
list.
the
MBone community
a viable and efficient topology, global
used to minimize congestion on the Internet. site
announces
itself to its Internet
To add
a
new node
Service Provider (ISP) or the
to the
MBone
Then, the nearest network providers decide on the most advantageous path
connection to minimize local or regional Internet
MBone
traffic.
uses various application tools in order for end-users to receive and deliver
The common
videoconferencing.
applications are videoconference tool (vie), visual audio
tool (vat), robust audio tool (rat), shared whiteboard (wb),
and session directory
Vat
(sdr).
is
used for audio teleconferences. Shared whiteboard (wb), using T.120 protocols, can be used as a shared
drawing surface, and
tool dynamically
it
can be used to export and view postscript
files.
The
sdr
announces the availability of sessions by displaying active multicast
groups. Sdr also launches multicast applications and automatically selects unused addresses
for
any new groups.
Sdr makes announcements periodically over a well-known multicast
address and port.
One
of the
first significant
uses of the
MBone came
about
when
NASA Select set up
an in-house cable channel broadcast during space shuttle missions, which then could be
viewed
live
from any
MBone user's desktop computer.
Although many practical applications have been developed on the MBone, continues to be used as a testing ground for IP multicast research and
leveraged for distance learning. Retrieval of Digital Audio
One
thesis, Internetworking:
how
it
can be
Economical Storage and
and Video for Distance Learning, [Tiddy,
96], investigates the
usefulness and feasibility of applying networked storage of digitized video and audio,
the
MBone
it
all
via
for distance learning. Currently there are prototypes that are being used to
61
deliver stored digitized data over the
which can be found
at http://imj.gatech.edu, is
delivery of video-on-demand
VCR
Demand
on
MBone. The
(VoD)
Project,
Interactive Multimedia Jukebox Project,
a research effort to investigate the scalable
The MBone
service using multicast communication.
at
http://www.informatik.uni-mannheim.de/informatik
/pi/projects/MVoD/, offers a solution for the interactive remote recording and playback of multicast videoconferences.
E.
MBone ISSUES IN DISTANCE LEARNING Because
it
was
originally a developmental tool, the
the commercial environment, but
It
it
MBone
has already proved the great benefits of IP multicasting.
has great potential to grow and cover the entire Internet.
service providers have not enabled multicasting in
Among them
combinations of both) service providers
MBone
tools
leery about
is
the direction to take,
don't have an
still
MBone
not easy to set up.
is still
how
is
many network
of their routers for various reasons.
and pricing
issues.
Many
ATM
connection.
Enabling a router for multicasting and installing
video services will impact network bandwidth. Also,
Windows machines.
UNIX
or IP (or
regional network
Many
something not normally done by network administrators.
mainly developed for running on tools to
many
Nevertheless,
the lack of maturity of the technology, not being sure if
is
MBone
has seen limited use in
machines, and there are
still
MBone
62
tools are
problems porting the
Finally, the tools aren't as user friendly as
commercial products.
are
some of
the
The commercial
sector
is
discovering the viability of multicasting and
develop tools that are based upon the
CU-SEEME
and
Precept's
MBone
IP/TV
Companies such
standards.
already
have
is
starting to
as Whitepine's
MBone-compatible
applications.
Videoconferencing applications will continue to mature, and likely the myriad of standards will eventually converge.
This process can be accomplished more easily
if
the
newer
products are based upon thoroughly evaluated tools.
F.
SUMMARY This chapter discusses the major multicasting protocols, technologies and issues that
are pertinent to using videoconferencing as a part of distance learning.
It
describes the
baseline issues that need to be addressed in order to multicast distance learning lectures to
numerous
recipients across an IP-based
videoconferencing over IP networks in
opposed
to dedicated
down. This
network
DoD
to sea.
These proven protocols will make
a practical solution.
One primary
reason
is (as
networks) that multicast groups can be dynamically set up and torn
flexibility is
needed because of the constantly changing location of end-users
such as those receiving distance learning
at sea.
Standards like IP multicasting, and the future implementation of IPv6, will address
some of
the
QoS
issues
by supporting resource reservation and flow
setup.
Also, as older
routers are replaced or upgraded to support multicast, videoconferencing over the Internet
and NIPRnet between groups
at
numerous locations
designed to help improve delivery of data Quality of Service (QoS) issues.
Its
will
become commonplace.
at regular intervals,
which
IPv6
is
will help address
packet headers will help define the types of service
63
(high quality paths in underlying network) that can be used for real-time delivery of audio
and video. This
chapter
has
implementation of multicasting,
widespread emplacement
is
shown
also
it
is
that
based
upon
the
thorough
testing
and
clear that the hurdles currently facing IP multicasting
deployment the rather than the technology.
64
IMPLEMENTING IP MULTICAST ACROSS THE NAVAL NETWORK ARCHITECTURE TO SEA
V.
A.
INTRODUCTION This chapter provides an analysis of numerous options that can be used to leverage
DISN
They
for IP multicast.
will include desktop connectivity,
Sensitive Internet Protocol Router
Defense
Satellite
Network (NIPRnet),
Communications System (DSCS) and/or
satellite
the Unclassified but
entry points (gateways),
C band SHF terminals
(Challenge
Athena), and Automated Digital Networking System (ADNS).
B.
BACKGROUND The
goal of the Defense Information Infrastructure (DII)
is
to establish a seamless,
secure, robust, agile, reliable and cost-effective telecommunications network that will serve
as the end-to-end information transfer infrastructure for
worldwide [DISA,
component of
96].
the DII,
Service
and
SATCOM Defense
DoD personnel
and organizations
The Defense Information Systems Network (DISN) is
Communications Systems
Commercial
all
architecture, a
based upon a global network integrating existing Defense assets,
initiatives,
Military
Satellite
Communications (MILSATCOM),
leased telecommunications services, dedicated
Agency networks,
and
mobile/deployable
networks;
i.e.
DoD the
consolidated worldwide enterprise level telecommunications infrastructure that provides the
end-to-end information transfer component of the DII [DISA, 96].
65
Through the Defense Information Systems Agency (DISA), identifying
what architecture
and
infrastructure that can support voice
and video.
Global (DVS-G), the transport network that collection of dedicated room-based systems
ISDN is
services.
NIPRnet.
One
other segment of
NIPRnet
is
DISN
standards
for
a
is
whose
is
continuously
telecommunications
Video Service -
Currently, the Defense
DISN
DISN
needs
DoD
used for videoconferencing,
terrestrial
that can
components
is
mostly a
are connected
by
be used to support videoconferencing
an IP-based network that consists of the wide-area and local-area
network switching and transmission systems along with customer premises equipment
(CPE)
C.
in order to provide connectivity to
DoD users.
DESKTOP SYSTEMS CONNECTIVITY POTS
1.
Videoconferencing applications conducted on serial
modem
CONUS
connections are straightforward.
(DTS-G),
AT&T provides information
DISN
over Ethernet, token-ring, or
Under the DISN transmission services
transport for the aggregate
bandwidth of
customer Service Delivery Points homed off the Bandwidth Managers located respective access areas.
Figure 5-1
is
a diagram of the
take advantage of the bulk transmission rates,
SONET
for delivery
to
the
AT&T
Bandwidth Managers.
transmission bandwidth interfaces
at
Tl, T3 and
CONUS
all
in their
transmission service.
To
bundles the access transmission into
At the customer access locations,
SONET
are provided.
AT&T
teams with
Local Access Providers as required to accomplish the access area bandwidth requirements.
66
POSTfcAMWSTATK*' VTC""
Figure 5-1
For
POTS
is
DISN
networks with dedicated dial up
However, even with optimal desktop hardware and software,
always a question due to throughput problems associated with
connections and dirty analog
2.
Architecture [DISA, 96]
connectivity, commercial and
connectivity can be used.
performance
DISN
lines,
which can cause
bit errors
and retransmissions.
Asynchronous Digital Subscriber Line (ADSL)
A twisted-pair phone
line has a capacity far
beyond
the narrow 3 -kHz channel used
to carry an analog voice signal. Historically that capacity has not
it
modem
was reserved
to
compensate for signal loss
67
in the line.
been used before, because
A
reemerging technology,
Asynchronous Digital Subscriber Line (ADSL) overcomes provide download data rates up to least ten times
of traditional
8Mbps
modem
this limitation
and promises to
to desktops, while transmission rates will
data rates.
ADSL is
a
modem
ADSL
uses, the distance
central office plays a significant role in an
modem
is
maximum
to the central office, the less
distance
from
ADSL modem
— LEC).
approximately 1.7 miles, whereas 1.5
Computer industry
Mbps
leaders such as
such as Ameritech, Bell Atlantic,
SBC
joined in an alliance to promote
ADSL.
between the
modem
throughput.
The
signal degradation occurs.
8Mbps download
the central office for an
has a 3.4 mile
Compaq,
Intel,
Communications,
ADSL
The
current problems with
3.
Cable
ADSL are its
ADSL
in
their
For example, the data rate
would be
US
West, Sprint and
GTE
have
technology has the potential to further
twisted-pair copper
that currently plagues
many
ADSL truly attractive is that
phone
lines, is already in place.
lack of availability and high equipment costs.
Modems
Cable Internet access stage of rollout.
it,
closer the
Microsoft and phone companies
POTS. Furthermore, what makes
the infrastructure required to support
and the
limit.
enhance desktop videoconferencing by removing the bottleneck users connected via standard
at
technology that requires
terminal devices at each end of the phone line (user to Local Exchange Carrier
Because of the high frequencies
be
Except central
is
a relatively
for the past year,
offices,
new
transport technology that
early
phone companies had been slow implementing
which was a favorable
accessibility of cable Internet access.
is still in its
situation
At the end-point, a cable
for
modem
the
growth and
connects to the
cable television coaxial wiring and also attaches to the end-user's desktop via a standard
68
modems can
Ethernet connection. Cable a 28.8
modem,
medium, making have
to build
modems up
10Mbps).
(i.e.
its
Unlike point-to-point
architecture a
from scratch
good
to take
are shared, they are
theoretically deliver data at
bound
fit
ADSL,
cable
to
350 times
modems
that of
are a shared
Additionally, end users will not
for multicasting.
However, because cable
advantage of multicasting. to run into congestion
up
problems on the wire as users
fill
local cable loops.
Due
to technical limitations,
data via the cable link.
many
cable Internet services do not allow users to send
Hybrid systems,
in
which incoming data comes via the cable
connection, but the outgoing data travels over the
common.
POTS modem
Therefore, this current system works well
videoconferencing data, but
it is
if
connection are the most
the end-user desires to receive
not a good set-up for delivering videoconferencing content
from the desktop.
D.
TERRESTRIAL TRANSMISSION
1.
Routing
Tunneling
a.
When must look
at the
deciding what routing protocol
network design and topologies.
is
most effective over a network, one
While the NIPRnet
multicast enabled, the Cisco System routers used throughout the
configured to support multicast.
An
alternative
selected multicast-enabled routers in the
CONUS 69
method segment.
is
to
(as a
whole)
NIPRnet can be
is
not
easily
form "tunnels" between
Subnet islands can be created,
similar to what
extended
to
is
used
MBone,
a unicast
implement IP multicast across
link
virtual
that
may
cross
several
satellite
Some major
connection to remote (deployed) users.
are using tunneling to
essentially
These tunnels can be
to connect various end-users.
gateways, that have multicast-enabled routers, with access to
in order to provide a
UUNET)
in the
ISPs (such as
their networks.
bridges
terminals
A
tunnel
is
and routers, which
Tunnel endpoints can be either routers supporting native
encapsulate multicast packets.
multicast routing or workstations running the mrouted multicast daemon.
The advantages of tunneling
may be
the best solution
when both
quantity of IP multicast traffic
is
the
limited.
is that it is
quick and easy to implement and
number of customers using IP Additionally, tunneling
is
multicast and the
a cost-effective
way
to
gain the benefits of multicast without adding excessive risks or making mass hardware
changes.
However, there are two major disadvantages.
The
The second
and managing multicast servers or gateways.
first
is
disadvantage
is
setting
up
that tunneling inserts the
process of encapsulating IP Multicast datagrams into unicast IP datagrams, essentially
slowing down the transmission and introducing scaling problems [Hurwicz, 97].
PIM-SM
b.
As mentioned
in
Chapter IV, Sparse-Mode protocols are based upon the
assumption that the multicast group members are sparsely distributed throughout the
network and bandwidth scalable
wide-area,
is
not necessarily widely available.
inter-domain,
infrastructure, such as
NIPRnet.
multicast
PIM-SM
is
routing
in
DVMRP,
by using the unicast
70
addresses the need for a
mechanism
in
a
large
network
available in Cisco System's routers (which
comprise most of the routers used on the NIPRnet). problem, found
It
PIM-SM
solves the routing table
tables for multicasting [Hurwicz, 97], but
there are
still
some drawbacks. Because
unicast routes adjust automatically to equipment or
link failures, if there are specific routes that multicast traffic should or
guarantee that
it
highly likely) data
may be
NASA
addressed this problem on
its
is
portions of the network, and
NASA
MOSPF
Research and Education
network
to the
same groups
Since the hardware usually has a decisive
influence on the choice of multicast routing protocol,
MOSPF
no
not multicast enabled (which
the responsibility for the multicast
were managing the unicast network.
towards
take, there is
lost.
Network (NREN) by moving that
If all routers are
will take that route.
must
NASA
uses
PIM
in the
Cisco-based
on the Proteon router portion, since they are oriented
[Hurwicz, 97].
Since distance learning via videoconferencing in the data to be transmitted worldwide,
PIM-SM
Navy
will require
should be seriously considered as a routing
protocol in NIPRnet routers used for multicasting.
IP over ATM
2.
The NIPRnet has a 10-node connected via
(SVC)
SONET OC-12
ATM backbone
(622Mbps)
pipes.
in the Continental
The
ATM
United States that
switches provide switched
or permanent virtual circuits (PVC), and has promised to handle the
IP multicast traditionally did not address.
QoS
issues that
Therefore, instead of the IP datagrams being
routed across the long-haul pipes, they will
NIPRnet
is
router closest to the destination.
71
jump
to the
ATM
backbone and
exit at a
Although loads, one major
mapped
to
it
it
goes over the
Not converting IP datagrams
IP-to-ATM protocols such
as
to
MPOA
traffic
across
traffic
supposed
ATM backbone, and then converted back.
ATM cells eliminate three potential problems.
First,
ATM
many
are complicated, and
officially set, although they are close to
is
ATM is that the IP datagrams have to be
Second, standards for the protocols to
network managers.
ATM
has the ability to scale under high traffic
problem with transporting IP over
ATM protocols before
push more IP
ATM
has been proven that
being finalized. Finally,
to
do (such
as voice)
and use ATM's
Therefore, finding economical
fast
IP to
if
unfamiliar to
ATM
are
the challenge
all
still
is
not
how
to
of the other things
hardware for switching IP
ways of
trafficking IP datagrams
ATM network backbones can be a plus for IP based videoconferencing applications.
ATM
network combines layer 3
scalability
switching and high performance, essentially amounting to that can stream data at high speeds.
switches,
the
VC's
flexibility
across a
with layer 2
TCP/IP network,
development of layer 3 routing
in
IP Switching
Developed by
ATM switches.
The idea
is
Ipsilon Networks, IP switching software creates IP ability in
to establish a path across a network. If a network of IP switches
up a "switched" virtual
improve
Through
and
two popular methods have emerged, IP switching and Tag switching.
a.
as an
map
across the data-oriented Internet, you can ignore
[Dutcher, 97].
IP over an
set
is still
circuit
traditional IP routing.
ATM
determine
The
(VC) among themselves across
ATM switch acts as a router for low-duration traffic and
switch for long-duration flows.
how
a network, they can
It is
designed to allow network administrators
long a flow should be in order to activate switching instead of IP routing.
72
NASA is currently conducting studies on the use of IP switching. simulation studies have
Its
shown eighty-four percent of data packets can be DP routed
[Breeden, 97].
Tag Switching
b.
Tag Switching software
is
developed by Cisco Systems. Working with
ATM
networks, the software tags, or maps, the current network and stores the data in routers. The data packets are tagged and switched as they leave their starting points (in this case
Bandwidth Management Centers). The tags can use the Last-in-First-Out (LDFO) method the switch based
through the next switch.
upon
its
ATM backbone portion. A tag
The
priority designation.
The
tags allow the
at
network to plot a course
ATM switches scan the tag and then send
it
to the
can be an aggregate of tags, allowing an iterative process that increases
the scalability of the network.
Unlike routers, the switches will need to
know
the complete
path to the edge router destination.
One drawback is
that tag switching only
the vast majority of routers used in
major hardware procurement
NIPRnet
to utilize this
works with Cisco equipment.
are Cisco routers, there will
method.
73
Since
be no need for
c.
ATM Considerations
If either
of these two aforementioned methods
backbone, native routing will essentially be pushed
is
to the periphery
IP switching or Tag switching to handle the backbone segment. ability to provide almost the
same bandwidth
of conversion to already time
critical data.
as
used over NIPRnet's
of the network, allowing
Each method advertises
ATM without having to ATM
Also, IP over
may
significant savings in architecture changes, but might also alleviate the
being forced to implement
ATM
potential problem with these
to the desktop, requiring
two methods of IP over
development and have not proven
their
ability
to
ATM
scale
not only provide
need for customers
One
even more spending. is
the
add an extra layer
that they are
still
under
under heavy network loads.
Furthermore, most videoconferencing applications are already devoted mostly to
E.
ATM
IP.
VTOECONFERENCING OVER DISN's SATELLITE SYSTEMS A
NIPRnet)
deployed unit's means of transporting videoconferencing will
be by using military and commercial
SATCOM
High Frequency (UHF) and Super High Frequency (SHF) High Frequency (EHF) Medium Data Rate (MDR), terminals (Challenge Athena) into an entry point or
to the terrestrial
segments of DISN,
DISN
(i.e.
(C-band and Ku-band), Ultra
SATCOM, MILSTAR
DSCS DISN
over
(military), and/or
gateway.
To
C
Extremely
band
SHF
provide a gateway
this integrated satellite transmission
system will be
further interconnected with the services of the Standardized Tactical Entry Point (STEP).
74
Space Segment
1.
The space segment II/m multi-channel
SHF
is
composed of Ultra High Frequency (UHF)
75bps - 1.5Mbps(T-l),
(EHF) Medium Data Rate (MDR)
SATCOM
commercial
(L,C,and
Broadcast System (GBS), which Since
is
Ku
for
MILSTAR
medium
data
rate
SATCOM, DSCS
Extremely High Frequency --
4.8Kbps
1.544Mbps,
-
bands) - 2.4Kbps - 8.448Mbps, and the Global
currently being readied.
satellites are inherently
broadcast by nature, an implementation of a typical
satellite link requiring satellite terminals
and military or commercial
satellite
resources
fits
well within the IP multicast basic model.
Deployed
SATCOM NCTAMS Navy
units'
facilities,
entry point accesses are currently supported primarily at
which serve
sites requires circuits to
three of the four
be
terrestrially
NCTAMS.
Navy
back-hauled to the nearest
Navy
access to non-
NCTAMS
site.
access procedures to terminal segments are described in Naval Telecommunications
Publication (NTP)-4, NTP-2, and Communications Information Bulletins (CIBs).
Terminal Segment
2.
Connectivity with shore communities can be leveraged using the Standard Tactical Data Entry Points (STEP).
STEP
is
a Joint Staff directed upgrade to the
portion of the Digital Communications Satellite Subsystem
(DCSS) program, which
designed to improve and standardize Navy Tactical Satellite Communications
Fourteen
STEP
DSCS
sites
sites will eventually
DSCS is
(SATCOM).
be upgraded worldwide to provide access to DISN.
provide both ship-to-shore and ship-to-ship communications consisting of
75
operational and administrative traffic.
single
two
STEP
site
These
sites
could be either single or dual, whereas a
supports one satellite coverage area while a dual
satellite areas.
These gateways can allow at-sea units
STEP
site
NIPRNET
routers are installed at the
path provided from the
is that tactical
CINC
STEP
access to
approval.
site
ITSDN
The ITSDN IP
and provided by the
ITSDN is
STEP
router to the
at least
to quickly connect to the
Under
sustaining base services that they need for videoconferencing data.
Program,
supports
sites,
the
DISN
ITSDN
with a 512Kbps-transmission
NIPRNET
backbone.
One drawback
provided only on a temporary basis and
may
require
router address assignments for tactical units are obtained
user.
Network Cache at the Gateways
3.
Because
the
gateway
ship/shore
is
a
component
of
the
paths
of
many
videoconferencing sessions travelling across the NIPRnet, storing sessions on a cache server offers a potentially significant savings in
bandwidth and end user latency by allowing end-
users to retrieve data at the gateway, rather than having to reach-back to the original source.
Network caching can be used
to deliver to sea video/audio
from
large disk caches at
various gateways, while saving needed for bandwidth across the NIPRnet' s territorial
backbone network.
Therefore,
if
session real-time, he or she might
the stored (recorded) session
courses,
it
Therefore In order
must be assumed this
a student
were not able
to receive a videoconferencing
download a session from a network cache
would
be. Since personnel will
that all units will not
be enrolled
server,
where
in a variety
of
be downloading the same information.
type of flexibility would require a very large disk cache to store information.
manage
the resources, a certain
amount of
76
digital storage
space would need to be
allocated for each course
on
the
cache server, and also
it
must be decided how long
a videoconferencing session "forward stored" on the server. For example,
and voice data stream, transmitted
network cache
to the
at
if
to leave
a typical video
300Kbps (near
the upper
transmission end of VTXS), were fifty minutes long, the storage space required for the
lecture
would be approximately
1 1 1
300Kbps stream 37.5KBps
*
Table 5-1 shows the estimated storage space.
Mbytes. *
Byte/8
1
bits
= 37.5KBps
3600 seconds/hour = 135MB/hour
135MB/hour*.825hours =
1 1
1.375MB required per
lecture
Table 5-1: Estimated Digital Storage Requirements
If
each course stored one week of lectures on a
5GB
disk drive, leaving storage
space for system operation, over 40 lectures can be stored on just that one drive. digital storage
expected to cost about .02 cents per
MB
by 1998
3 ,
With
cost for storage is
minimal.
Network cache systems could be used with broadcast
videoconferencing data to
users.
the Global Broadcast
The
communications payload carried aboard U.S. Navy
GBS
UHF
System (GBS)
space-segment
is
Follow-On (UFO)
providing reliable multicast transport data protocols with
GBS,
a
Ka-Band
download
videoconferencing sessions from a gateway, and store data locally for future use. requests can be
made by a slower back
channel.
In order to
By
satellites.
users can
to
User
manage bandwidth over
the
space segment, each unit can be given a download-time window, or the network cache can
be controlled to deliver content
3
to sea only during
Survey taken by consulting firm Disk/Trend
Inc. of
non-peak hours.
Mountain View, CA.
77
SHIPBOARD
F.
ADNS
1.
Because many shipboard networks are not interoperable and require some type of
gateway Digital
to interface
with other systems,
SPAWARSYSCOM
Network System (ADNS) within the
(JMCOMS).
ADNS
is
has developed the Automated
Joint Maritime
attempting to convert the
Communications Strategy
Navy stovepipe systems
into network-
compatible systems without incurring the cost to completely redesign and procure
new
systems for delivery data to afloat forces [Bergdahl, 96]. Currently the bandwidth of
as
it
improves bandwidth capacity,
interface to end-user video
ADNS
cannot support real-time videoconferencing, but
ADNS's
routing and switching system will provide the
and voice data across available
RF
switching subsystem should include an IP router and a suite of protocols.
The
routers should also support
QoS
media.
common
protocols, such as
The
routing and
multicast routing
RSVP.
In order to
prevent multicast packets from wasting unnecessary bandwidth on the shipboard multicast filtering switches might be used.
up
G.
filters
so multicast traffic
LAN,
IP multicast-enabled switches automatically set
only directed to participating end-nodes.
is
CONCLUSION As shown
in the chapter, the
deliver IP multicast to sea.
If
network infrastructure and technology
used, delivering videoconferencing over
networks can alleviate the need for dedicated systems
78
that require
is
available to
DISN's IP-based
people to travel anyway.
Because the architecture and management systems are already
in place, using
networks can provide distance learning to a broad audience with minimal spending.
79
IP-based
80
VI.
VIDEOCONFERENCING APPLICATIONS
INTRODUCTION
A.
This chapter discusses typical videoconferencing software and hardware that can be
used to deliver distance learning via videoconferencing from a desktop computer over an IP-
based network. This chapter does not endorse any particular software application(s), but
merely providing some examples of provides the
common
is
This chapter also
tools currently available.
recommended standards when employing desktop videoconferencing.
VIDEOCONFERENCING APPLICATIONS
B.
Although most of the newer routers and switches are configured
many of them
multicast,
are,
by
default,
not enabled.
Also,
many
to support IP
current software
applications are unicast and must also be modified to interface with the multicasting
capabilities of
[Hurwicz,
TCP/IP
stacks,
which
Because
97].
in turn, join
companies
and leave multicast groups by using
realize
that
there
is
great
IGMP
potential
in
videoconferencing, these issues have not inhibited application developers from eagerly creating
new
products.
4
Bandwidth and picture quality
is still
a major impediment, but other barriers like
standardization, costs, and installation costs continue to decrease.
its
4
collaboration tool, NetMeeting, in
According
4,000
Web
to
Multimedia Research Group,
sites
each year for
Inc.
its
free Internet Explorer 4.0 browser.
of Sunnyvale, CA, and Fuji Keizai
offered video clips in 1996. That
at least the
Microsoft has embedded
number
next three years.
81
tripled to 12,000 in
Netscape
USA, approximately
1997 and
is
expected to triple
Communicator
4.0,
which
is
Microsoft also has released a
also free, packages an analogous tool, Netscape Conference.
UNIX
version of Internet Explorer 4.0. The
uses free videoconferencing desktop applications
reliable.
Unfortunately,
many
(vie,
vat,
sdr,
wbj
MBone
that are
proven and
of the commercial desktop applications, which are
MBone
are not fully compatible with the
tools,
which
are mostly
also used
PC
based,
UNIX based.
Delivering synchronous/asynchronous video and audio streams to sea not only requires a network architecture, but
it
also requires software tools that are capable of
providing quality content to the student. Even so, quality content delivery does not replace the need for occasional student/instructor collaboration. Today's desktop videoconferencing
tools
can generally be broken
collaboration applications,
down
two
categories.
First
are
standards-based
which provide complete information-sharing solutions
the spectrum
from one-to-one
applications
that
to fully interactive meetings.
broadly distribute
one-way,
collaborating applications enable users to
as for desktop videoconferencing.
it
into
live
or
that span
Secondly, there are streaming
stored
presentations.
communicate with a small number of
Desktop
others, such
Streaming applications are much more scalable, making
possible to reach a virtually unlimited audience.
Streaming applications will generally have both client and server software, whereas collaboration
applications
can be
client-to-client.
To
inititalize
multipoint
sessions,
collaborative application users register their contact information with a location server.
Fourl
1
and Microsoft's Internet Location Server (ILS) are two examples. These servers are
based upon Lightweight Directory Access Protocol (LDAP).
Because audio
is
the
most
critical
and sensitive aspect of videoconferencing,
applications should provide features that allow audio adjustments to compensate for non-
82
guaranteed bandwidth. Applications must support different audio codecs in order to allocate
amounts of the data stream
certain
for different bandwidths.
Chat room software can be
used as an option when voice and video are bandwidth constrained.
The
ability to tune
audio during transmission, and embedded Forward Error Correction (FEC) or redundancy
schemes, used in
CU-SeeME
and the MBone's
rat tool,
can help minimize poor audio
reception.
Desktop videoconferencing collaboration applications also need a combination of
document management which allow users the whiteboard.
as setting
capabilities,
to capture
such as
file
whole windows or
sharing, white board,
parts of
windows
for cutting
Multicasting
BSD 4.3
videoconferencing
readily supported
as
applications
Berkley Socket API, which
UNIX, and Windows 95 and NT. As
OS's such
and pasting to
by Winsock
2,
these API's
is
use
is
basically
required.
a
straightforward
supported by operating systems such as
become cross-platform capable, and more
they will be ready for widespread use on PC's, running
Windows.
RECOMMENDED STANDARDS
C.
H.323 and H.324, T.120, along with multicast protocols, such and
tools,
Standard e-mail applications can be used for administrative purposes, such
up time for point-to-point conferencing when additional help
extension to
and snapshot
RSVP make up
as
IGMP, RTP, RTCP,
the primary standards for desktop videoconferencing systems.
extension of H.320, H.323 addresses multipoint videoconferencing over ISDN, well as
LANs
and the
Internet.
H.324
is
As an
POTS,
as
the standard for real-time multimedia standards
83
When
over POTS.
using application from different vendors, ensure that each completely
implements the standards
it
For example Microsoft NetMeeting and Netscape
claims.
Conference are both "H.323 compliant," but they do not have any
Even with these
rendering them unable to talk with each other.
common
audio codecs,
misinterpretations, the
standards-based support and deploying an application base required for most desktop
videoconferencing interoperability
modems
over
no longer an
across
POTS
videoconferencing.
compliant chip
is
in the past,
major problems. Dial-up with
the
still
network bandwidth and
continues to be a choke point for delivering and receiving
As H.324
sets into
As
platforms are
different
still
inhibitor.
matures, manufacturers will begin to build
As of now, H.324
hardware.
is
more H.324
acceptable for point-to-point
collaboration, but not for supporting IP multicast.
Although the ITU-T has provided the baseline codec standards for videoconferencing there are several de facto standards that have emerged. for
Windows and Apple QuickTime
with both basis for
are
common
Windows and Macintosh environments and
MPEG-4. The use
One of the
first
companies
relate to real-time video
to
some of
the
is
compatible
ITU-T
CPU
as the
usage, but
capable.
market a product
fully
based upon IETF standards
that
and audio streams, and ITU-T standards for data compression and
decompression was Precept Software.
were
more than
QuickTime
has been accepted by
of hardware codecs can alleviate
today's multimedia capable processors are
client
video codecs.
Microsoft Video
initially available for
Its
Flashware Server software and IP/TV viewer
Wintel based systems.
nonproprietary standards, this product can receive capability to interoperate with
UNIX
platforms.
84
Because of the implementation
MBone Until
group sessions, giving
it
the
more companies adopt universal
standards, this
is
one of the few options for cross-platform capability between
users.
85
UNIX
and
PC
Table 6-1 describes the
minimum
standards needed for videoconferencing systems.
LANAVAN,
POTS
Internet
H.324
H.323
Video
Audio
H.261
H.261,
H.263
H.263
G.711.G.7.22,
G.723
G.728,
Full-Duplex
Full-Duplex
T.120,JPEG,GIF
T.120, JPEG, GIF,
TIFF, Postscript, Still Frame Capture, File
TIFF, Postscript,
Transfer
File Transfer
Chat Functions,
Features
Chat Functions, Application Sharing
Multicasting
RTP, RTCP, (RSVP,
Whiteboard
Additional
RTSP when
Still
Frame Capture,
Application Sharing
adopted)
Multiple Simultaneous Sessions
BW Controls(Frame-
Controls
Rate,
BW Controls
Image Size)
Yes
Yes
Additional
Firewall
Trial
Support
Configuration,
testing
Asynchronous Support
Trial
Copies for
Copies for
testing
Router
MOSPF
Support
PIM Table 6-1: Videoconferencing Standards over IP Networks
86
D.
HARDWARE Today's desktop computers provide most of the hardware components needed for
videoconferencing.
is all
A good camera and video capture card, which can cost as little as $200,
of the upgrading that
is
normally required. This
is
a markedly low price in comparison
to roll-about
and room-based systems. The release of its newer,
processors
sealing the fate of expensive hardware codecs. This
is
faster
is
multimedia based
the
recommended
desktop system hardware requirement to support desktop videoconferencing:
Desktop w/ processor Digital
camera
that supports
for face
view
multimedia
5
Microphone Speakers and/or headphones 16
bit
sound card, (full-duplex)
Video Card
Video capture card
6
Web Server7 Minimum 28.8Kbps Modem
5
Cameras
excessive 6
recommended. Parallel port cameras place requires powerful CPU's- less than Pentium 133, use an Analog Camera). include onboard codecs, but as processor power has increased, these more
that connect to video capture boards are
CPU cycle time
Video capture cards may
(for lesser
expensive boards are unnecessary. This recommendation the capturing device 7
it
is
will use a video capture board.
For Streaming Video Applications over Internet/Intranets
87
based upon a face-to-face conference. If a server
is
Cameras
that
connect to video capture boards are recommended.
are unacceptable because of inadequate data throughput,
cameras
Parallel
and because they require excessive
CPU cycle time.
E.
SUMMARY The ITU-T and IETF standards
will likely gain
broad acceptance since they are
based upon videoconferencing over the commonly existing network architectures. In order for videoconferencing to gain full acceptance, H.320,
H.323 and H.324 must work together
integrated applications.
Although desktop videoconferencing
is
becoming more capable, the frame
and small picture size of streaming videoconferencing applications are in conjunction with collaborative software
shared control, there
is
still
rates
lacking.
If
and
used
such as whiteboards, shared application and
adequate functionality to conduct meaningful learning.
88
VII.
A.
VIDEOCONFERENCING DEMONSTRATION
INTRODUCTION
This
chapter
provides
a
proof
of
concept
that
demonstrates
how
current
videoconferencing software can be used to deliver synchronous or asynchronous material for distance learning over an IP based
on work accomplished
network via multicast. The demonstration
in Internetworking:
is
follow-
Economical Storage of and Retrieval of Digital
Audio and Video for Distance Learning [Tiddy, 95] and Internetworking: Worldwide Multicasting of the
B.
Hamming Lectures for Distance Learning
[Emswiler, 95].
OVERVIEW Several free software tools were considered, and the one selected
was
the
MBone
VCR on Demand (MVoD), developed by Wieland Holfelder at the University of Mannheim, Germany.
The
MVoD
is
a free, experimental software solution for the interactive remote
recording and playback of multicast videoconferences. graphical
user interface
The
MVoD
Service offers a
(GUI) environment where the user can interactively record
audio/video conferences on a remote server, controlling the recording session with a local client application. Later, that
same user or other users can play the session back on demand,
via multicast or unicast.
Through the use of this •
tool, the goals
of this experiment was to demonstrate:
A successful download and installation the MVoD Service software.
89
•
Multicasting a prerecorded taped lecture over the
MBone
via an
while recording the multicast lecture using the
MVoD
Service from a second
workstation that has the
•
Use
the
MVoD
session over the
C.
MVoD Service software installed.
Service to playback and multicast a satisfactorily replicated
MBone, which can be
received by multiple users.
DEMONSTRATION To begin
MVoD
the testing, the
Service software was downloaded from the
http://wwwJnformatik.uni-mannheim.de/informatik/pi4/projects/MVoD. the software
RAM,
SGI workstation
was
running a
installed
Version 0.9a7 of
on a Silicon Graphic Indy, running IRIX 6.2 OS, 128
MIPS R1000
processor.
The MBone
tools sdr, vie
The
MVoD architecture consists of three components:
•
The
MVoD Server:
handles the user and session management
•
The
MVoD Client:
offers the users a
•
The RTP DataPump:
is
access the
MB
of
and vat were already
installed.
GUI to
site
MVoD Service
responsible for the recording and playback, the
synchronization and the administration of the
RTP data
streams.
A number of internal protocols have been developed to provide communication between the various •
MvoD
software components.
They
include the:
VCR Announcement Protocol (VCRAP)- the server announces its services to all clients.
•
VCR Service
Announcement Protocol (VCRSAP)-
the clients have access to the
server.
•
VCR
Stream Control Protocol (VCRSCP)- the
session on the server.
90
client
use to access and control a
RTP DataPump
•
Control Protocol (RDCP)- the server uses to control the
DataPumps (one per
An
been implemented with the Session Announcement Protocol
interface has also
[Perkins, 97],
which
about ongoing
used by the
is
MBone
MBone
tool sdr, in order for the
Figure 7-1
sessions.
protocols, which are used in conjunction with
various protocols can be found
IVIvoD
RTP
session).
at the
M
Server «
web
MVoD
the
is
MBone
MVoD
server to learn
architecture with
its
various
Detailed explanations of the
tools.
site.
VCRSAP
-vv tn
VCRSCP
£$
4
VCRSAP-
* MvoD Client
« VCRSCP
-V;
i i
Trdcp
RTP DataPump
Figure 7-1
The on
the
testing
*+
5-^K. / RTPJ
4 V*JI;
MVoD Architecture [Holfelder, 97]
was accomplished using two SGI workstations (Indy and Octane models)
NPS LAN. The
test
lectures
for the multicast transmission,
developed from the thesis "Internetworking Worldwide Multicast of the
for Distance Learning" (Emswiler, 95), were input
from the
line output
workstation
(electric).
of a
VCR
The
The
.
MVoD
software used for the experiment.
to
MVoD
91
Hamming
Lectures
an SGI Indy workstation (blacknoise)
Service
Service, and the
The MBone
which had been
was running on an adjacent
MBone' s
sdr, vat
tools are also free
and vie were the
and can be downloaded
form many
provide
ftp sites that
MBone
The MBone
tools.
tools used have already
been
proven effective, therefore the focus of the Chapter will be on the effectiveness of the
MVoD recording and playback processes.
RECORDING A BROADCAST
D.
The
MBone by
step
first
was
to set
up the workstation expected to multicast
providing video and audio line connections from the
blacknoise was used to create a
MBone transmission was Once
the
MBone
VCR
provided by a
was connected and
15, in order to
On
GUI was
The video and audio source of
the
VCR that played back the Hamming Lecture Series.
used to control the
MvoD
MVoD
Service
(maximum)
was
MVoD server creates
If
a standard
requirements would be approximately 62 per hour. (This size
fits
The
MVoD
client
The May 26
th
1995 lecture
which lasted for 37
Based
for each recorded session, the total file size
the recording averaged
1.24MB
50-minute lecture were held, the storage
MBs. An expected
conveniently inside of a
92
set to
of the recording was noted.
was approximately 46 MBs. Therefore
per minute of data stored.
running.
vie video stream,
file size
was
(ttl)
LAN.
MVoD server and RTP data pump.
using a 128kbps
the
settings for vie
audio (64Kbps) were used. The time-to-live
After the session was recorded, the
for the transmission
was multicast over
For the multicast, default bandwidth
the workstation "electric," the
the five files that the
75MB
on
keep the transmission restricted to the campus
was recorded by minutes.
PCM
session.
VCR. The
sdr tool
the session created, the lecture
using vie and vat (RTPv2).
H.261 (128Kbps) and vat
upon
new MBone
the lecture over the
file size is
100MB
zip disk).
thus approximately
PLAYING BACK AN MBone RECORDED SESSION
E.
The next
MVoD
step in evaluating te
Service was to play back (multicast) the
recorded session while simultaneously transmitting
GUI on
client
case)
by
electric,
the server
When
list
back
over the
MBone. Using
the
MVoD
of sessions previously recorded (which was only one, in our
was displayed.
the option of playing
selected.
a
it
Once
the session
either audio, video or both
the play button
was
was
selected, the
GUI
also provided
mediums. Both audio and video were
clicked, the session
was
multicast over the
MBone
and
vie and vat were automatically launched locally in order for the person playing back the
session to observe
it.
The transmission used
the
same bandwidth
settings that
were used
during the original session and can not be changed.
The rebroadcast (play back) of
From
"electric" and "blacknoise."
between the recorded session and the there
was no congestion on
was observed using
the observation, there
vie
and vat tools on
was no discernable difference
There was no packet loss due to the fact that
original.
LAN containing the multicasting and receiving workstations.
EVALUATION OF RESULTS
F.
Currently
with
the
the session
MvoD
UNIX command
Therefore install
it is
lines
UNIX
systems.
For a user having
and environment variables, the
recommended
the software.
processes.
only runs on
that only
During the
System Administrators or experienced
initial
experience
MVoD tool is not easy to install.
installation, there
UNIX
were problems with
For instance, some processes could not access sockets even
the socket had been killed.
little
users
killing
after prior process at
After becoming more proficient with the tool, and properly
93
shutting
it
down,
this
installation simpler,
One
was no longer an
and will
likely provide a
down
rate of the transmission.
the
In
CPU
all
Windows
MvoD may make
version as well.
many
applications running on the
cycle time, effectively slowing
down
the compression
of the playbacks (multicasts), the default transmission rates
on the audio and video provided a
is
Further development of
having too
result important to note that
workstation slowed
No
issue.
clear reproduction of the original audio/video session.
experiments were conducted using the using the
MBone wb
tool.
Whiteboard recording
not likely to occur soon due to the distributed asynchronous nature of events.
The
results of the audio
and video testing are satisfactory and demonstrate the
successful recording and payback (multicast) of a distance learning lecture using the
MVoD
Service.
G
SUMMARY The
results of this
experiment proved that the technology exists for software tools
available to receive, archive, and retransmit distance learning lectures.
properly, the software provides a simple
GUI
that is easy to use,
Once
set
up
and not only provides
playback on demand but also recording on demand. Being able to record content for future use enables users to build a local library of distance learning content.
The
MVoD
tool, or a similar tool,
can be used to remotely record an instructor's
lecture.
MvoD could be
MBone
tools to connect to the session during the live broadcast, or use the
GUI
set
up
to
perform as described
to receive a prerecorded session at a
in
Chapter V.
more convenient
94
time.
A
If
student can use the
MVoD
client
bandwidth over the
network segment
is
restricted,
which may often be the case, users can
the cache server for local playback.
95
ftp the session
from
96
Vin.
CONCLUSIONS AND RECOMMENDATIONS
SUMMARY OF FINDINGS
A,
The underlying premise of
implemented over the currently available point-to-point, expensive,
desktop videoconferencing can be
this thesis is that
DISN
room based systems
IP-based networks instead of dedicated
that
can not provide the scalability necessary
to deliver distance learning to a broad, globally dispersed audience.
IP multicast
is
designed to scale well as the number of participants and collaborations expand so that
adding one more user doesn't amount to adding a corresponding amount of bandwidth. doesn't cost any one.
This
fits
more or
require any
for 100,000 viewers than
it
does for
well with desire to deliver distance learning to numerous participants.
Just within the past
strides,
more bandwidth
It
two years videoconferencing technology has made enormous
and the current capability to implement
real time, off-the-shelf or free standards
based products has advanced greatly beyond what was available in the sufficient, well-tested standards that
can be used
in IP
videoconferencing via IP-based networks in the DII
is
past.
based videoconferencing.
There are
Desktop
a viable tool that can add numerous
economical benefits, such as a decreased spending for travel and eliminating the need to rely
on
large,
room-based videoconferencing systems.
97
B.
RECOMMENDATION FOR FUTURE RESEARCH This thesis provides a preliminary study on the technological and economic benefits
of implementing IP multicast videoconferencing technology from desktops to remote
locations.
determine
As the
part of the
strategic
bandwidth parameters,
technology within the DISN. •
planning process, additional research
comparing
ATM
such
latency,
as
Additional research
is
on
delay,
required in the areas
multicast to IP switching and
its
is
needed
to
videoconferencing
of:
viability
in
wide-scale
videoconferencing •
conduct a comparison of current desktop videoconferencing software
in its
implementation in distance learning. •
determine the feasibility of tunneling over NIPRnet.
•
setting
up a course and delivering
its
contents using the
MVoD
Service
is
another area of research that can provide an actual demonstration of distance learning from the desktop.
•
how network caching and web
•
the implementation of
hosting can be used in videoconferencing
RSVP and RTSP over the NIPRnet.
98
APPENDIX A. GLOSSARY OF TERMS API: Application Programming
Interface; the generalized
term for a defined software
interface for software applications.
Asynchronous Transfer Mode (ATM): A connection-oriented technology defined by the ITU and the ATM Forum. At the lowest level, ATM sends all data in fixed cells with 48 octets of data plus five octets of header information, per cell.
Autonomous System:
A
network controlled by a single administrative authority; a
routing domain.
Broadcast: The sending of information from one to Class A:
all
hosts in a
A type of unicast IP address that segments the address
LAN network.
space into
many network
addresses and few host addresses.
Class B:
A
type of unicast IP address that segments the address space into a
number of network and host
A
Class C:
medium
addresses.
type of unicast IP address that segments the address space into
many
host
addresses and few network addresses.
Class D: Multicast IP group addresses. Connectionless:
Cyclic Redundancy Check; a
Ethernet: 80s.
to describe data transfer without the existence
of a virtual
UDP is connectionless and provides best effort- unreliable delivery.
circuit.
CRC:
Term used
An
Became
Frame: The
industry
LAN
mechanism
to detect errors in frames.
standard sponsored by
the basis for the official
IEEE 802.3
link-layer data entity; data is
DEC, Xerox, and
Intel in the early
LAN standard.
packaged
in
frames, for the purpose of
transmission over a network. Frames are bounded by flag characters or
some other
delimiter.
H.320:
An ITU-T
switched
H.323:
umbrella of standards for videoconferencing over narrow-band
circuit-
WAN services such as ISDN.
An
extension of H.320,
it
covers videoconferencing not only over narrow-band
WAN services, but also on packet-switched networks, such as LANs and the Internet. H.324: The ITU-T's standard for real-time multimedia over standard 28.8Kbps V.34 modems or better.
99
POTS
lines using
Host: The generalized term for any device that can be a source or sink of information on a network. Generally, a host is a single-networked computer.
IETF: Internet Engineering Task Force; the body associated with recommends and approves "standards" for use on the Internet.
IGMP:
Group
Internet
Management
Protocol,
the
protocol
communicate with the nearest router supporting multicast membership in a multicast group. IP: Internet Protocol; the network layer (layer 3) of TCP/IP.
to
the Internet that
with notify
Network
which hosts them about
layer addresses are
used by routers for routing purposes.
The
ITU-T:
Telecommunications Standardization Sector of the International Telecommunications Union, a body of the United Nations which controls the standards for telephone systems.
MAC: media
Media Access
Control; the protocol used in a
LAN
or other shared transmission
for gaining access to the media.
MBone:
Multicast Backbone
is
a virtual, experimental network that runs on top of the
and audio around the world.
internet to provide multicasting of live video
Multicast: The sending of information from one to many, but not network. See
RFC
all
members of
a
1112.
Multicast Group:
A
group set up to send and receive messages from multiple sources and receivers. These groups can be set up based on frame relay or LP in the TCP/IP
protocol suite, as well as in other networks.
OSI Model:
A
seven-layer model of data communications protocols standardized by the
International Standards Organization (ISO).
PVC: Permanent
Virtual Circuit; a permanent logical connection set up with packet data
networks such as frame relay or
RFC: Request
for
Comment;
and recommend practices
RTP
ATM.
the
document
that the
IETF uses
to define standards for use
in the Internet.
v2: Real-Time Transport Protocol Version 2
is
a real-time transport protocol that
provides end-to-end delivery of services to support applications transmitting real-time data,
for example, interactive video
services.
See
RFCs 1889 and
and audio, over unicast and multicast network
1890.
100
RTCP: Real-Time Control Protocol is a control protocol used in conjunction with RTP. RTCP provides information to applications, identify RTP resources, control RTCP transmission intervals, and conveys minimal session control information. See
RFCs 1889
and 1890.
RSVP:
Resource Reservation Protocol
is
an experimental resource reservation set up
protocol designed for an integrated services network, that
An
application might invoke
SVC:
is
currently under development.
RSVP to request specific end-to-end QoS
Switched Virtual Circuit; a switched logical connection
set
for a data stream.
up on a temporary basis
with packet data networks such as frame relay or
ATM.
TCP/IP: The protocol
The most important protocol
suite used in the Internet.
suite
used
in networking.
TTL
(time to
live):
A
counter that
is
decremented each time a packet passes through a
router.
Unicast: The sending of information from one to one in a network; point-to-point data packet communication.
101
102
APPENDIX B. INSTRUCTION FOR the BASIC OPERATION OF THE MBone VCR on DEMAND SERVICE (MvoD) This user's guide has been developed from experience and the information
provided by the
HTML
program.
also
is
It
a
files
accompany
that
follow-on
guide
Internetworking: Economical Storage of
Distance Learning (Tiddy, 95). desires to use the
in
no way
MBone Web
A.
all
MBone VCR
encompassing.
tools.
It is
the actual the
Service
instruction
manual from
Retrieval of Digital Audio
and Video for
of the
and
MVoD
MBone VCR
designated to provide basic assistance to anyone that
Service to record or playback a multicast session, and
There are no instructions
Information about the
MBone
in this
can be found
at
is
appendix for operating
The
MBone
Information
available at http://www.MBone.com/.
OVERVIEW OF THE MVoD SERVICE During the recording, the
MVoD
upon the information provided by application, the
the
Service will synchronize the data streams based
RTPv2
protocol.
As with any
multicast capable
MVoD Service does no need to know the source address of a data stream
or the exact content of the data stream, as long as the data stream conforms to the
protocols supported by the
MVoD Service.
A session recorded by the MVoD Service can be one of as many as sessions that a user desires to record.
As many
simultaneously.
103
as
20
clients
100 multicast
can access the server
To playback
a recorded session, the
MVoD Service RTP data pump sends the data
out to the network, recovering the original timing and synchronization of
all
the
media
streams included in this session and using the same network protocols used by the applications from
which the data was recorded. The
MVoD interface is
shown
in Figure
B-l.
ii ii ii
BQUPAm BiatefeJd
•
Gbstum Wofk»hop 97
i
u u u ;.u u
De*«J Corrfcuafcn CoUofaoratorj
FAU-W HWWJ
.
ICASTMBONe Channel
IMJ— Channel 1 iMJ
— Channels
>d*
SAP «noou»«rne>ot»,;
E Figure B-l
M Bone VCR on Demand Interface [Holfelder, 98]
104
DOWNLOADING THE TOOLS
B.
The
MVoD Service software can be
downloaded from http://www.informatik.uni-
The
mannheim.de/informatik/pi4/projects/MVoD.
contains a description of the
site
service as well as a source for the various versions of the tools (based the
The version described
workstation).
in this
Graphics Indy, running IRIX 6.2 OS, 128 processor.
the
MVoD
client
It
also ran
Service
is
manual
is
MB
RAM,
of
0.9a7,
downloaded
running a
UNIX
to Silicon
MIPS R1000
on a more powerful SGI Octane workstation. The workstation
downloaded
to
must have
JDK
1
.
1
.4
that
or higher in order to run the
and server components. This resource can be found
at
http://www.javasoft.com
Mav/download.
Once
the tool has been
un-tarred using the tar
readme
file will
running the
C.
-xvf command
be included.
It
it
must be unzipped, using gunzip, and then
line to install
it
on the
local workstation.
will provide detailed instructions for installing
The and
MVoD service.
USING THE MVoD SERVICE The following
MVoD
downloaded,
sections describe the basic functions available to the users of the
Service client, and assume that the system administrator has already properly
installed the
MVoD Server.
Additional information can be found in the readme
105
files.
Connect to a Server
1.
The
GUI
will
first
list
thing that a user needs to do
and
connect to the desired
the servers that the clients will be able to access.
themselves via the the left
is
VCR Announcement
window, highlight the desired
Protocol
On
server.
that will connect the client to the server.
The
From
(VCRAP).
MVoD server. servers
the
list
the toolbar, select the
Then, the user will need
The
announce
of servers in
computer icon,
to log
on
to the
MVoD server. an MBone session
2.
Select
Below
the left
window,
This will show the user a the
MVoD
menu and
Server.
select
list
select
from the drop down menu, "SAP announcements."
of the current
MBone
Highlight the desired session.
ends
media
file
1
.
file
in a session in this directory.
The filenames
readme
session.
In the data directory,
file).
An
index
file
ends
files (*.rec
in .idx
and a data
For example, given that a session stored
the automatically generated
raw rtp-data dumped
two
you and file
for these files are automatically generated out of the session
whd-007.rdcp consists of one media with rdcp-id
Then
At
(*.rdcp) for every session and
media
007-0.rec, whd-007-l.idx and whd-007-l.rec.
the
MBone
data
filename and the corresponding rdcp-id.
rdcp-id
down
will create five files related to that particular session in a directory called
in .rec.
session
drop
RTP
one session description
*.idx) per
to the Session
this point the
(the location of directories is explained in the
will find
Then go
advertising to
is
"Connect to session," or go up to the toolbar and click the tape icon.
This step will connect the user to the desired
DataPump
sessions that the sdr
into the file as
it
files
was received from 106
and and one media with
would
The content of
in the
be: whd-007-0.idx,
the .rec file
is
the network.
whd-
more or
The
less
.idx file
contains a fixed-length header per data packet that holds a
from information of the .rec file and a
The
mapped timestamp generated
the rtp-timestamps, an offset to the corresponding rtp-data packet in
few other
details.
user will also notice that, once the connection
made, the
is
record function button, located on the lower right of the display will the left
At
window
will display the
become enabled, and
media (video and/or audio) associated with
ready to record the session that he or she
this point the user is
MBone VCR
is
connected
that session.
to.
Recording a Session
3.
Once
the user
transmitted over the
is
connected to the session, and has verified that the data
MBone,
session are
now being
use the
mouse button
left
select the red record button.
The
MVoD
recorded and stored in the data directory.
tools,
you can not record data
RTP DataPump daemon
do not perform so-called
DataPump daemon and
To
being
data files for the
stop the recording,
to click the square, black stop function button.
With most of the MBone host where the
8
is
is
local loopback.
the
MBone
tools
running
(e.g.
However,
that is sent
from the same
with vat, vie) because these tools
for playback
on the same host since the
you can run the
RTP
RTP DataPump
does
not turn off local loopback.
8
By
default
To
MVoD does not start to record if
it
does not receive a data signal from any of the media in the
when no data is present, select the "Recording without signal" button from the Options drop down menu. Once the button is selected, the digital timer on the right of the display will session.
start
recording
activate.
107
you can not run the source multicast transmission and recording
In other words,
client
on the same machine, but no single-machine
restrictions exist during palyback.
Editing a Session or Media
4.
In order to edit a session that has already been loaded
display the available sessions.
Click on the drop
display and select "Recorded Sessions".
The
left
have been stored (recorded). Select the session that
Once connected
clicking the tape icon.
MBone
a
media so
it
single click with the left
5.
To
is
will display the sessions that
Connect
to the session
by
media types recorded from
the
desired.
window.
mouse button on
the
media
list
will select a
can be muted/unmuted with the "mute/unmute" icon or the "mute/unmute"
selection under the
surrounding
window
the lower left of the
Mute a Media
.
A
down menu on
to the session, the
session will be displayed in the left
and created, the user must
Media dropdown
list.
If the
media
is
muted, angle brackets < >
it.
Play a Session
play a session back, simply click the "play" button. In order to listen to and/or
watch the data,
MBone
selecting the "Tools"
tools vie
dropdown
and vat need to be launched. They can be launched by list
and then the
session, click the stop function button.
108
"start
MBone
tools".
To
stop the
Fast
6.
To
fast
Forward and Rewind
forward
(ff)
or rewind (rew) a session, click on the "ff button or the '
'rew" button.
Random Access with the Session Slider
7.
The
slider
on the lower part of the display enables random access within the
Clicking with the middle button somewhere in the slider will forward or rewind
session.
the session to this point.
marker
will
Clicking the
left
mouse button on
the slider to the
rewind the session about one minute. Clicking on the
the right of the marker will forward the session about
corner of the display, the total length of the session
8.
If the
is
left
one minute.
left
of the
mouse button
At the lower
to
right
displayed.
Loop Mode "Loop Mode"
playback, the session will
entry in the "Options" drop
down
over from the beginning
when
start all
feature allows continuous transmissions.
109
list
it
is
selected during
reaches the end. This
9.
Quick-Keys
The following quick-keys
are available for the
MVoD
Client.
They
will probably
continue to change as the product matures.
Key
Meaning
q
quit
backspace
go back one
P
play
shift-p
play
s
stop
level
at
shift-s
stop at
r
record
shift-r
record
e
edit session
i
info about session
t
start tools
shift-t
start all tools
at
automatically
D.
1
loop-mode on
shift-1
loop-mode off
right
forward one second
shift-right
forward 10 second
ctrl-right
forward
left
back one second
1
minute
shift-left
back 10 second
ctrl-left
back
up
goto end
Down
goto
1
minute
start
KNOWN BUGS and SHORTFALLS This demonstration used Version 0.9a7, downloaded to a Silicon Graphic Indy,
running IRIX 6.2 OS, 128
MB of RAM,
running a
110
MIPS R1000
processor. This version
of the
MVoD
service
many of the manual delineates the
•
F.
more user
friendly, because
The
uses the
GUI
interface to alleviate
inputs required in the (Tiddy, 96) instruction guide.
MVoD
versions for the
error
was
Whiteboard (wb)
is
SUN
MVoD
This section
Service.
workstation could not be untarred.
A
displayed.
not yet supported.
SUMMARY Once
installed, the
MvoD
tool
provides context help in the status the
it
known bugs and some of the shortcomings of the
checksum •
is
mouse
pointer.
Although not
user with simple operation of the
is
line,
all
easy to operate.
depending on the
encompassing,
MVoD client.
Ill
The GUI state
is
of the
this instruction
user friendly, and
client
and the area
manual can aid a new
112
LIST OF REFERENCES Automated
Network System (ADNS),
Digital
http.V/www.jmcoms. org/jmcoms/online/explained/moreadns. htm
Andrews, Dave, "Better Data Delivery for the Net," Byte Magazine, April, 1997. Bergdahl,
"Automation
Jeff,
Program Ashore Improves Navy Networks,"
http.V/www.jmcoms. org/newsletter/june96/ntechup. htm, June,
Breeden,
John
II,
"NASA Team
Tests
Switches,
URL:
1 996.
Routers
for
Net's
Successor,"
Government Computer News, September 29, 1997. Brewin, Bob, "DIS A
Moves NIPRnet
to Sprint,"
Government Computer News, July 8
1995.
CDSfCPACFLT, "USN IT-21," Routine Administrative Message, ZYB PSN 038075M23 Constance, Paul,
"DISA
"
Comer, Douglas, Computer Networks and Internets
"DoD moves to
Computer News, March Coanstance, Paul,
News, August
"DoD
1997,
Separates Global Net-Building requirements into Four
Procurements, Government Computer News, August
Constance, Paul,
R 300944Z Mar
7,
1995.
" Prentice-Hall,
New Jersey
1997.
Rein-in NIPRnet' s High User Fees," Government
4, 1996.
Picks Pulsar for Unclassified
ATM Net," Government Computer
12, 1996.
Defense Information Systems Agency, "Defense Satellite Communications Systems (DSCS) Standard Tactical Entry Point (STEP) Concept of Operations (CONOPS)," July 1,
1997.
Defense Information Systems Agency - Joint Interoperability and Engineering Organization, "Defense Information Systems Network (DISN) Architecture," September, 1996.
Dutcher, William,
"New Backbone Pumps up DISN," Government Computer News,
January 13, 1997. Dutcher, William, "Will IP Switching replace
ATM?," PC Week Magazine, September
24, 1997.
113
.
Emswiler, Tracey for Distance
L.,
"
Internetworking: Worldwide Multicast of the Hamming Lectures Masters Thesis, Naval Postgraduate School, Monterey,
Learning ."
California, September, 1995.
Frank, Alan, "Multimedia
LANs
and
WANs," LAN Magazine,
June 1996.
Gibbs, Mark, "Streaming Sophistication," NetworkFusion, January 26, 1998.
Hudson, Rhett, "DT-5 Enabling Technologies Desktop Video Conferencing", URL: www.visc.vt.edu/succeed/videoconf.html, 30 May 1996. Hurwicz, Michael, "Switched ATM Is Fast, But Not That Smart, Routed JP Not That Fast. Why Not Combine Them?," Byte Magazine, April 1997. Hurwicz, Michael, "Multicast to the Masses: The DP Multicast standard infrastructure isn't yet." Byte Magazine, June 1997.
is
Is
Smart, But
ready, but the
EVITC ITU Standards, URL: http://www.imtc.org/i/standard/i_itustd.htm,\991. "
Development of a Transcoder From MPEG-1 University of Washington, August 1996.
Jin
Zhong,
to
H.261
" Master's Thesis,
Johnson, V., Johnson M., Hall, M., "D? Multicast: Making Things Happen," Data
Communications on the Web, URL: http://www.data.com/tutorials/ip_multicast.html,
May
21, 1997.
Johnson, V., Johnson, M., Hall, M.
"How
IP Multicast Works,"
URL:
http://www.ipmulticast.com/community/whitepapers/howipmcworks.html, 1997.
Johnson, V., Johnson M., Hall, M., "Higher Level Protocols used with IP Multicast"
URL: httpJ/www. ipmulticast. com/community/whitepapers/introrouting. html, 1 997 Johnson, V., Johnson, Infrastructures,"
URL:
M.
Hall, M., "Implementing JP Multicast in Different
Network
http://www. ipmulticast. com/community/whitepapers/
introrouting.html, 1997.
Johnson, V., Johnson, M., Hall, M., "Introduction to IP Multicast Routing," http://w ww. ipmulticast. com/community/whitepapers/introrouting. html,
Joint Staff,
"JROCM
047-95:
DISN Mission Needs
1
URL:
997.
Statement," Joint Requirements
Oversight Council, March 30, 1995.
Koenig,
Harold,
M.,
"The
Surgeon
General's
Sitrep
http://supportl.med.navy.mil/bumed/speeches/SGS23-97.htm, 1997.
114
(23-97),"
URL:
.
Scott, "Forget Slow Phone Companies and Regulators; Anyway," Byte Magazine, January 1998.
Mace,
Mace,
have Put a Hole
Scott, "Internet Technologies
in the
ADSL
Coming
is
ATM
Boat Carrying
to
Shore," Byte Magazine, October, 1997.
McCormick, John, "Videoconferencing
Your Desk," Government Computer News,
at
January, 1998.
MPEG FAQ, "The MPEG Standard", www.csr4.it/~luigi/MPEG/mpegfaq.html. Musich, Paula,
"UUNET
Announces IP Multicast Service," PCWeek Online, September
24, 1997.
Nerino, Michael,
P.,
"
A
Comparison of High End Video Teleconference Alternatives for
the Department of Defense ," Masters Thesis, Naval Postgraduate School, Monterey,
California March, 1994.
Nolle, Thomas, "Reservations about
RSVP," NetworkWorld, October
Office of the Assistant Secretary of Defense, "C4I
May
Handbook
28, 1996.
for Integrated Training,"
1996.
Pappalardo, Denise, "ISPs Focus on
Web
Hosting," Network World Fusion,
December
11, 1997.
Perkins,
Kouvelas,
Collin,
"Notes
Isador,
on
the
38
th
IETF,"
URL:
http://www.cs.ucl.ac.uk/staff/cperkins/reports/ietf_38/node5.html, April 28, 1997.
Petrosky, Mary, "IP Switching:
The Search
for the Truth,"
NetworkWorld, March 03,
1997.
Seminar
Delivery ".
"
Desktop Videoconferencing: Technology and Use for Remote Masters Thesis, North Carolina State University, July 1995.
Rettinger, Leigh A.,
"High Speed Internet Access," Microtimes, httpJ/www.microtimes com/1 74/hispeedaccess. html, 1 998
Savetz, Kevin M., .
Savetz, K., Randall N., and Lepage, Y.,
IDG Books Worldwide, Seachrist, David,
Foster City,
CA,
"
MBone, Multicasting Tomorrow's
Internet
"
1996.
"See and Be Seen Over IP," Byte Magazine, September, 1997.
Seaman, Mick, "New IP-Switch Designs Help move Low-Latency Data Such as Sound and Video Through Large Networks," Byte Magazine, October 1997.
115
Tamer, Murat Tevfik, "Internetworking: Multicast and ATM Network Prerequisites for Distance Learning " Masters Thesis, Naval Postgraduate School, Monterey California September, 1996.
VTEL
Corporation,
"White
Paper
www. vtel. com/vcnews/wpapl .html, "Welcome
to
the
JPEG
on
—H.320:
A
Quality
requirement
Guide",
1996.
Tutorial",
tut/jpegtutl html. .
116
http://dynamo.ecn.purdue.edu/~ace/jpeg-
INITIAL DISTRIBUTION LIST No. Copies
1.
2.
3.
Defense Technical Information Center 8725 John J. Kingman Rd., Ste 0944 Ft. Belvoir, VA 22060-6218
2
Dudley Knox Library Naval Postgraduate School 411 DyerRd. Monterey, CA 93943-5101
2
Rex Buddenberg, Code SM/Bu
2
Naval Postgraduate School Monterey, CA 93943 4.
Don Brutzman, Code UW/Br
1
Naval Postgraduate School Monterey, CA 93943 5.
LT Mark Glover PO Box 1473
1
Walterboro, S.C. 29488
6.
Dipl. Wirtsch. Inf.
Wieland Holfelder
1
University of Mannheim Praktische Informatik
L
IV
15,16
D-68131 Mannheim, Germany 7.
Erik
Chaum
1
Code 2251, Building 1171 Naval Undersea Warfare Division Newport
1176 Howell Street Newport, Rhode Island 02841-1708 8.
Dr. Jim Eagle, Chair,
Code
UW
1
Naval Postgraduate School Monterey, California 93943-5101 9.
Dr.
Ruben
Harris, Chair,
Code
SM
1
Naval Postgraduate School Monterey, California 93943-5101
117
10.
Dr.
Maxine Reneker, Code 013 Dudley Knox Library
Director,
Naval Postgraduate School Monterey, California 93943-5101 11.
Tracy
Hammond Code IB
Registrar
Naval Postgraduate School Monterey, California 93943-5101 12.
Dan Boger Code SM/Bo Naval Postgraduate School Monterey, California 93943-5101
118
D J' r
'
DUDLEY KNOX LIBRARY aoi
00 ^VALPO$fQ^U.Wgf 03943-5101 MONTEREY CA
C 1J \
483NPG
3tflli| TH 10/99 22527-200.-.'
