\documentclass[a4paper,twoside,titlepage]{article}
\usepackage{isolatin1}
\usepackage[T1]{fontenc}
\usepackage{ae}
\usepackage{german}
\usepackage{palatino}
\usepackage{makeidx}
\usepackage{fancyheadings}

\parindent0pt
\parskip1ex


%\frenchspacing          %deutsche Silbentrennung
%\sloppy                 %vermeidet uebergroesse Zeilen

%eigene Def's:
\newcommand{\indbf}[1]{\textbf{#1}\index{#1@\textnormal{#1}}}
\newcommand{\indit}[1]{\emph{#1}\index{#1@\textnormal{#1}}}
\newcommand{\indtt}[1]{\texttt{#1}\index{#1@\textnormal{#1}}}
\newtheorem{definition}{Definition}[section]

\makeindex

\title{Dienste \& Protokolle: \vspace{10pt} \\
Einfl"usse von Multimedia auf Dienste \& Protokolle}
\author{M. Ochsendorf \and T. Nehmer}
\date{WS 1999$/$2000 FH-Furtwangen}

\begin{document} 
\pagestyle{fancy}
\maketitle
%\clearpage

\tableofcontents
\clearpage


\section{Einf"uhrung: Was ist Multimedia}
Multimedia-Informationen bestehen zum einen aus \indit{kontinuierlichen
Daten} (Video \& Audio), zum anderen aus \indit{diskreten
Bestandteilen} wie Texten oder Graphiken.

\subsection{Multimedia-Klassifizierung}
Die Anforderungen an Multimediadienste 
lassen sich nach der in \indtt{ITU-T Recommendation I.350}
\indit{General Aspects of QoS and Network Performance in digital
Network (March 1993)} angegebenen Einteilung von
Bandbreiten-Kommunikationsdiensten in nachfolgend aufgef"uhrte 
Dienstklassen klassifizieren:
\index{Dienstklassen}
\begin{itemize}
\item \indbf{Interaktive Dienste}\\
Diese Dienste erlauben dem Anwender den Empfang und die Darstellung der
Informationen zu kontrollieren:
\begin{itemize}
        \item \indit{Conversation Services}\\
        Echtzeit-Anforderung (\indit{Isochronit"at})\\
        kein Zwischenspeichern der Informationen\\
        Beispiel: Videokonferenzen oder Videotelefonie
        \item \indit{Messaging Services}\\
        Nachrichtenvermittlungsdienste\\
        Zwischenspeichern der Informationen\\
        Beispiel: Multimedia-Mail oder White-Boarding
        \item \indit{Retrieval Services}\\
        Anfragedienste an eine "offentliche Informationsdienste (jederzeit)\\
        Beispiel: Teleshopping oder medizinische Bild"ubertragung
        \end{itemize}
\item \indbf{Verteilungsdienste}
        \begin{itemize}
        \item \textit{ohne Kontrolle} durch den Empf"anger:\\
        unidirektionale Dienste wie Funk \& Fernsehen oder Video
        \item \textit{mit Kontrolle}:\\
        Tele-Learning oder Distance-Learning, Video-on-Demand
        \end{itemize}
\end{itemize}

\clearpage
\section{Anforderungen}

\subsection{Kapazi"atsanforderungen}
Um die Kapazit"atsanforderungen, die bei Multimediadiensten sehr hoch sind,
erf"ullen zu k"onnen, sind an das "Ubertragungsmedium hohe Anforderungen
gestellt.
G"angige Ubertragungsmedien, die diese Bandbreiten bereitstellen sind: Kupfer,
Glasfaser, Radiowellen oder Satellitenkommunikation.
Multimediadaten werden normalerweise als Multicast-Verkehr verschickt, aber es
ist generell auch m"oglich ihn als Unicast oder Broadcast zu
versenden. N"aheres finden Sie im Abschnitt  \textit{L"osungsans"atze} auf
Seite \pageref{loesung}.


\subsection{Qualit"atsanforderungen}
\subsubsection{Sicherheit}
\begin{description}
\item[Authentizität] Gewählreistung der Echtheit der empfangenen Daten. 
\item[Verschl"usselung] Gewährleistung der Vertraulichkeit der empfangenen Daten.
\end{description}

\subsubsection{QoS - Quality of Service}
\index{QoS - Quality of Service}
m"ogliche Parameter, die QoS beschreiben k"onnen:
\begin{itemize}
\item in keiner Weise abh"angig von unterliegenden Netzen
\item geforderte Datenrate/Bandbreite 
\item Echtzeitanforderungen (Isochronit"at)
\item "Ubertragungsverz"ogerung
\item Verlust von Datenpaketen
\item "Ubertragungsverz"ogerung und Datenverlust wird als Toleranzfaktor
bezeichnet.
\end{itemize}
Falls m"oglich, wird die Qualit"atsanforderungen beim Verbindungsaufbau
zwischen den beteiligten Kommunikationsinstanzen und den Diensterbringern
verhandelt. Man nennt dies eine \emph{flexible Protokollarchitektur}, die
w"ahrend dem Verbindungsaufbau entsprechend den geforderten Anforderungen
konfiguriert werden kann.

\subsubsection{AMTP}
\index{AMTP - Adaptive Multicast Transfer Protocol}

OSI-Transportsysteme stellen ausser dem AMTP (Adaptive Multicast Transfer
Protocol) keine Mechanismen zu "Uberwachung und Bereitstellung der geforderten
QoS bereit.

\begin{definition}[adaptive Systeme]\label{adaptiv}
Systeme, die im laufenden Betrieb eine Neukonfiguration der definierten
QoS erm"oglichen, werden als adaptive Systeme bezeichnet.
\end{definition}

Dienst, der die "Uberwachung der QoS vorsieht und durch den Einsatz von
einer der Telefonie nachempfunden \indit{Call-Blocking-Strategie} die
Beeintr"achtigung weiterer aktiver Verbindungen minimiert.

AMTP ist ein Protokoll, das nicht auf eine bestimmte Einsatzumgebung
spezifiziert ist, sondern aufgrund seiner Konfigurierbarkeit sowohl
oberhalb unterschiedlicher \indit{ATM-AALs)}, 
Netzwerkarchitekturen (im LAN-Bereich), oder oberhalb von Internetprotokollen
wie IP eingesetzt werden kann.

AMTP-Bestandteile:
\begin{itemize}
\item \indit{Multicast-Dienste} f"ur den WAN-Bereich:\\
Dienste f"ur Punkt-zu-Punkt- und Mehrpunkt-Verbindungen.
(verbindungslos, verbindungsorientiert oder transaktionsorientiert)
\item adaptiver fensterbasierter Flusskontrollmechanismus
\item Datenwiederholungs-Strategien (redundante Wiederholungen,
router-basierte Neu"ubertragung)
\end{itemize}
Da es den Endteilnehmern nicht zumutbar ist, s"amtliche Parameter f"ur
ihre geforderten Anforderungen zu spezifizieren, ist das erste Muss bei
der Realisierung multimedialer Kommunikation eine geeignete
Benutzerschnittstelle.


Die Qualit"atsanforderungen werden ausf"uhrlich in 
\textit{From Best Effort to Enhanced QoS (ISO / IEC N 827)}
beschrieben.

\clearpage
\section{Klassische Lösungsansätze}
\label{loesung}


\subsection{Unicast}
Die erste M"oglichkeit Multimedia-Daten an die einzelnen Empf"anger 
zu schicken, ist die Daten als \textbf{Unicast-Verkehr
(Punkt-zu-Punkt-Verbindung)} 
\index{Unicast-Verkehr}
vom Server (Videoserver beispielsweise) zum Client zu "ubertragen.
Das hei"st es wird f"ur jeden Rechner, der Multimediadaten erhalten
m"ochte, eine Punkt-zu-Punkt-Verbindung aufgebaut, durch die die
Daten durch das Netz geleitet werden.

Der Vorteil der einfachen Implementierung von Unicast bei Multimedia kommt
nur dann zum tragen, wenn die Anzahl der Gruppenmitglieder nicht sehr gross 
ist.

Nachteile:
\begin{itemize}
\item  enorme Datenmengen, da ein und die selben Daten n-mal vom
Server zu den n-Empf"angern geschickt werden.
\item  Flaschenhals:\\
Der Netzabschnitt zwischen Server bis zum
Endrouter stellt den Flaschenhals der Multimedia-Kommunikation dar.
\end{itemize}
Anforderungen an Dienste \& Protokolle:
\begin{itemize}
\item enorme Datenmengen
\item Der Server muss alle Empf"anger der Multimediadaten in Tabellen
verwalten.
\item langsame Konvergenz bei sich "anderten Multimedia-Teilnehmern
\end{itemize}

\label{unicast_routing}
Routing-Methoden im Unicast-Verkehr:
\begin{itemize}
\item \indit{OSPF (Open Shortest Path First)}:\\
OSPF geh"ort zu den Interior-Gateway-Protokollen, die die Kommunikation
innerhalb eines \indbf{Autonomen System}s (AS) , das hei"st ein Subnetz
das nach bestimmten Administrationsregeln (DNS-Eintr"age,
Routing-Eintr"agen oder Subnetzmaske) verwaltet wird, regeln.

OSPF nutzt das \indit{Link-State-Verfahren} um die Netzknoteninformationen
aktuell zu halten und allen Router im Netz zug"anglich zu machen.
\begin{definition}[Link-State-Routing]
Router reichen Informationen "uber ihre Nachbarknoten an alle Router im Netz.
\end{definition}
\item \indit{RIP (Routing Information Protocol)}\\
RIP geh"ort ebenfalls zu den Interior-Gateway-Protokollen. 

RIP nutzt das \indit{Distance-Vector-Verfahren} um die Netzknoteninformationen
aktuell zu halten und allen Router im Netz zug"anglich zu machen.
\begin{definition}[Distance-Vector-Routing]
Router reichen ganze Tabellen mit allen
erreichbaren Netzen an alle Nachbar-Router.
(schneller \& effizienter als Link-State)
\end{definition}
\end{itemize}


\subsection{Broadcast}
Die zweite M"oglichkeit Multimediadaten zu versenden, besteht darin, die
Daten als Broadcast-Verkehr, d.h. mit Hilfe einer
Punkt-zu-Allen-Verbindung, an alle Rechner im Subnetz zu
schicken (Data-Link-Layer). Eine \indit{Broadcast-Dom"ane} wird durch Router
begrenzt, die die Grenzen eines LAN-Segments darstellen.

Nachteil bei Broadcasting ist der riesiger Datenaufwand:

Die Daten gehen an \textbf{alle} Rechner im Subnetz, das hei"st auch
Rechner die keine Multimedia-Daten beansprucht haben, m"ussen die Daten
verarbeiten und werden solange blockiert. 
(CPU-Last ist bei allen Rechnern enorm hoch)

Anforderungen an Dienste \& Protokolle:
\begin{itemize}
\item Der Server muss keine Adressen seiner Empf"anger kennen.
\item Realisiert auf Data-Link-Ebene
\item sollen mehrere Broadcast-Dom"anen erreicht werden, so m"ussen Techniken
h"oherer Ebenen genutzt werden (Bridges oder Router). 
\end{itemize}


\subsection{Beispiel Internet-Radio}
Der wohl erste Multimedia"=Versuch im Internet war die Einführung des
Realplayers, der eine Unicast"=Verbindung für jeden Teilnehmer öffnet. Die
benötigte Bandbreite wird durch Datenkompression verringert, so daß ein
Datenstrom mit 24 kBit/s bereits akzeptable Ergebnisse liefert. In kleinem
Rahmen ist diese Technik sehr gut realisierbar und arbeitet auch heute noch
ohne grössere Probleme. Beispielsweise wird das FH-Radio ``GLF'' mit dieser
Technik verbreitet.

\clearpage
\section{Neue Dienste \& Protokolle}
Aus den Defiziten der bereits vorhandenen Mittel resultierten folgende neuen
Lösungen:

\subsection{Multicast-Ans"atze mit IPv4}
Da Multimediadaten enorme Anforderungen an die Bandbreite und somit an
die Netztopologien stellen, die die Daten zwischen den
Kommunikationspartnern "ubermitteln, m"ussen Protokolle bereitgestellt
werden, die die Multimediadaten vom Sender bis zum Router des
Empfangsnetzes (bis zu den \indit{Geb"auderouter}) als 
\indbf{Unicastverkehr} durch das Netz schaufeln. 
Erst der Router \textbf{flutet} danach die Daten an alle
Hosts (wie es bei allen modernen Multicast-Routing-Protokollen der Fall
ist).

Heute ist es sinnvoll, den Datenstrom als \indbf{Multicast-Verkehr} gezielt an
die gew"unschten Empf"anger zu schicken.

\subsubsection{Multicast-Kommunikation}
Es gibt drei Parameter, die der Network-Layer definieren muss, um
Multicast-Kommunikation zu gew"ahrleisten:
\begin{itemize}
\item \textit{Aufbau von Multicast-Rahmen}:\\
F"ur die Adressierung von Multicast-Traffic wurde die neue Adress"=Klasse D
reserviert. Es wird der gewöhnliche IPv4 Rahmen verwendet.
\item \textit{Dynamische Registrierung von Multicast-Mitgliedern}:\\
Die dynamische Registrierung ist in RFC 1112 beschrieben. RFC 1112 definiert
das Protokoll \indit{IGMP - Internet Group Message Protocol}.
\item \textit{Multicast-Routing}:\\
Es gibt folgende Standards, die IP-Multicast-Verkehr routen k"onnen:
        \begin{itemize}
        \item RFC 1584 MOSPF:\\
        Multicast extensions for Open Shortest Path First.
        \item RFC 1075 DVMRP:\\
        Distance Vector Multicast Routing Protocol
        \item PIM (Protocol Independent Multicast) 
        \end{itemize}
\end{itemize}

\indit{IP-Multicast (IPmc)} stellt Mittel (IGMP-Internet Group Message
Protocol und diverse Routing-Methoden) zur Verf"ugung, um mehreren 
Zielen Datenverkehr mit hohem Bandbreitenbedarf zuzustellen.


\subsubsection{Aufbau von Multicast-Rahmen}
Multicast-Rahmen beginnen Bin"ar mit \texttt{1110}, das hei"st sie sind im
Adressraum Klasse D zusammengefasst, die zwischen \texttt{224.0.0.0} und 
\texttt{239.255.255.255} (IPV4) liegen.

Server $\rightarrow$ Multicast-Rahmen $\rightarrow$ Netzwerk

\indbf{Multicastrahmen-Aufbau}:
\begin{enumerate}
\item MAC-Ziel-Adresse (Layer 2, 6 Byte lang)\\
Die ersten 3 Byte der MAC-Ziel-Adresse beginnt immer mit \textbf{01-00-5e}
und die restlichen 3 Byte setzen sich aus den 3 rechten Bytes der
Protokoll-Ziel-Adresse zusammen.\\
Zweck: Mapping von L3-IPmc-Adresse zu L2-MAC-Adresse.
\item Protokoll-Ziel-Adresse (Layer 3)
\end{enumerate}
Beispiel:\\
Multicast-Rahmen an die IP-Adresse 224.10.10.1\\
MAC-Ziel-Adresse: \textbf{01-00-5e-10-10-1}\\
Protokoll-Ziel-Adresse: \textbf{224.10.10.1}

Die Reichweite des Multicast-Streams wird durch \indit{TTL - Time to Livefield}
(\indit{Hopcount}) von \indit{IP} beschr"ankt. 

\subsubsection{IGMP}
\index{IGMP - Internet Group Message Protocol}
\index{IGMP-Internet Group Message Protocol}
IGMP ist dabei f"ur die An \& Abmeldung von Hosts bei Multimediagruppen
verantwortlich.

Will ein Host sich Multimedia-Daten vom Server zusenden lassen, so mu"s er
sich beim Server anmelden.
Den Anmelde.- und Abmeldevorgang "ubernimmt \indit{IGMP}:

Anmelden: \indbf{IGMP-Join} Nachricht an Server\\
Abmelden: \indbf{IGMP-Leave} Nachricht an Server\\
Der Server tr"agt die Empf"anger in entsprechende Multimediagruppen ein.

Voraussetzung: IGMP muss auf allen Server, Router und Hosts implementiert
sein.

\subsubsection{MOSPF}
Diese Methode wird wegen ihrer Instabilit"at und der Abh"angigkeit an
OSPF kaum mehr eingesetzt.

\subsubsection{DVMRP}
\index{DVMRP - Distance Vector Multicast Routing Protocol}
DVMRP benutzt einen Technik, die als \indit{Reserve Path Forwarding} bezeichnet
ist. Wenn ein Router DVMRP-Pakete empf"angt, \textbf{flutet} er das Paket aus
allen Ports. Dadurch wird der Datenstrom in allen angeschlossenen LAN-Segmente
erreicht. Wenn es keine Gruppenmitglieder in einem LAN-Segment gibt, sendet der
entsprechende Router eine \indit{prune back-Methode} (\textit{Zur"uckschneiden
der Anfrage}) zur"uck, damit nicht weitere Daten unn"otig an dieses LAN-Segment
geschickt werden. Dieses Fluten mit ggf. anschlie"sendem Zur"uckschneiden wird
alle 60 Sekunden wiederholt.

DVMRP implementiert sein eigenes Unicast-Protokoll. Es hat gro"se "Ahnlichkeit
mit RIP und basiert ausschliesslich auf den Hopcount (TTL-Feld) auf.    

Diese Vorgehensweise mit Reserve-Path-Forwarding und Prune-back wird auch von
\textit{PIM - Dense Mode} implementiert.

\subsubsection{PIM}
\index{PIM - Protocol-Independent Multicast}
\index{PIM!Dense Mode}
\index{PIM!Sparse Mode}
PIM ist ein Protokoll das unabh"angig von dem verwendeten
Unicast-Routing-Protokoll (siehe Kapitel~\ref{unicast_routing} auf
Seite~\pageref{unicast_routing}) arbeitet, d.h. das mit allen
Routing-Protokollen zusammenarbeiten kann.  Diese Unabh"angigkeit von der
Netzwerkarchitektur ist ein entscheidendes Kriterium f"ur den Einsatz von
PIM-Routing-Methoden.  Es gibt zwei Arten von PIM, die sich in der Menge der
unterst"utzten Teilnehmer unterscheiden:
\begin{itemize}
\item PIM - Dense Mode:\\
Dieses Protokoll arbeitet in der gleichen Weise wie das DVRMP. Es ist f"ur
viele Multicast-Teilnehmer geeignet.
\item PIM - Sparse Mode:\\
Bei diesem Protokoll, das f"ur wenige Teilnehmer ausgelegt ist, wird nicht der
Traffic von allen Routern geflutet, sondern es werden Daten solange als Unicast
versendet, bis sie beim letzten Router angekommen sind. Diese Router dienen als
\indit{Treffpunkt Router} oder \indit{Rendezvous Point} f"ur eingehende
Multimediadaten. Ab hier werden die Daten gezielt an die Ausg"ange
weitergeleitet, von denen eine IGMP-Join-Anfrage gekommen ist. 
\end{itemize}

\subsection{ATM}
\indit{ATM} \emph{(Asynchronous Transfer Mode)} ist eine Weiterentwicklung des
Breitband"=ISDN. Da es eine komplette Neuentwicklung ist, stellt alle ATM für
Multimedia"=Dienste notwendigen Mittel zur Verfügung. ATM ist auf den
OSI-Schichten zwei, drei und vier angesiedelt und damit ein sehr vielseitiges
Protokoll. Im Zusammenhang mit Multimedia unterstützt ATM von Grund auf
Multicasting und die Zusicherung einer dedizierten Bandbreite.

\subsection{IPv6}
IP Version~6 ist die Neuauflage des heute verwendeten IP
Version~4\footnote{Version 5 war ein experimentelles Protokoll, dessen
  Weiterentwicklung eingestellt wurde.}. Hauptgrund für dieses neue Protokoll
ist die Tastache, daß sich die Struktur des Internets seit der Entwicklung des
IP grundlegend geändert hat. Wohl wichtigste Neuerung sind die 128-Bit
Adressen, die den momentanen Adressengpass beseitigen. IPv6 bietet alle
notwendigen Mechanismen für Multimediaanwendungen: Multicasting,
Verschlüsselung, Authentifizierung und QoS.

Die Migration zum IPv6 hat bereits begonnen. Das jetzige v6-Netz, 6Bone
genannt, ist ein Virtuelles LAN, daß aus vielen Inseln im Internet
besteht. Diese sind untereinander über die Tunnel"=Technik verbunden. 

\subsection{Bandbreitenzusicherung}

\subsubsection{RSVP}
\indit{RSVP} \emph{Resource Reservation Protocol} ist ein propriet"ares
Protokoll von Cisco das die geforderten Bandbreite zwischen Clients und Servern
garantiert (\textit{Empf"anger-orientierte Reservation}).

RSVP ist auf Schicht 3 des OSI-Modells angesiedelt.
Es ist unabh"angig von den Routing-Systemen zwischen Servern und Clients,
da es einen eigenen Routingalgorithmus implementiert hat.
Die Kommunikation regeln \indit{path requests} des Senders zu den Empf"angern,
die Empf"anger schicken \indit{reservation requests} zum Sender zur"uck.
Da RSVP das "`\indit{Soft State}"'-Konzept realisiert, werden diese 
Requests periodisch wiederholt.
Soll eine Session zwischen Client und dem Anwendungsserver zustande kommen,
speichern die Router den Pfad und die wichtigen Daten der
Session (\indit{Session-ID} und \indit{Reservation-ID}) in Tabellen ein. Sieht
sich ein Router nicht in der Lage eine geforderte Bandbreite garantieren zu
k"onnen, versucht RSVP einen anderen Weg zu finden, gibt es keinen wird die
RSVP-Anforderung des Client abgelehnt. 

\subsubsection{ATM}
Der \indit{Adaption Layer (AAL)} vom \indit{ATM} ist f"ur die Umsetzung
der Informationen von h"oheren Schichten in das Zellformat zust"andig. Die
angebotenen Dienste k"onnen eine feste Bandbreite haben. Der AAL wird in
Klassen eingeteilt, wobei Dienste der \textit{Klasse A} Bandbreite
garantieren. Dienste dieser Klasse haben zus"atzlich noch die Isochronit"at
garantiert. Die folgende Grafik zeigt die Klassifikation der ATM-Dienste:

\begin{center}
\begin{tabular}{|c|c|c|c|}
\hline
Class A & Class B & Class C & Class D \\
\hline
\multicolumn{2}{|c|}{Time relation required} & \multicolumn{2}{|c|}{Time
  relation not required} \\
\hline
Constant Bitrate & \multicolumn{3}{|c|}{Variable Bitrate} \\
\hline
\multicolumn{3}{|c|}{Connection Oriented} & Connectionless \\
\hline
\end{tabular}
\end{center}

\subsubsection{Kodierungsverfahren}
Sprachdaten sind ein m"oglicher Bestandteil von Multimediadokumenten. Die
zugrundeliegende Signale sind zeit- und wertkontinuierlich. Solche Daten
m"ussen durch entsprechende Digitalisierung- bzw. Codierungsverfahren
(\indit{PCM Pulse Code Modulation}) in diskrete Bereiche "uberf"uhrt werden.

Dem Signal wird dabei in regelm"a"sigen Zeitabschnitten Abtastwerte
(\indit{Samples}) entnommen.
Diese werden anschlie"send einer \indit{Quantisierung}
unterzogen und somit einem \textbf{diskreten Wert} zugeordnet.

Falls diese Werte danach noch bin"ar codiert werden, so spricht man von
\textit{Pulse Code Modulation (PCM)}.
\index{Kodierung}
Je h"oher die Quantisierungsstufen sind, desto besser ist die G"ute der
Codierung.\\
(Minimierung der Quantisierungsger"ausche)

Bei der digitalen Telefonie wird ein Abtastrate von 8 kHz mit einer 8 Bit
Quantisierungsstufe eingesetzt.
Dies entspricht einer Datenrate von 64 kBit/s.

\subsubsection{Reduzierung der Datenrate}
\index{Bandbreiten-Reduzierung}
\begin{description}
\item[ADPCM] Durch den Einsatz von 
\indit{ADPCM (Adaptive Differtial Pulse Code Modulation)} 
kann die ben"otigte Datenrate um den Faktor 3 reduziert werden.  Definition von
adaptiven Systemen siehe Seite \pageref{adaptiv}.  Digitale Telefonie wird mit
ADPCM (8 bit Qantit"atsstufe, 8 kHz Samplingrate) auf 24 kBit reduziert.
\item[MPEG Layer 3 Audio] Die MPEG Layer 3 Audio kompression verringert die
  benötigte Bandbreite für Audiodaten in CD-Qualität auf ein Zehntel. Dies wird 
  durch spezielle Algorithmen erreicht, die unhörbare Frequenzanteile aus dem
  Originalsignal herausfiltern. Diese Technologie entstand am Frauenhofer
  Institut für Informationssysteme.
\end{description}

\begin{tabular}{|p{40mm}|l|p{25mm}|l|}
\hline
\textbf{Datentyp} & \textbf{uncodiert} & \textbf{Codierung} & \textbf{codiert} \\
\hline
Digitale Telefonie: 8 kHz, 8 Bit Auflösung & 64 kBit/s & PCM & 64 kBit/s \\
Digitale Telefonie: 8 kHz, 8 Bit Auflösung & 64 kBit/s & ADPCM & 24 kBit/s \\
CD-Audio: 44,1 kHz, 16 Bit Auflösung & 1.411 kBit/s & PCM & 1,411 kBit/s \\
CD-Audio: 44,1 kHz, 16 Bit Auflösung & 1.411 kBit/s & MPEG Layer 3 Audio & 
128 kBit/s \\
Videodaten: PAL/NTSC & ca. 240 MBit/s & MPEG-1 (VCD) & 1,85 MBit/s \\
Videodaten: PAL/NTSC & ca. 240 MBit/s & MPEG-2 (DVD) & 4-10 MBit/s \\
\hline
\end{tabular}


\clearpage
\section{Effiziente Gruppenkommunikation}

Effiziente Gruppenkommunikation ben"otigt neben eindeutiger Sicherungs- und
Vermittlungsebenenfunktionalit"at (Schicht zwei und drei: Informationsverteilung,
Routing, Adressierung) auch Transportebenenfunktionen zur Ende-zu-Ende
Fluss - und Fehlerkontrolle (Layer vier: QoS-Unterst"utzung, 
Zugangskontrolle aufgrund von Anwendungsanforderungen, Ratenkontrolle) und
Gruppenmanagement und Synchronisationsfunktionen (oberhalb von Layer vier).

Zusammenfassend die wichtigsten Funktionen bei effizienter
Gruppenkommunikation:
\begin{itemize}
\item Sicherungsschicht: Adressierung, Routing, Bedienstrategien oder
Informationsverteilung
\item Transportschicht: adaptives Multicast-Transportprotokoll
(empf"angergesteuertes QoS-Konzept, Flusskontrolle, "Uberlastkontrolle
oder Fehlerkontrolle)
\item  Kommunikationssteuerungsschicht (Session-Layer):
Gruppenadress"=Verwaltung, Synchronisation
\end{itemize}
Diese Multifunktionalit"at wurde versuchsweise in einem einzelnen Protokoll
integriert. Doch war das HSTP, das Highspeed-Transport-Protokoll sehr
aufgebl"aht und nicht effizient zu  implementieren.

Deswegen wurden Anwendungen implementiert, die die an Multimediadienste
geforderten Funktionen als leichtgewichtige und adaptive Bausteine
integrieren. Diese Art von Anwendungen werden als \indbf{CSCW - Computer
Supported Cooperate Work} zusammengefasst.

Es gibt \textbf{asynchrone} Gruppenkommunikation 
(Verteilungsdienste, es m"ussen nicht s"amtliche Mitglieder zur 
gleichen Zeit aktiv sein) und \textbf{synchrone}
Dienste (Interaktive Dienste wie Videokonferenzen, wo alle Mitglieder
aktiv sein m"ussen). Bei der asynchronen Gruppenkommunikation er"ubrigt
sich daher Bereitstellung von Leistungsdiensten wie Bandbreitegarantie
o."a., da keine Isochronit"at der Daten gew"ahrleistet sein muss.

\clearpage
\section{Ausblick}
Für Ethernet wird derzeit eine QoS-Erweiterung (IEEE 802.1q) entwickelt. Da es
bisher nur propriätäre QoS-Standard für Ethernet existieren, ist dies ein
Hoffnungsträger für die Ethernet"=Welt. 

\subsection{Beispiele für Multimediaanwendungen}
\begin{enumerate}
\item Voice over IP
\item Medizin
\item Video on Demand
\item Telelearing
\item Whiteboarding
\item Spiele
\end{enumerate}




\clearpage
\printindex
\clearpage
\end{document}
