+ All Categories
Home > Documents > Multicast-Distribution-System MDiSwebdoc.gwdg.de/ebook/ah/dfn/mdis.pdfDFN-Projekt...

Multicast-Distribution-System MDiSwebdoc.gwdg.de/ebook/ah/dfn/mdis.pdfDFN-Projekt...

Date post: 25-Aug-2019
Category:
Upload: vannhan
View: 235 times
Download: 0 times
Share this document with a friend
44
DFN-Projekt Multicast-Distribution-System MDiS Abschluß bericht 15.2.2002 Erstellt durch: Deutscher Wetterdienst Kaiserleistr. 42 63067 Offenbach Herr Knottenberg Herr Kiehl Herr Lö ser Durchführung des Projektes in Zusammenarbeit mit: Tellique Kommunikationstechnik GmbH Berliner Straß e 26 D-13507 Berlin Universitä t Bremen Technologiezentrum Informatik Bereich Digitale Medien und Netze Bibliotheksstraß e, MZH 5180 D-28359 Bremen Das Vorhaben wurde aus Mitteln des Bundesministeriums f ü r Bildung, Wissenschaft, For- schung und Technologie (BMBF) durch den Verein zur F örderung eines Deutschen For- schungsnetzes e. V. (DFN-Verein) finanziert. PDF wurde mit FinePrint pdfFactory-Pr üfversion erstellt. http://www.context-gmbh.de
Transcript
  • DFN-ProjektMulticast-Distribution-System – MDiS

    Abschluß bericht

    15.2.2002

    Erstellt durch:Deutscher WetterdienstKaiserleistr. 4263067 Offenbach

    Herr KnottenbergHerr KiehlHerr Lö ser

    Durchführung des Projektes in Zusammenarbeit mit:TelliqueKommunikationstechnik GmbHBerliner Straße 26D-13507 Berlin

    Universität BremenTechnologiezentrum InformatikBereich Digitale Medien und NetzeBibliotheksstraße, MZH 5180D-28359 Bremen

    Das Vorhaben wurde aus Mitteln des Bundesministeriums fü r Bildung, Wissenschaft, For-schung und Technologie (BMBF) durch den Verein zur Förderung eines Deutschen For-schungsnetzes e. V. (DFN-Verein) finanziert.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 1

    1 INHALT

    1 INHALT ________________________________________________ 12 EINLEITUNG ____________________________________________ 32.1 PROBLEMSTELLUNG 32.2 ZIELSETZUNG 43 HINTERGRUNDINFORMATIONEN __________________________ 63.1 MULTICAST 63.1.1 Prinzip ______________________________________________ 63.1.2 Vorteile _____________________________________________ 73.1.3 Anwendungsgebiete ___________________________________ 8

    3.2 STANDARDISIERUNG 94 MULTICAST-DATEIVERTEILUNG Ü BER RDIST MIT MTP/SO____ 124.1 RDIST 124.2 DESIGN VON MDIST 144.2.1 Ü bertragung der Datei-Informationen _____________________ 144.2.2 Benö tigte Dateien der Server ___________________________ 154.2.3 Datenübertragung ____________________________________ 164.2.4 Verwendung von rdist zur abschließenden Fehlerbehebung ___ 164.2.5 Programmdokumentation zu mdist _______________________ 174.2.6 Protokollbeschreibung_________________________________ 174.2.7 Bewertung des Ergebnisses ____________________________ 18

    5 MULTICAST-DATEIVERTEILUNG DURCH tq®-TELLICAST ______ 195.1 PRODUKTAUFBAU tq®-TELLICAST 195.2 FUNKTIONSWEISE 205.2.1 Initialisierung / Announcements _________________________ 205.2.2 Ü bertragung ________________________________________ 20

    6 ANWENDUNGSFALL DWD _______________________________ 226.1 DATENVERTEILUNG IM DWD 226.1.1 Beteiligte Netzstrukturen_______________________________ 22

    6.1.1.1 Primärnetz _____________________________________________ 226.1.1.2 Sekundärnetz ___________________________________________ 22

    6.1.2 Datendistribution über AFD_____________________________ 236.1.3 ISDN-Failover _______________________________________ 24

    6.2 GEPLANTE DATENÜ BERTRAGUNG Ü BER MULTICAST 256.2.1 Vorgesehener Einsatzbereich___________________________ 256.2.2 Anforderungen ______________________________________ 26

    6.3 ZIELARCHITEKTUR 276.3.1 Integration von tq® -TELLICAST und AFD___________________ 276.3.2 Schnittstelle zur Datenübertragung: MD ___________________ 28

    6.3.2.1 Schnittstelle auf Senderseite _______________________________ 286.3.2.2 Schnittstelle auf Empfängerseite ____________________________ 29

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 2

    6.4 GESICHERTE DATENÜ BERTRAGUNG 306.4.1 Forward Error Correction ______________________________ 306.4.2 Negative Acknowledgements (NAK)______________________ 30

    6.4.2.1 Bandbreitenkontrolle für NAK_______________________________ 306.4.3 Steuerung von Retransmissions _________________________ 326.4.4 Realisierung des ISDN-Backups_________________________ 32

    6.5 BANDBREITENMANAGEMENT BEI MEHREREN SENDERN 336.6 SCHNITTSTELLE ZUM MDIS-GUI 346.7 REALISIERUNG IM RAHMEN DES PROJEKTES 356.7.1 Tests ______________________________________________ 356.7.2 Festlegung der Multicast-Channel _______________________ 35

    6.8 INBETRIEBNAHME 366.9 BEWERTUNG DES ERGEBNISSES 367 PROJEKTERGEBNIS ____________________________________ 388 ABKÜ RZUNGSVERZEICHNIS/GLOSSAR____________________ 409 ABBILDUNGSVERZEICHNIS ______________________________ 43

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 3

    2 EINLEITUNG

    2.1 PROBLEMSTELLUNGDurch die hohe Popularität des Internets, die steigende Bedeutung von In-formationsaustausch in der Wirtschaft und die Entwicklung bandbreitenin-tensiver Verfahren zur Ü bertragung von Multimediadaten ist die effektiveNutzung der vorhandenen Netzkapazitäten ein entscheidender wirtschaftli-cher und technischer Faktor.Multicasting, die simultane Datenübertragung an mehrere, ausgewählteEmpfänger, stellt daher auf Grund der resultierenden Bandbreiten- undKostenreduzierung eine Form des Internet-Datenaustausches dar, die im-mer mehr an Bedeutung gewinnt und zukünftig ein zentraler Service in derInternetlandschaft sein wird.Die notwendige Netzinfrastruktur zur Ü bertragung von Multicast-Paketenist derzeit bereits verfügbar und kann z. B. zur ungesicherten Ü bertragungvon Audio- oder Videodaten problemlos genutzt werden. Kern des Multi-cast-Backbones in Deutschland bildet dabei das Deutsche Wissenschafts-netz (WiN/B-WiN).Trotz der vorhandenen Infrastruktur und der vielfältigen Vorteile von Multi-cast – Verringerung der Netzlast, Reduzierung der Ü bertragungsverzö ge-rung und deutlich geringere Belastung der sendenden Rechner – nutzenbisher nur wenige Dienste die Ü bertragung von Dateien über Multicast.Grund dafür ist, dass die gesicherte Datenübertragung oberhalb des Best-Efford-IP-Dienstes immer noch sehr aufwendig ist.Die technische Grundlage für den Einsatz von Multicasting auf den Proto-kollebenen bis zur Vermittlungsschicht (ISO/OSI Ebene 3) ist heute schonvollständig gegeben. Auch ATM bietet mit Punkt-zu-Mehrpunkt-VCs dienotwendigen Voraussetzungen, um beispielsweise unterhalb der LAN-Emulation 1.0 grundlegende Multicast-Funktionalität zu realisieren. DerEinsatz von Multicast wird jedoch dadurch eingeschränkt, dass eine stan-dardisierte, universell verfügbare und problemlos benutzbare Transport-plattform für die gesicherte Ü bertragung von Daten über Multicast (ReliableMulticast) fehlt. Marktfähige Software für die gesicherte Ü bertragung vonDateien über Internet liegt nur begrenzt vor und weist oftmals erheblicheNachteile gegenüber den Unicast-Protokollen auf.Die in den USA gegründete IP Multicast Initiative, der auch Großunterneh-men wie Microsoft, Netscape und Cisco angehö ren, konzentriert ihre Akti-vitäten auf Gruppenkommunikation und die ungesicherte Ü bertragung vonAudio- und Videodaten. Innerhalb der IETF, dem Standardisierungs-„Gremium“ des Internets, werden zugleich in mehreren Arbeitsgruppen undin einer speziellen Researchgruppe (IRTF) gezielt Verfahren zur gesicher-ten Datenübertragung diskutiert. Ergebnisse dieser Gruppe oder gar ent-sprechende Internet-Standards kö nnen jedoch erst mittelfristig erwartetwerden.Bisher steht Anwendungen, die von den Vorteilen einer Multicast-Ü bertragung profitieren wollen, als standardisiertes Transportprotokoll der

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 4

    Schicht 4 nur UDP mit der von ihm angebotenen ungesicherten Ü bertra-gung von Datagrammen zur Verfügung. Viele Anwendungen sind aller-dings darauf angewiesen, dass die gesendeten Daten lückenlos bei denEmpfängern ankommen. Dies hat zur Entwicklung von spezialisierten Pro-tokollen, aufbauend auf UDP, geführt, die die Dienste von UDP entspre-chend anwendungsspezifisch erweitern. Die Protokollentwicklung ist jedochaufwendig und gerade für komplexe Mehrpunktsituationen einer kleinenGruppe von Spezialisten vorbehalten. So muss bei der Entwicklung vielerAnwendungen heute noch auf die Verwendung von mehreren Punkt-zu-Punkt-Verbindungen („TCP-Fanouts“) zurückgegriffen werden.Auf dieser Basis ist bisher nur eine sehr begrenzte Anzahl an kommerziel-len Produkten zur gesicherten Multicastübertragung entwickelt worden. Zunennen wären hier die Produkte der Firmen Kencast, The Fantastic Corpo-ration, Deuromedia und Starlight Networks. Aber auch diese Produkte bie-ten nur einen Bruchteil des für den universellen Einsatz von Multicasterforderlichen Funktionsumfanges und erfordern eine spezielle Implemen-tierung auf die Gegebenheiten des jeweiligen Anwenders. So ist der Ein-satz von IP-Multicast zur gesicherten Datenübertragung für eine sehr breiteGruppe an potentiellen Anwendern nur über Eigenentwicklung mö glich.

    2.2 ZIELSETZUNGAls Pilotprojekt für die allgemeine Nutzung von gesicherter Datenübertra-gung über Multicast wird im Rahmen des Projektes MDiS durch die FirmaTellique Kommunikationstechnik GmbH und das Technologiezentrum In-formatik der Universität Bremen eine Plattform zur Verfügung gestellt, diefür verschiedenartige Anwendungen den Einsatz von zuverlässiger Multi-cast-Datenübertragung ermö glicht. Kern der Plattform ist das von der Telli-que Kommunikationstechnik GmbH entwickelte MulticasttransportprotokollMTP/SO. MTP/SO entspricht den Empfehlungen des Internet RFC 1301und stellt quasi ein TCP-Pendant für Mehrpunktkommunikation dar.Im Rahmen von MDiS werden zwei Mö glichkeiten des Einsatzes vonMTP/SO demonstriert, die beide als Beispielanwendung die Distributionvon Dateien zum Ziel haben:

    • Entwicklung von mdistEines der unter Unix am häufigsten verwendeten Unicast-Dateiverteilsysteme ist rdist. Im Rahmen von MDiS wird rdist als Basisfür die Entwicklung eines Multicast-Dateiverteilsystem unter Nutzungvon MTP/SO verwendet. Damit wird ein Tool erstellt, durch dass sichMTP/SO einfach in bestehende, bewährte Systeme integrieren lässt.Nutzer von rdist kö nnen ohne Ä nderung ihrer bestehenden Systemkon-figuration Multicast nutzen.

    • Piloteinsatz beim DWDFür den Piloteinsatz beim DWD wird zur Dateiverteilung die von Telli-que auf Basis von MTP/SO entwickelte Datendistributionssoftware tq® -TELLICAST verwendet. Ü ber tq® -TELLICAST werden zusätzliche Servi-cefunktionen zur Verfügung gestellt, die eine Einbindung in Datendistri-butionssysteme wie das AFD des Deutschen Wetterdienstesentscheidend erleichtern und zudem über Kompression, Verschlüsse-lung etc. die zentralen Vorteile von Multicast intensivieren.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 5

    Die aktuelle Implementierung von tq® -TELLICAST FileBroadcast wirdvon Tellique im Rahmen des Projektes in erweiterter Form bereitgestelltund zusätzlich den Einrichtungen des DFN-Vereins zur wissenschaftli-chen Nutzung auf der Infrastruktur des Deutschen Wissenschaftsnet-zes zur Verfügung gestellt. Auf Basis von tq® -TELLICAST wird durch dasProjekt eine Plattform für Dateiübertragung als Beispielanwendungentwickelt, die es erlaubt, Dateigruppen automatisiert auf prinzipiell be-liebig viele Empfängersysteme zu replizieren. Diese Plattform wird vom Deutschen Wetterdienst (DWD) als Pilotnut-zer im Rahmen von MDiS erprobt. Dazu wird das entwickelte Multicast-Distributions-System in die zentrale Infrastruktur des DWD eingebun-den. Ziel ist unter anderem die Ü bertragung von im MeteorologischenRechenzentrum in Offenbach erstellten Modelloutputs (Vorhersageda-ten in hoher Auflö sung) an 6 dezentrale Niederlassungen mit Regional-zentrale sowie in einem späteren Stadium die Verteilung von kleinerenDatenbeständen an ca. 50 weitere Niederlassungen des DWD. DieDatenraten für die Verteilung an die dezentralen Niederlassungen in-nerhalb des Primärnetzes sollen dabei auf einen wesentlichen Teil derderzeit zur Verfügung stehenden 34 Mbit/s ansteigen. Angesteuert wirddiese Ü bertragung durch das bereits bestehende Automated File Distri-butor (AFD) des DWD.

    Pilotnutzer im Projekt ist der DWD, langfristig wird jedoch eine universelle-re Nutzung von reliable Multicast in den Netzen des DFN-Vereins ange-strebt. Die Tellique Kommunikationstechnik GmbH und dasTechnologiezentrum Informatik der Universität Bremen kö nnen durch ihrebisherige direkte Mitarbeit in den Gremien des IETF dafür garantieren,dass deren derzeitige Forschungsergebnisse in das Design des beim DWDim MDiS-Projekt zu implementierenden Multicast-Systems einfließen. Es istweiterhin anzustreben, die Ergebnisse des für den DWD durchgeführtenProjektes auch in die Standardisierung einzubringen und damit zur weite-ren universellen Verbreitung von Multicast in der gesicherten Datenüber-tragung beizutragen.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 6

    3 HINTERGRUNDINFORMATIONEN

    3.1 MULTICAST

    3.1.1 PrinzipMulticast ist die simultane Verteilung von Daten von einem Sender an meh-rere definierte Empfänger. Die Daten brauchen dabei nicht an jeden Emp-fänger einzeln verschickt zu werden, sondern werden nur einmal in dasNetz „eingestellt“. Netzkomponenten, wie beispielsweise Router, leiten dieDaten an alle Empfänger weiter. Dabei leitet bei Bedarf ein Router bei-spielsweise Kopien eines eingehenden Paketes auf mehreren anderen In-terfaces („in verschiedene Richtungen“) weiter. Auf den einzelnenÜ bertragungsstrecken werden die Pakete unabhängig von der Empfänger-anzahl daher nur einmal übertragen (sofern keine Paketverluste auftreten).Dadurch wird die Netzauslastung, aber auch die Belastung des sendendenServers (der sonst so viele Kopien versenden müsste, wie es Empfängergibt) vermindert.

    1

    11

    222

    345

    34

    34

    34

    Unicast-Verteilung von einem Sender an 5 Empfä nger

    Sender4

    3

    2

    1

    4

    1

    1

    2

    1

    23

    1

    2

    4

    3

    3

    4

    2

    5

    4

    3

    5

    3

    4

    M

    Multicast-Verteilung von einem Sender an 5 Empfä nger

    Sender

    5

    4

    3

    2

    1

    M

    M

    M

    M

    M

    M

    M

    M

    M

    M

    M

    M

    MM

    MM

    M

    M

    M

    Abbildung 1: Unicast und Multicast im Vergleich

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 7

    Ein Endpunkt kann auf einer speziellen Multicastadresse Daten empfangenund senden. Hierfür ist im IP-Adressraum der Nummernraum 224.0.0.0 bis239.255.255.255 vorgesehen („Klasse-D-Adressen“). Daten, die an eineMulticast-Adresse gesendet werden, werden von allen Rechnern empfan-gen, die auf dieser Adresse Daten empfangen wollen.Häufig wird bei Multicast UDP als Transportprotokoll eingesetzt. TCP ist alsTransportprotokoll für Multicast-Anwendungen nicht geeignet, da die Pro-tokollmechanismen (z.B. die für Verbindungsauf- und -abbau und fürEmpfangsbestätigungen) eine einfache Zweierbeziehung voraussetzen.Eine typische Multicast-Anwendung ist z.B. die Ü bertragung von Audio-und Videoinformationen; hier wird auch im Unicast-Fall UDP eingesetzt.Bei der Verteilung von Daten, bei denen es nicht auf die Echtzeitfähigkeitankommt, sondern auf dem Empfang aller Daten in der richtigen Reihen-folge, muss ein anderes Transportprotokoll als UDP eingesetzt werden (o-der auch der Dienst von UDP, Fehlererkennung undAnwendungsadressierung, durch ein weiteres Protokoll ergänzt werden).Hierfür kann das Multicast-Transportprotokoll MTP/SO verwendet werden.Bei MTP/SO gibt es einen Master, der steuert, wann welcher Sender Datensenden darf. Empfängt der Master ein Paket, so gilt es als allgemein emp-fangen. Empfänger, die die Daten nicht erhalten haben kö nnen bei ande-ren Kommunikationspartnern diese Daten erneut anfordern. DurchSteuerpakete vom Master ist genau festgelegt, in welcher Reihenfolge Pa-kete an die einzelnen bei den Kommunikationspartnern laufenden Anwen-dungen ausgeliefert werden dürfen.

    3.1.2 VorteileDurch die Nutzung von Multicast ergeben sich unter anderem die folgen-den Vorteile:

    • Verringerung der Netzlast und damit insbesondere im Weitverkehrsbe-reich oftmals erhebliche Einsparungen sowohl für die Anwender alsauch für die Netzbetreiber.

    • Deutliche Verringerung der Ü bertragungsverzö gerung, da die Datennur einmal übertragen werden, während der Sender bei Unicast-Ü bertragungen die Daten hintereinander an die einzelnen Empfängersenden müsste.

    • Reduzierte Belastung der sendenden Rechner. Da die Daten nur ein-fach auszusenden sind, kann ein Rechner simultan auch Tausende vonEmpfängern erreichen – oftmals wird so eine breitbandige Versorgunggroßer Ü bertragungsgruppen überhaupt erst mö glich.

    Multicast entwickelt sich durch diese Vorteile zu einer Schlüsseltechnologiefür die Datenübertragung des beginnenden 21. Jahrhunderts.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 8

    3.1.3 AnwendungsgebieteDie mö glichen Anwendungsgebiete sind vielfältig und beinhalten z. B.

    • Versorgung verteilter Organisationen mit aktuellen Informationsbestän-den

    • Realisierung von verteilten/replizierten Datenbanken

    • Verteilte/replizierte Dateisysteme

    • Softwareverteilung/Softwareupdates

    • Groupware, Shared Applications, Audio-/Video-Konferenzen

    • Ü bertragung von Daten vom „Information Service Provider“ an Abon-nenten

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 9

    3.2 STANDARDISIERUNGDie massenhafte Verbreitung von Reliable-Multicast-Anwendungen im In-ternet setzt neben einer Multicast-Infrastruktur standardisierte Protokollevoraus. Dabei sind Normen vor allem in zwei Bereichen erforderlich:

    • Transportprotokolle für Reliable Multicast

    • Geeignete Sicherheitsstandards für große GruppenIn beiden Bereichen stellte sich Mitte der 1990er Jahre schnell heraus, daßvor Beginn einer Standardisierung zunächst offene Forschungsfragen zulö sen waren. Die Aktivitäten wurden daher nicht sofort in die IETF getra-gen, sondern erst einmal in der Internet Research Task Force (IRTF) bear-beitet, bis sich jeweils so etwas wie ein Grundkonsens herausschälte.Abbildung [[[2]]] zeigt dies im Ü berblick.Die Arbeiten im Bereich des Transportprotokolls in der IRTF bezogen sichzunächst auf die Entwicklung einer gemeinsamen Taxonomie, um über-haupt einmal der mö glichen Vielfalt der Protokolle Herr zu werden. Späterkonzentrierte sich die Reliable Multicast Research Group (RMRG) auf fürdie Staukontrolle (congestion control) von Multicast-Strö men geeigneteVerfahren sowie die Mindestanforderungen, die an solche Verfahren zustellen sind (Fairness).

    MSECuTake up and standardize SMUG work

    SMUGuSecurity setup (LKH)–GDOI–GSAKMPuSource authentication

    Multicast Security

    RMTubulk data transfer– unidirectional– bidirectionalt NORMt TRACK

    RMRGuearly workucongestion control

    Reliable Multicast

    IETFIRTF

    MSECuTake up and standardize SMUG work

    SMUGuSecurity setup (LKH)–GDOI–GSAKMPuSource authentication

    Multicast Security

    RMTubulk data transfer– unidirectional– bidirectionalt NORMt TRACK

    RMRGuearly workucongestion control

    Reliable Multicast

    IETFIRTF

    Abbildung 2: IRTF- und IETF-Aktivitäten in Transport und Security

    Diese Arbeiten waren Ende 1999 so weit fortgeschritten, dass am16.12.1999 die reliable multicast transport WG (RMT) in der IETF einge-richtet werden konnte. Dieser Arbeitsgruppe wurde jedoch eine klare Be-schränkung auf den Bereich des Massendatentransports (bulk transfer) mitauf den Weg gegeben, da man die Lö sung des Staukontrollproblems fürden allgemeineren Fall noch nicht absehen konnte. Damit konnte diese

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 10

    Arbeitsgruppe mit ihren Protokollen nicht den Grad an Flexibilität erreichen,den MTP/SO auszeichnet.RMT entschied sich wegen der immer noch hohen Zahl von mö glichentechnischen Alternativen nach einiger Diskussion dafür, die grundlegendenMechanismen der Protokolle in Form von Building Blocks (BBs) zu entwi-ckeln, von denen dann mehrere in Protocol Instantiations (PIs) referenziertund zu einem konkreten Protokoll ausentwickelt werden sollen.

    uTFMCCuPGMCC

    uLCCCongestion Control

    uGRAu(GRA for CC?)Router Assist

    uNORM –(FEC, NORM)uTRACK –(FEC, NORM, TREE)

    uALC (LCT)Protocols (PIs)

    uFECuNORMuTREE

    uFECuLCT

    Protocol BBs

    Two-wayOne-way

    uTFMCCuPGMCC

    uLCCCongestion Control

    uGRAu(GRA for CC?)Router Assist

    uNORM –(FEC, NORM)uTRACK –(FEC, NORM, TREE)

    uALC (LCT)Protocols (PIs)

    uFECuNORMuTREE

    uFECuLCT

    Protocol BBs

    Two-wayOne-way

    Abbildung 3: Das Arbeitsprogramm der IETF-Arbeitsgruppe RMTDie Arbeiten der RMT-Gruppe spalteten sich schnell in eine auf Einweg-kommunikation basierende Vorgehensweise (Digital-Fountain-Modell – eswird kontinuierlich gesendet, Empfänger kö nnen jederzeit beginnen zuempfangen, bis sie genug Bits haben, um den Inhalt zu rekonstruieren)und eine klassischere auf Zweiwegkommunikation basierende Vorgehens-weise. Da für erstere noch nicht so viele technisch sinnvolle Protokolle aufdem Markt sind, konnte das Unternehmen Digital Fountain recht schnellEinigung über diese Protokolle erzielen; dementsprechend sind die Doku-mente heute (Anfang 2002) bereits in der Nähe des Working Group LastCall.

    Komplexer ist die Situation in der Zweiwegkommunikation. Hier muß zu-nächst zwischen der klassischen gruppenorientierten Kommunikation mitnegativen Bestätigungen (NACK-Oriented Reliable Multicast, NORM) undkomplexeren auf positiven Bestätigungen beruhenden baumbasierten An-sätzen (Tree-based ACK, TRACK) unterschieden werden. Nach extensiverDiskussion wurde klar, daß die TRACK-Lö sung eine Obermenge derNORM-Lö sung werden sollte. Drafts für beide Normen liegen vor, bedürfenaber noch weiterer Ü berarbeitung.Eine weitere Schwierigkeit liegt in den Staukontrollalgorithmen für denZweiwegefall. Neben dem in der RMRG entwickelten TCP-friendly multi-cast congestion control (TFMCC) trat mit der SIGCOMM 2000 PGMCC aufden Plan, eine schneller reagierende Variante der TFMCC-Grundidee, dieaber entsprechend auch hö here Fluktuationen in der Datenrate mit sichbringt.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 11

    Zusammenfassend lässt sich sagen, dass (Stand Anfang 2002) eine Normfür den Zweiwegfall noch nicht absehbar ist. Wegen der schwierigen wirt-schaftlichen Situation und der allgemeinen Desillusionierung bezüglich ei-nes mö glichen Internet-weiten Einsatzes von Multicast-Technologien wirddie Normung gegenwärtig auf kleiner Flamme vorangetrieben. Für die ab-sehbare Zukunft ist das auf RFC1301 basierende Protokoll MTP/SO des-wegen auch weiterhin als lebensfähige Grundlage für die Entwicklung vonProdukten im Bereich der Zweiwege-Multicastkommunikation anzusehen.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 12

    4 MULTICAST-DATEIVERTEILUNG Ü BER RDIST MIT MTP/SO

    Dieser Abschnitt beschreibt die Entwicklung eines Programms für die Ver-teilung von Daten per Multicast.Es wäre ein einfaches Vorhaben gewesen, auf der Basis des ja bereitsrecht leistungsfähigen Multicast-Transportprotokolls MTP/SO eine simpleDateiverteilanwendung zu entwickeln. Es bietet sich aber an, Dateivertei-lung per Multicast genau dort zu verwenden, wo bereits heute Dateivertei-lung per Unicast im Einsatz ist. Das heute am häufigsten verwendeteProgramm für diesen Zweck ist das Programm rdist. Als Namen für dieseszu entwickelnde Programm wählen wir mdist, da mdist auf dem Quelltextvon rdist basiert.Im folgenden wird zunächst das Programm rdist beschrieben, welches alsBasis für mdist verwendet wird. Daran anschließend erfolgt die Beschrei-bung des Programms mdist, dass über MTP/SO auf Grundlage von rdistdie Verteilung von Dateien realisiert.

    4.1 RDISTRdist wurde im Zusammenhang mit 4.3BSD entwickelt und ist deswegen inseiner ursprünglichen Form Bestandteil fast aller modernen UNIX-Systeme. Diese „klassische“ Variante von rdist hat allerdings einigeschwerwiegende Mängel, so dass heute meist eine stark verbesserte Ver-sion im Einsatz ist.Basis dieses Projektes zur Verteilung von Daten über Multicast ist dasProgramm rdist in der Version 6.1.5. Das Programm dient zur automati-sierten Verteilung von Daten eines Quellrechners an mehrere Zielrechner.In einer Konfigurationsdatei kö nnen die Dateien, auch ganze Verzeichnis-se, angegeben werden, die über das Netz verteilt werden sollen. Hierbeikö nnen auch Abweichungen auf den einzelnen Zielrechnern mit angege-ben werden, wie z.B. ein anderes Zielverzeichnis oder das Ü berspringenbestimmter Dateien oder Verzeichnisse. Zusätzlich kann noch angegebenwerden, ob neuere Dateien auf dem Zielrechner überschrieben und aufdem Quellrechner nicht mehr vorhandene Dateien auf dem Zielrechnergelö scht werden sollen.Eine weitere wichtige Funktion von rdist ist das Ausführen von Program-men auf den Zielrechnern nach erfolgreicher Verteilung. Bei Verteilung vonProgrammen und Bibliotheken eines Linux-Systems kann mit dieser Funk-tion beispielsweise hinterher automatisch die Bibliotheken-Datenbank mitdem Aufruf ldconfig auf den aktuellen Stand gebracht werden.Die Komplexität der Funktionalität von rdist spiegelt sich in der Konfigurati-onsdatei, dem Verteilungsmechanismus und dem Programmquelltext wi-der. An vielen Stellen sind Fallunterscheidungen und Funktionen mitAusnahmeregelungen zu finden.Beim Start des Programms werden rdist, die Konfigurationsdatei und e-ventuelle Ä nderungen zu dieser auf der Kommandozeile übergeben. DieKonfigurationsdatei wird mit einem mit Hilfe des Parser-Generators yacc(bzw. heute meist bison) erzeugten Parser in eine C-Datenstruktur übertra-

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 13

    gen. Diese Datenstruktur wird nun weiter in die Befehle jedes Kommandosfür jeden einzelnen Zielrechner zerlegt, immer unter Berücksichtigung derper Kommandozeile übergeben Ä nderungen. Am Ende dieser Verfeinerungsteht eine Funktion, die genau ein Kommando auf einem Zielrechner aus-führt.Das Programm startet nun für jeden Zielrechner einen eigenen KindPro-zess1, der einen Server2 auf dem ihm zugewiesenen Zielrechner startet.Diese beiden Prozesse auf Quell- und Zielrechner tauschen nun Informati-onen und Daten für das jeweils zu bearbeitende Kommando aus.Der Prozess auf dem Quellrechner überprüft anhand der Konfiguration, wiedie Datei auf dem Zielrechner heißen soll und fordert Informationen überdiese Datei an. Anhand dieser Informationen wird entschieden, ob die Da-tei übertragen werden muss oder nicht. Die Entscheidung, ob die Datei ü-bertragen wird oder nicht, liegt beim Zielrechner, denn nur der rdist-Prozess auf dem Quellrechner weiß, ob neuere Versionen auf dem Ziel-rechner durch die Version auf dem Quellrechner überschrieben werdensollen.Falls es sich bei dem Gegenstand der Verteilung um ein Verzeichnis han-delt, wird anhand des Ä nderungsdatums überprüft, ob sich neuere Dateienin dem Verzeichnis befinden. Ist das Verzeichnis geändert worden, gehtrdist rekursiv alle Dateien innerhalb dieses Verzeichnisses durch und über-prüft wieder jede einzelne Datei.Dieser Informationsaustausch ist durch ein auf ASCII basierendes Protokollrealisiert. Als Verbindung zwischen den Prozessen wird die Standardein-und -ausgabe verwendet. Ein Kommando besteht aus genau einer Zeile,die mit einem Code für die Art des Kommandos beginnt. Danach schicktder Server entweder eine positive (ACK) oder negative (REJ) Bestätigungoder angeforderte Informationen.Entscheidet der Client, dass die Datei übertragen werden muss, so teilt eres dem Server mit und startet die Dateiübertragung.Ist ein Kommando komplett abgearbeitet, überprüft der Client, ob noch an-dere Kommandos für diesen Server vorliegen. Ist dies der Fall, werdendiese Kommandos ebenfalls von diesem Client-Server-Paar bearbeitet.Ein großer Nachteil dieses von rdist verwendeten Dateiverteilverfahrens ist,dass für jeden Rechner die Datei separat auf dem Netz übertragen wird.Dieser Nachteil motiviert die Entwicklung eines auf Multicast basierendesProgramms zur Dateiverteilung.

    1 Dieser KindProzess auf dem Quellrechner wird im folgenden Client genannt.2 Der Server auf dem Zielrechner ist der rdist-Daemon rdistd.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 14

    4.2 DESIGN VON MDISTUm die Funktionalität von rdist mö glichst weitgehend zu erhalten, wurdennur wenige Ä nderungen am Original-Quelltext vorgenommen. Stattdessenwurden separate C-Module entwickelt, die spezielle Einsprungpunkte fürdie veränderte Aufgabe von mdist enthalten. Ü ber das Setzen einer Vari-able wird der mdist-Teil im Programm aktiv. Durch diese „minimal invasive“Vorgehensweise kann mdist relativ leicht an eine neue Version von rdistangepaßt werden, sollte der Autor eine überarbeitete Version verö ffentli-chen3.Ein Hauptproblem war, die Punkte im Quelltext zu finden, an denen mdist-spezifische Funktionalität statt des bestehenden rdist-Codes ausgeführtwerden muss. Das Programm rdist ist stark auf die Unterschiedlichkeit derZielrechner ausgerichtet. Ein Client überträgt alle jeweils für ein spezifi-sches Ziel erforderlichen Daten. Bei Multicast sind aber die einzelnen Ziel-rechner bei der Datenübertragung nicht unterscheidbar, jeder empfängt dieDaten und muss selbständig entscheiden, ob es sie annehmen muss odernicht. Daher wurden zwei grundlegende Design-Ä nderungen vorgenom-men:

    • Die Intelligenz, welche Daten übertragen werden müssen, wurdevom Client zum Server verlagert. Hierzu benö tigt der Server Infor-mationen über die Kommandos, die Ausnahmeregelungen, Namenauf dem Quell- und Zielrechner und die Parameter auf der Kom-mandozeile für eventuelle Ä nderungen.

    • Die Ü bertragung der Daten wird komplett am Ende durchgeführt,nachdem alle Server ihre Liste der Kommandos erhalten haben.

    Kurz bevor die Aushandlung beginnt, welche Daten übertragen werdensollen, wird in den mdist-Teil des Programmes gesprungen. Statt mit demZielrechner jede einzelne Datei auszuhandeln und dann gleich zu übertra-gen, werden dem mdist-Prozess auf dem Zielrechner die Konfigurations-informationen über diese Aufgabe übermittelt. Dann wird diese Aufgabeunterbrochen und die Konfigurationsdatei weiter bearbeitet.Ist die Konfigurationsdatei komplett abgearbeitet worden, beginnt die Aus-handlung, welche Daten übertragen werden sollen und danach die eigentli-che Ü bertragung. Der Multicast-Teil von mdist besteht aus drei Phasen: dieÜ bertragung der Dateiinformationen vom Client an den Server, die Antwortder Server mit der Liste der von ihnen benö tigten Dateien und die eigentli-che Datenübertragung aller benö tigten Dateien vom Client zu den Servern.

    4.2.1 Ü bertragung der Datei-InformationenDer Client ermittelt eine Liste aller in der Konfiguration angegeben Dateienund Verzeichnisse. Die Liste besteht nur aus den Namen der Dateien aufdem Quellrechner; die Umsetzung auf die Dateinamen auf den Zielrech-

    3 Dies ist natürlich nur in begrenztem Umfang m ö glich. Substantielle Ä nderungen am Design von rdist erfordernwahrscheinlich ebenfalls eine Ü berarbeitung von mdist, da mdist auf die internen Datenstrukturen von rdist zu-rückgreift. Glücklicherweise kann rdist heute als weitgehend stabiles Programm angesehen werden.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 15

    nern kö nnen diese anhand der per Unicast ausgetauschten Informationenselbständig ermitteln.Zu jeder Datei und jedem Verzeichnis werden folgende Daten ermittelt undübertragen:

    • Name auf dem Quellrechner

    • Typ: Verzeichnis, Link oder reguläre Datei

    • Dateigrö ße

    • Ä nderungsdatum

    • Rechte

    • Besitzer, sowohl der Name als auch die systeminterne Kennziffer(UID)

    • Gruppe, ebenfalls der Name und die KennzifferDie Ü bertragung der Namen und Kennziffern bei Besitzer und Gruppe sindnö tig, da unter Umständen bei einigen Zielrechnern die Kennziffer und beianderen der Name erhalten bleiben soll, falls diese auf dem Zielsystemnicht übereinstimmen.Auf Serverseite werden diese Informationen der anfangs übertragenenKonfiguration zugeordnet bzw. verworfen, wenn die Datei auf diesem Ser-ver nicht benö tigt wird. Auf dem Server nicht existierende Verzeichnissewerden in diesem Schritt angelegt, da an dieser Stelle schon alle relevan-ten Informationen ausgetauscht wurden.Rdist ist in der Lage, Softlinks bei der Ü bertragung aufzulö sen. Dadurchkö nnen Softlinks, die auf Dateien verweisen, die außerhalb des zu vertei-lenden Verzeichnisses liegen, ebenfalls mit übertragen werden. Es mussallerdings darauf geachtet werden, dass durch die Softlinks keine Schleifenbei Verweisen auf Verzeichnisse entstehen. Diese Funktionalität ist inmdist nicht mehr vorhanden. Dies ergibt sich aus dieser Art des Informati-onsaustauschs. Bei der Ü bertragung dieser Informationen werden erst alleDateien an alle Server geschickt, bevor diese antworten, da es ansonstenzu unnö tigen Verzö gerungen kommt, wenn erst alle Antworten jeder Dateiabgewartet werden müssen. Um Schleifen bei Softlinks auf Verzeichnissezu vermeiden und da es unter Umständen sowohl Server gibt, die Softlinksaufgelö st haben wollen als auch solche, für die dies nicht vorgenommenwerden soll, wurde auf diese nicht sehr oft benö tigte Funktionalität ver-zichtet, da sie das Protokoll sehr verkompliziert und verlangsamt hätte.

    4.2.2 Benö tigte Dateien der ServerNach der Ü bertragung aller Dateiinformationen wird der Server aktiv undmuss die Liste der von ihm benö tigten Dateien zurückschicken. Anhandder Konfiguration und der mö glichen Dateinamen des Quellrechners wer-den die aus Sicht der Zielrechner zu verwendenden Dateinamen ermittelt4.

    4 Je nach Komplexität der Konfiguration kann eine Datei des Quellrechners an mehreren Stellen beimZiel zu speichern sein.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 16

    Nachdem diese Zuordnung durchgeführt ist, wird ermittelt, ob diese Dateineu übertragen werden muss. Hierbei werden vier Ü berprüfungen durch-geführt:Die Konfiguration kann eine Liste von auszuschließenden Dateien und re-gulären Ausdrücken über den Dateinamen enthalten. Ist der Dateiname indieser Liste, dann wird keine weitere Ü berprüfung durchgeführt, sonderndie Datei als nicht benö tigt markiert.Handelt es sich um ein Verzeichnis, das noch nicht existiert, so wird derDateiname in die Liste der anzufordernden Dateien aufgenommen. DerClient weiß bei Anforderung eines Verzeichnisses, dass er alle Dateien undUnterverzeichnisse dieses Verzeichnisses ebenfalls übertragen muss.Ist die Datei innerhalb eines noch nicht existierenden Verzeichnisses oderist sie die selbe Quelldatei wie eine schon als benö tigt markierte Datei, sowird die Datei in die Liste der zu übertragenen Dateien aufgenommen, abernicht in die Liste der Anforderungen, die an den Client geschickt werden.Schließlich werden die weiteren Informationen über die Quell- und die Ziel-datei ausgewertet. Hierzu werden Grö ße, Ä nderungsdatum und die Optio-nen der Konfiguration überprüft. Falls die Datei übertragen werden muss,wird sie in die Liste der benö tigten und anzufordernden Dateien aufge-nommen.Die so erstellte Liste der Dateien und Verzeichnisse des Clients wird nunan diesen zurückgesendet und die eigentliche Datenübertragung kannstarten.

    4.2.3 Datenü bertragungNachdem alle Server die Liste der von ihnen benö tigten Dateien übertra-gen haben, beginnt die Ü bertragung aller benö tigten Dateien selbst. AmAnfang wird der Dateiname auf dem Quellrechner und die Grö ße übertra-gen. Danach wird diese Datei übertragen und dann die nächste Datei be-arbeitet.Jeder Zielrechner empfängt alle Dateien. Er muss dann selbständig ent-scheiden, ob er sie speichern muss oder nicht. Die Informationen über dieRechte, die diese Datei bekommt, erhält der Server aus den Informationen,die in Phase 1 ausgetauscht wurden.

    4.2.4 Verwendung von rdist zur abschließ enden FehlerbehebungWährend der Multicast-Ü bertragung kann durch längere Ausfälle der Multi-cast-Konnektivität der Fall auftreten, dass ein oder mehrere Zielrechner dieÜ bertragung nicht komplett erhalten. Sie ziehen sich bei Problemen ausder Multicast-Ü bertragung zurück und melden dem Client, dass sie dieDaten nicht empfangen kö nnen.Nachdem die Multicast-Ü bertragung abgeschlossen ist, wird die Variable,die den mdist-Teil des Programms aktiviert, auf die Verwendung des rdist-Protokolls zurückgesetzt. Danach wird das Programm mit den nicht abge-schlossenen Operationen als rdist noch einmal gestartet; damit werden et-waige Lücken der Multicast-Ü bertragung automatisch behoben.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 17

    4.2.5 Programmdokumentation zu mdistDer mdist-Teil des Programms besteht aus vier C-Modulen: mtp, mclient,mserver und mparser.Der mtp-Teil sorgt für die Multicast-Ü bertragung auf Basis der Bibliothekmtpso. Er enthält Hilfsfunktionen für die Initialisierung eines mtpso-Multicast-Sockets und für das Senden und Empfangen von Daten. DieseFunktionen werden vom mserver und dem mclient verwendet.Die Module mclient und mserver enthalten den eigentlichen mdist-Teil desProgramms. Sie enthalten die Funktionen, die vom Original-rdist ange-sprungen werden. Für die Parsierung der Datenströ me für den Informati-onsaustausch wird das Objekt mparser verwendet. Es enthält Funktionen,um interne Datenstrukturen in Zeichenketten und zurück zu übersetzen.

    4.2.6 ProtokollbeschreibungDie Unicast- und die verschiedenen Phasen der Multicast-Ü bertragung set-zen verschiedene Protokolle für die Datenübertragung ein. Die Ü bertra-gung der Konfiguration und der Dateiinformationen ist ein auf ASCIIaufsetzendes, zeilenorientiertes Protokoll. Die verschiedenen Informatio-nen werden durch Leerzeichen getrennt, Zahlen in menschenlesbarerForm übertragen. Zeichenketten, die wiederum Leerzeichen enthalten kö n-nen, enthalten eine zusätzliche Längenangabe, um sie wieder korrekt ext-rahieren zu kö nnen.Jede Zeichenkette beginnt wie bei rdist auch mit einem Zeichen, welchesdie Art der Zeile beschreibt. Die einzelnen Codes sind in der nachfolgen-den Tabelle aufgelistet.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 18

    4.2.7 Bewertung des ErgebnissesMdist ist ein auf der Basis von rdist entwickeltes System zur Dateiverteilungper Multicast. Der Ansatz, nicht ein vö llig neues Tool zu entwickeln, son-dern auf rdist einzusetzen, bietet Anwendern von rdist eine sehr einfacheMigrationsstrategie in Richtung Nutzung von Multicast zur Dateiverteilung.Projekte, die z.B. im Wissenschaftsnetz des DFN grö ßere Dateien regel-mäßig verteilen wollen, erhalten mit mdist ein Tool, das die benö tigtenBandbreiten deutlich reduzieren kann.Rdist ist natürlich nicht das einzige Tool zur Dateiverteilung, das als Basisfür die Entwicklung von mdist hätte dienen kö nnen. Ein anderes heute weitverbreitetes Programm zur Dateiübertragung ist rsync. Statt rdist hätteauch rsync auf Multicast-Verteilung angepaßt werden kö nnen. Im Gegen-satz zu rdist ist rsync aber allein auf die Verteilung ausgerichtet und hatweniger Sonderfunktionen für den Einsatz in grö ßeren Netzen; so kannrsync beispielsweise nach erfolgreicher Verteilung nicht Programme zurendgültigen Installation der verteilten Dateien ausführen. Die grundsätzli-che Idee von rsync, durch Ü berprüfung partieller Prüfsummen der Dateiin-halte Ü bertragungskapazität einzusparen (Tridgell, A. and Mackerras, P.,„The rsync algorithm“. Technical Report TR-CS-96-05, Dept. ComputerScience, ANU, 1996), bietet im Multicast-Fall auch weniger Vorteile.Die Entscheidung, rdist als Basis für das Programm mdist zu verwenden,ist jedoch nicht nur mit Vorteilen verbunden. Einerseits wird in vielen Infra-strukturen heute rdist eingesetzt und dementsprechend ist in vielen Orga-nisationen signifikanter Aufwand investiert worden in die Entwicklung vonrdist-Konfigurationsdateien, die nun mit mdist einfach unverändert über-nommen werden kö nnen. Die Funktionsvielfalt von rdist macht auch mdistzu einem mächtigen Werkzeug für die Verteilung von Daten.Diese Funktionsvielfalt und die damit einhergehende Komplexität ist ande-rerseits auch einer der grö ßten Nachteile des entstandenen Systems. DerQuellcode von rdist ist an vielen Stellen sehr verwickelt und daher unüber-sichtlich. Da die Intelligenz bei mdist im Server und nicht wie bei rdist imClient steckt, mussten allerlei Funktionen neu implementiert werden. Durchdie Komplexität ist es auch sehr schwierig, alle denkbaren Spezialfälle zutesten, weil sie abhängig von der jeweiligen Anwendung sind und derPhantasie der Anwender bei der Anwendung der rdist-Konfigurationssyntaxkaum Grenzen gesetzt sind.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 19

    5 MULTICAST-DATEIVERTEILUNG DURCH tq®-TELLICAST

    5.1 PRODUKTAUFBAU tq®-TELLICASTtq® -TELLICAST ist ein Multicastübertragungssystem, das auf MTP/SO alsMulticast-Transportprotokoll basiert. Es besteht aus verschiedenen Modu-len, die die Ü bertragung unterschiedlicher Inhalte ermö glichen:

    Abbildung 4: Produktmodule von tq®-TELLICASTDer modulare Produktaufbau ermö glicht den Einsatz des Systems in einerVielzahl unterschiedlicher Einsatzbereiche und zugleich den gezielten Ein-satz auf die jeweilige Content-Art angepaßter Module für das jeweiligeProjekt. Für den Einsatz im DWD wird die Funktionalität von tq® -TELLICASTauf das Modul FileBroadcast beschränkt.Alle Module von tq® -TELLICAST weisen neben bzw. durch die Verwendungvon MTP/SO die folgenden Sevicefunktionen auf, die zugleich die Basis fürdie Einbindung in das Dateiübertragungssystem des DWD darstellen:

    • zeit- und prioritätenkontrollierte Steuerung durch einen zentralen Sche-duler

    • Ü bertragung in logischen Kanälen (Channel), die u. a. die Festlegungvon maximalen Bandbreiten pro Channel erlauben

    • zentrale Bandbreitensteuerung (Ü berwachung der Gesamtband-breite,Koordinierung paralleler Sendeaufträge)

    • Datenkomprimierung „on the fly“, d. h. während der Ü bertragung undsomit ohne zusätzliche Verzö gerung

    • Datenverschlüsselung „on the fly“

    • gesicherte Datenübertragung mit gezielten Retransmissions

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 20

    • Ü berwachung durch ein webbasiertes Interface und Log-Dateien

    • Ausgabe von für das Accounting relevanten Daten in spezifische Datei-en

    5.2 FUNKTIONSWEISEDer tq® -TELLICAST Sender ermö glicht die Multicast-Ü bertragung von Da-teien an mehrere Empfänger. Die Daten werden als Dateien, Dateiver-zeichnisbäume oder – für Datenströ me wie z. B. Bö rsenticker – alstransparenter Datenstrom übermittelt.Die Ü bertragung erfolgt auf einer per-Channel-Basis, d. h. der physikali-sche Kanal kann in viele logische Channel unterteilt werden. Für jedenChannel werden über Channel Files spezifische Parameter wie Bandbreite,Kompression etc. festgelegt. Die Channel Files enthalten auch eine Refe-renz auf ein oder mehrere Recipient Files. Die Recipient Files sind Emp-fängerlisten. Alle Empfänger in den durch das Channel File referenziertenRecipient Files kö nnen die Daten dieses Channels empfangen.

    5.2.1 Initialisierung / AnnouncementsÜ ber einen Announcement Channel informiert der Sender die Empfängerkontinuierlich über alle anstehenden Ü bertragungen. Dazu gehö rt bei-spielsweise die:

    • Ankündigung aller Ü bertragungen vor dem Datenaustausch,

    • Verteilung der Datenschlüssel für verschlüsselte Ü bertragungen und

    • Auffordern der Empfänger, Bestätigungen für die erhaltenen Daten zusenden.

    Insgesamt hat der Announcement-Channel die Aufgabe, die Menge der aufden Empfängern zu konfigurierenden Daten mö glichst klein zu halten unddie notwendigen Informationen stattdessen automatisch vom Sender zuempfangen.

    5.2.2 Ü bertragung

    SenderDie Ü bertragung wird durch sogenannte Job Files angesteuert. Als Jobwird die Ü bertragung einer bestimmten Datenmenge an eine spezifizierteGruppe von Empfängern bezeichnet. Ein Job File definiert die Parameter,die für die Administration und Ausführung einer spezifischen Datenübertra-gung notwendig sind.Der tq® -TELLICAST Sender liest kontinuierlich neue Job Files aus dem Ver-zeichnis „jobs/incoming“ ein. Ein neuer Job wird ausgewertet und kontrol-liert, mit Systemparametern erweitert und in das Verzeichnis„jobs/scheduled“ verschoben.Solange ein Job aktiv ist, verbleibt er im Verzeichnis „jobs/scheduled“. Deraktuelle Zustand der Jobs wird regelmäßig in den Job Files im Verzeichnis„jobs/scheduled“ zwischengespeichert. Dies ermö glicht die Fortführung der

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 21

    Ü bertragung nach einem Neustart des Systems an weitgehendst der sel-ben Stelle, an der die Unterbrechung erfolgte.Nachdem ein Job beendet wurde, wird das entsprechende Job File in dasVerzeichnis „jobs/done“ verschoben, um das Ende der Ü bertragung anzu-zeigen. Job Files im Verzeichnis „jobs/done“ werden nicht länger vomSystem verwendet und kö nnen entfernt oder geändert werden.

    tq®-TELLICAST SenderMTP/SO

    jobs/incoming

    job/scheduled

    jobs/done

    FIFO Queue (Messages)

    Files

    data

    channels

    send.log

    accounting.dat

    JOB

    recipients

    tq®-TELLICASTEmpfä ngerMTP/SO

    recv.log

    data

    send.ini

    recv.ini

    Ann

    ounc

    emen

    tcha

    nnel

    Abbildung 5: Dateienü bertragung mit tq®-TELLICAST

    EmpfängerBeim Systemstart ö ffnet der Empfänger den allgemeinen AnnouncementChannel und wartet auf die Verteilung von Schlüsseln (bei aktivierter Da-tenverschlüsselung), Ü bertragungsankündigungen und Empfangsaufforde-rungen. Erfolgt eine Empfangsaufforderung, so werden die Daten auf demangekündigten Kanal empfangen.Die empfangenen Dateien und Verzeichnisse werden unter dem selbenNamen und unter den selben Unterverzeichnissen abgelegt, die auch derSender benutzt, jedoch in Relation zu einem kanalspezifischen Startver-zeichnis, das pro Empfänger gesondert konfiguriert werden kann.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 22

    6 ANWENDUNGSFALL DWD

    Kernbestandteil des Projektes MDiS war die Realisierung von Multicast-Datenübertragung innerhalb der bisher über AFD erfolgenden Datenver-teilung des DWD.Dieses Kapitel gibt zunächst einen groben Ü berblick über die zugrunde lie-gende Kommunikationsinfrastruktur des DWD und die Anforderungen, dievon Seiten des DWD an eine Multicast-Datenverteilung gestellt werden.Auf dieser Basis wird dann die Zielarchitektur vorgestellt.

    6.1 DATENVERTEILUNG IM DWDIm Folgenden wird ein Ü berblick über die Kommunikationsinfrastruktur unddie Datenverteilung innerhalb des DWD gegeben, sofern diese für MDiSrelevant sind.

    6.1.1 Beteiligte Netzstrukturen

    6.1.1.1 Primärnetz

    Das Primärnetz verbindet ringfö rmig die Zentrale des DWDs in Offenbachmit den 6 dezentralen Niederlassungen mit Regionalzentrale in Essen,Hamburg, Potsdam, Leipzig, München und Stuttgart. Die Standleitungendes Primärnetzes haben im derzeitigen Ausbau eine Bandbreite von 34MByte/s, von denen 8 Mbit/s zur Datenverteilung der angebundenen ande-ren Behö rden des Bundesministeriums für Verkehr, Bau- und Wohnungs-wesen (BVBW) reserviert sind.Den überwiegenden Anteil der Datenübertragung innerhalb des Primärnet-zes macht die Datenversorgung der dezentralen Niederlassungen mit Re-gionalzentrale aus, wobei die Datenbanktransaktionen nur einengeringeren Anteil ausmachen, während die Dateiverteilung den grö ßtenTeil des Datenvolumens benö tigt (im Endausbau bis 12 Gbyte Daten).In Rückrichtung von den dezentralen Niederlassungen mit Regionalzent-rale an die Zentrale in Offenbach erfolgt die Ü bertragung von Messdaten,z. B. der Radarstandorte. Die benö tigte Bandbreite ist jedoch viel geringerals die für die Produktverteilung von der Zentrale an die Niederlassungenmit Regionalzentrale.

    6.1.1.2 Sekundärnetz

    Das Sekundärnetz verbindet weitere grö ßere Standorte des DWDs überStandleitungen mit den dezentralen Niederlassungen mit Regionalzentrale.Dies sind vor allem Flugwetterwarten, Radarstandorte und Observatorien.Die Bandbreite dieser Verbindungen ist mit 64 kbit/s geringer als die desPrimärnetzes. Es erfolgt je nach der Auslegung des Standortes eine Ü ber-tragung von der Zentrale an die Standorte und/oder Ü bermittlung vonMessdaten an die Zentrale.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 23

    Abbildung 6: Primärnetz und Sekundärnetz des DWDs

    6.1.2 Datendistribution ü ber AFDAFD ist ein vom DWD entwickeltes Dateidistributionssystem, das sowohldie Datenübertragung innerhalb des Primär- und Sekundärnetzes als auchTeile der Kundenversorgung und des internationalen Austausches vonmeteorologischen Daten steuert und durchführt.Ü ber den Automated File Distributor (AFD) werden die Produkte von derZentrale in Offenbach aus an alle Niederlassungen verschickt. Dabei be-achtet AFD die physikalische Ringstruktur des Primärnetzes, indem dieDaten von Regionalzentrale zu Regionalzentrale weitergereicht werden. Sosendet die Zentrale die Daten nur an die beiden nächstgelegenen Regio-nalzentralen. In einer Regionalzentrale werden die Daten sowohl regionalverteilt als auch sofort an die auf dem Ring nachfolgende Regionalzentralegesendet. Dadurch erfolgt die Verteilung der Daten in die DWD-Fläche ü-ber zwei „Halbringe“, nämlich über Essen und Hamburg nach Potsdam undüber Stuttgart und München nach Leipzig.Bei dieser Verteilstruktur ergeben sich Probleme bei Ausfall einer Regio-nalzentrale, da dann die auf dem Ring nachfolgenden Regionalzentralennicht versorgt werden. In diesem Fall werden die Daten vom Endpunkt ei-nes „Halbringes“ an die nachfolgende Regionalzentrale, also z. B. vonPotsdam nach Leipzig, gesendet. Dies ist durch einfache Operatoranwei-sungen am jeweiligen AFD zu erreichen.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 24

    Jede Niederlassung besitzt einen Backup-Rechner für den Rechner, aufdem die Daten eingehen. Die Zugangsdaten und Zielverzeichnisse diesesRechners sind mit denen des eigentlichen Empfangsrechners identisch.Der Backup-Rechner wird von AFD versorgt, sobald der ursprünglicheEmpfangsrechner ausfällt.

    6.1.3 ISDN-FailoverBei Ausfall von Standleitungen des ATM-basierten AFD-Systems werdendie Daten an die betroffenen Rechner über ISDN übertragen. Die ISDN-Ü bertragung wird mit einer sehr viel geringeren Bandbreite als die primäreAFD-Ü bertragung realisiert (unter Einsatz von Kanalbündelung bis zu2Mbit/s zu einem Standort).Die Datenserver empfangen nicht nur über das interne ATM-Interface di-rekt Daten aus dem Primärnetz, sondern sind zusätzlich über ein Ethernet-Interface an das lokale LAN angebunden, über das sie u.a. auch die imFailover-Fall über ISDN übertragenen Daten empfangen kö nnen.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 25

    6.2 GEPLANTE DATENÜ BERTRAGUNG Ü BER MULTICAST

    6.2.1 Vorgesehener EinsatzbereichMulticast soll zunächst nur für die DWD-interne Datenübertragung einge-setzt werden. Für die Ü bermittlung von Daten an Kunden kann diesesVerfahren ggf. in einer späteren Ausbaustufe und evtl. kombiniert mit Sa-tellitendiensten erweitert eingesetzt werden.Im Rahmen von MDiS soll die Multicast-Datenübertragung im Primärnetzrealisiert werden. Das Sekundärnetz wird im Rahmen des Projektes nurversuchsweise und voraussichtlich zunächst nur an einem Standort durch-geführt, mit dem Ziel, die Einsetzbarkeit in diesem Bereich sicherzustellen.Damit ergeben sich folgende Einsatzbereiche für Multicast:

    • Ü bertragung von Daten von der Zentrale in Offenbach an die Daten-Server in den Niederlassungen mit Regionalzentrale.

    • Ü bertragung der von den Stationen des Sekundärnetzes an den Regi-onalzentralen eingehenden Daten von den Regionalzentralen an dieZentrale in Offenbach.

    Die Ü bertragung der Daten erfolgt auf Sendeseite über Vermittlung durchAFD, d. h. es wird eine Datei-/Verzeichnis-basierte Schnittstelle definiert,über die AFD einzelne Ü bertragungsaufträge an das Multicastsystem wei-tergibt. Dabei ist es alternativ mö glich, auch direkt von anderen Systemen(außer AFD) Daten zur Ü bertragung an das Multicastsystem weiter-zugeben.Auf Empfängerseite sind zunächst die Daten-Server als Empfänger vorge-sehen. In einem späteren Schritt (außerhalb des MDiS-Projektes) werdendirekt die Applikationsrechner als zusätzliche Empfänger eingerichtet. DieÜ bertragung erfolgt parallel an beide Daten-Server, da dies über Multicastkeine Erhö hung der Bandbreite gegenüber der Ü bermittlung von Daten aneinen einzelnen Rechner darstellt und so eine hohe Ausfallsicherung er-reicht werden kann.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 26

    6.2.2 AnforderungenFür die Realisierung des Multicastsystems ergeben sich folgende grundle-gende Anforderungen von Seiten des DWDs:

    • Jede Regionalzentrale muss als Empfänger und als Sender fungierenkö nnen, d. h. das System muss mehrere Sender zulassen, die zentralkoordiniert werden.

    • Eine Ü bertragung muss parallel an mehrere Rechner in den Regional-zentralen erfolgen kö nnen.

    • Auf den Zielrechnern werden die Daten vom Multicastsystem in einempro Ü bertragungschannel definierbaren Zielverzeichnis angelegt. Eineweitere Unterverteilung erfolgt bei Bedarf durch AFD.

    • Die Ü bertragung der Daten muss bandbreitengesteuert und prioritäten-gesteuert erfolgen kö nnen.

    • Die ISDN-Ü bertragung als Backup muss realisierbar sein.

    • Das Multicastsystem soll eine Schnittstelle zum Abfragen von Zu-standsinformationen bieten. Ziel ist es, über ein Graphical User Inter-face (GUI) die Sendezustände der beteiligten Rechner abfragen zukö nnen. Das GUI wird vom DWD ähnlich dem AFD GUI entwickelt.

    • Die unterschiedlichen Bandbreiten für das Sekundärnetz und das Pri-märnetz sowie für eine Failover-Ü bertragung über ISDN müssen durchdie Definition mehrerer Channel (Multicast-Ü bertragungsgruppen) undpotentiell unterschiedlicher Bandbreiten pro Ü bertragungsgruppe abge-bildet werden kö nnen.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 27

    6.3 ZIELARCHITEKTUR

    6.3.1 Integration von tq®-TELLICAST und AFDZiel des zu entwickelnden Multicast-Distributionssystems ist es, angesteu-ert durch AFD, einen gesicherten Multicast-Ü bertragungsdienst für mehre-re Gruppen anzubieten und dadurch neben z. B. Unicast-FTP einenweiteren Ü bertragungspfad zur Verfügung zu stellen.MTP/SO setzt dabei auf UDP auf. Zwischen dem Service-Layer vonMTP/SO, tq® -TELLICAST, und AFD wird zur Schnittstellensteuerung ein A-daptation-Layer implementiert, der im folgenden als Multicast-DistributionLayer (MD) bezeichnet wird.

    AFD

    IP

    FTP

    TCP

    UDP

    Adaptation-Layer(MD = Multicast-Distribution)

    MTP/SO

    tq®-TELLICAST

    Abbildung 7: Schichtenmodell zur Einbindung von Multicast in AFDDie folgenden Ausführungen beschreiben darauf aufbauend die Ü bergabeder Daten vom AFD-System über MD an tq® -TELLICAST und die Rückmel-dung des Sendeerfolgs von tq® -TELLICAST über MD an das zu entwickeln-de MDiS-GUI.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 28

    6.3.2 Schnittstelle zur Datenü bertragung: MDDie Schnittstelle zwischen AFD und tq® -TELLICAST ist ein neu zu imple-mentierender Prozess „Multicast Distribution Layer“ (MD) und ein bereitsnach Channeln organisierter Dateibaum.

    6.3.2.1 Schnittstelle auf Senderseite

    AFD (oder zukünftig auch andere Systeme) stellen die zu übertragendenDateien auf Sendeseite in Channel Directories ein. Für jeden definiertenÜ bertragungschannel wird hierfür auf Sendeseite ein Channel Directoryvorgesehen (siehe Abbildung 8).Der Prozess MD scannt die Channel Directories (einschließlich enthaltenerDateien und Unterverzeichnisse) kontinuierlich. Alle dort neu erkannten o-der modifizierten Dateien werden zu Sendeaufträgen (Jobs) zusammen-gefasst und über Job-Files zur eigentlichen Multicast-Ü bertragung an tq® -TELLICAST übergeben.Entsprechend der genutzten Channel-Directories überträgt tq® -TELLICASTdie Dateien auf dem jeweiligen Ü bertragungs-Channel.Die GUI (oder alternativ auch ein anderer Prozess) verbinden sich über ei-nen TCP-Server-Port mit dem MD und rufen die Daten zum aktuellenStand der Ü bertragungen über ein ASCII-basiertes Protokoll ab.

    JOBs

    AFD GUI

    Multicast Distribution MD

    tq®-TELLICASTSender

    (MTP/SO)

    FilesTCP/ASCII

    AFDEinstellen

    von Dateienzur Ü bertragung(ggf. als Links)

    ChannelDirectories

    Scannen

    Löschen

    Namenskonvention:.* = temporäre Dateien

    Lesen

    Multicast-Ü bertragung

    ChannelDefinitionen

    ReceiverDefinitionen

    MD-SEND.INI

    Abbildung 8: Schnittstellen zwischen AFD und tq®-TELLICAST Sender

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 29

    6.3.2.2 Schnittstelle auf Empfängerseite

    Empfängerseitig empfängt tq® -TELLICAST den Multicast-AnnouncementChannel sowie die für diesen Empfänger konfigurierten Multicast-Data-Channel.Welche Channel von einem Receiver empfangen werden, kann vom Admi-nistrator durch eine Receiver-Channel-Definitionsdatei festgelegt werden.In dieser Definitionsdatei ist neben den zu empfangenden Channeln u.a.auch pro Channel ein Verzeichnis konfiguriert, in das die auf diesemChannel empfangenen Dateien abgelegt werden sollen.Der Prozess MD hat auf Empfangsseite vorwiegend die Aufgabe, die in ei-nem MDiS-spezifischen Format angegebenen Channel-Definitionen sowiedie Parameter einer zentralen md-recv.ini Datei in die tq® -TELLICAST spe-zifischen Konfigurationsdateien umzuwandeln. Dabei kö nnen auf Emp-fangsseite, ebenso wie auf Senderseite, die Angaben in der ChannelDefinitionsdatei überwiegend auch zur Laufzeit ohne einen Neustart derMD/ tq® -TELLICAST Prozesse vom Operator geändert und neu übergebenwerden.tq® -TELLICAST legt die empfangenen Dateien direkt in dem für den jeweili-gen Channel angegebenen Verzeichnis ab. In diesem Verzeichnis stehensie für andere Anwendungen zur Nutzung oder AFD zur weiteren Vertei-lung zur Verfügung. Ein Lö schen dieser Dateien erfolgt durch AFD oderzukünftig ggf. auch alternative Systeme.

    Multicast Distribution MD

    tq®-TELLICASTReceiver(MTP/SO)

    Files

    AFDLöschen

    durch AFDoder„ Nutz-

    anwendungen“

    ChannelDirectories

    Scannen

    Namenskonvention:.* = temporäre Dateien

    Schreiben

    Multicast-Ü bertragung

    ChannelDefinitionen

    MD-RECV.INI

    ISDN Fallback Control

    Abbildung 9: Schnittstellen zwischen AFD und tq®-TELLICAST Receiver

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 30

    6.4 GESICHERTE DATENÜ BERTRAGUNGDie gesicherte Ü bertragung der Daten durch MDiS ist, neben der gleich-zeitigen Ü bertragung an Daten-Server und Backup-Rechner, durch vierMechanismen gewährleistet:

    • Forward Error Correction (FEC),

    • Anforderung von Datenpaketen über „Negative Acknowledgements“(NAK),

    • Retransmission auf Grundlage von Acknowledgements und

    • das ISDN-Backup-System des DWD.

    6.4.1 Forward Error CorrectionFEC gewährleistet den Ausgleich von Ü bertragungslücken auch bei Fehleneines Rückkanals, wie z. B. bei Satellitenübertragungen. Vorteil im zu-nächst ausschließlich terrestrischen Einsatz des DWD ist, dass Ü bertra-gungsfehler (fehlende Pakete) durch den Einsatz von FEC behobenwerden kö nnen, ohne dass einer oder sogar mehrere der Empfänger expli-zite NAKs (negative Empfangsbestätigungen) an den Sender zurücksen-den müssen.Der Sender generiert auf Ebene von MTP/SO FEC Redundanzpakete ausden Daten mehrerer Datenpakete, die zusammen mit den eigentlichenDaten übertragen werden, und aus denen sich fehlende Datenpakete er-rechnen lassen.Die Generierung der Redundanzpakete erfolgt „on the fly“ und unmittelbarwährend der Ü bertragung.

    6.4.2 Negative Acknowledgements (NAK)Wenn einzelne Datenpakete nicht empfangen werden, fordert der Empfän-ger das Paket durch Senden eines NAKs neu an. Das fehlende Paket wirddaraufhin noch einmal übertragen. Diese Kontrolle des Datenempfangswird auf der Ebene von MTP/SO realisiert.

    6.4.2.1 Bandbreitenkontrolle für NAK

    Der Verbrauch von Bandbreite durch NAK-gesteuerte Paketanforderungenist schwer vorhersehbar. Starke Empfangsstö rungen einzelner Empfängerkö nnen zu einer hohen Belastung der Bandbreite des Channels führen, vorallem wenn sehr viele Empfänger zum Empfang eines Channels berechtigtsind.Für diese großen Empfängergruppen kann die Belastung des Sendersdurch die Beantwortung von NAK-Anfragen durch Repetitoren verringertwerden. Als Repetitoren werden Empfänger bezeichnet, die nicht nur dieDaten empfangen, sondern außerdem gegenüber anderen Empfängern alsSender fungieren und deren NAK beantworten. Die Bandbreite zum Sen-der hin wird damit entlastet, da der Sender nur noch die NAK des Repeti-tors erhält, während die NAK aller Empfänger im Einzugsbereich desRepetitors von diesem beantwortet werden.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 31

    Die NAKs werden von den Empfängern, die dem Repetitor zugeordnetsind, zunächst mit einer geringen TTL (time to live; Anzahl der Router, dieein Datenpaket passieren kann) gesendet. Dadurch ist gewährleistet, dasssie nur bis zum Repetitor übertragen werden und den Sender nicht mehrerreichen. Nur in dem Fall, dass der Repetitor ausfällt und die fehlendenDatenpakete nicht an den Empfänger überträgt, sendet dieser die NAKsnoch einmal mit hö herer TTL aus, so dass eine Anfrage beim Sender er-folgt

    Sender

    Empfä nger

    Empfä nger

    Empfä ngerEmpfä nger/

    Repetitor

    Empfä nger

    Empfä nger

    Empfä nger

    Empfä nger

    Sender

    ohne Repetitor mit Repetitor

    Abbildung 10: NAK-Retransmissions ohne und mit RepetitorIn die Regulation der Gesamtbandbreite für die Ü bertragung und die Da-tensicherung pro Ü bertragung muss sowohl die Bandbreite der NAK-Retransmissions zwischen Sender und Empfängern als auch die zwischenRepetitoren und Empfängern einbezogen werden. Dies erfolgt durch dieKonfiguration eines festen erlaubten Prozentsatzes der Gesamtbandbreitefür jeden der erwähnten Datensicherungsmechanismen pro Channel. Da-bei wird der Prozentsatz der Bandbreite für FEC und Packet Retransmissi-on von der im Sender konfigurierten maximalen zulässigen Bandbreite fürden Channel abgezogen, wobei die FEC-Bandbreite konstant von FEC ge-nutzt wird, während die für Packet Retransmission nur im Bedarfsfall abge-zogen wird, d. h. die Bandbreite steht sonst für die eigentliche Ü bertragungzur Verfügung.Die Bandbreite für Repetitor Packet Retransmission wird im Gegensatz da-zu auf die momentane Bandbreite des Channels aufgerechnet. Der Anteilan Repetitor Packet Retransmission kann in allen Repetitorgruppen indivi-duell konfiguriert werden.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 32

    Cha

    nnel

    band

    brei

    te

    % Bandbreite fü r FEC

    % max. genutzte Bandbreite fü r Repetitor Packet Retransmission

    % max. genutzte Bandbreite fü r Packet Retransmission

    lokal max.hinzugefü gtm

    ax.

    genu

    tzte

    Ban

    dbre

    ite

    / C

    hann

    el

    Abbildung 11: Einteilung der Channelbandbreite unterBerü cksichtigung von Datensicherungsmechanismen

    6.4.3 Steuerung von Retransmissionstq® -TELLICAST kann so konfiguriert werden, dass die Empfänger den voll-ständigen Empfang der übertragenen Dateien durch Acknowledgementsbestätigen. Fehlen die Acknowledgements von einzelnen oder mehrerenEmpfängern, kann die Ü bertragung von tq® -TELLICAST wiederholt werden.Dabei kann in den Job Files eine maximale Anzahl an Ü bertragungswie-derholungen konfiguriert werden.Für die Multicastübertragung in MDiS ist es wünschenswert, dass dieSteuerung der Retransmissions von MD und nicht von tq® -TELLICAST vor-genommen wird. tq® -TELLICAST überträgt daher die Daten nur einmal. Dieeingegangenen Acknowledgements für diese Ü bertragung werden von MDaus dem Job File ausgelesen, sobald dieses im „jobs/done“-Verzeichniserscheint. Retransmission an die Empfänger, die den Empfang der Datennicht bestätigt haben, erfolgt durch die Generierung eines neuen Job Filesdurch MD. Dies hat die folgenden Vorteile gegenüber der automatischenRetransmission durch tq® -TELLICAST innerhalb eines einzigen Jobs:

    • Der Status der Ü bertragung wird nach jeder einzelnen Ü bertragung anMD weitergegeben und kann an die GUI nach Anfrage weitergeleitetwerden.

    • Die Priorität der Retransmissions kann gegenüber der Priorität derErstübertragung herabgesetzt werden. Da für den Wetterdienst beson-ders die letzten, aktuellen Daten wichtig sind, kö nnen dadurch neu ein-gehende Sendeaufträge vor den Retransmissionen alter Datenübertragen werden, weil sie die hö here Priorität besitzen.

    Die Empfängerliste für die Retransmission kann gezielter auf die Empfän-ger beschränkt werden, die keine Acknowledgements gesendet haben.

    6.4.4 Realisierung des ISDN-BackupsDie Daten werden über 2 verschiedene Multicastadressen auf 2 Channelnvon tq® -TELLICAST gesendet:

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 33

    • Die wichtigsten Daten werden konstant über einen Multicast-Channelgesendet, der sowohl über ATM als auch über ISDN geroutet werdenkann, und der im normalen Betrieb über ATM und bei Bedarf automa-tisch über ISDN geroutet wird.

    • Die weiteren Daten werden über einen zweiten Channel übertragen, dernur über ATM geroutet wird, daher über ISDN/Ethernet nicht empfan-gen werden kann und somit auch keine Bandbreite der ISDN-Verbindung in Anspruch nimmt.

    Solange über ATM empfangen werden kann, gehen alle Daten über ATMohne Verzö gerung bei den Empfängern, d. h. den Daten-Servern, ein.Wenn ATM ausfällt, ist über das ISDN-Backup eine Notversorgung mit denwichtigsten Daten gewährleistet.Die Multicastempfänger auf den Daten-Servern, die im Normalbetrieb aufden Empfang über das ATM-Interface eingestellt sind, kö nnen den Ausfallder ATM-Ü bertragung über den Announcementchannel von tq® -TELLICASTregistrieren. Der Announcementchannel wird immer von allen Empfängernkonstant empfangen. Daher kann er als Indikator für den Ausfall des Net-zes dienen. Registriert der Empfänger, das er den Announcementchannelüber ATM nicht mehr empfängt, so wird der Empfang über das Ethernet-Interface auf ISDN umgestellt.

    6.5 BANDBREITENMANAGEMENT BEI MEHREREN SENDERNFür alle Sender des Systems wird ein gemeinsames Bandbreitenmanage-ment realisiert. Ein Sender wird dabei zum Master-Sender und reguliert dieGesamtbandbreite. Die anderen Sender teilen dem Master-Sender ihrenBandbreitenbedarf mit und bekommen von diesem entsprechend der aktu-ellen Verfügbarkeit Bandbreite zugewiesen.Welcher Sender das Bandbreitenmanagement übernimmt, wird zwischenden Sendern automatisch ausgehandelt. Jeder Sender bekommt über dieKonfigurationsdatei eine Priorität zugewiesen. Die Sender tauschen sich ü-ber die Priorität aus und weisen die Master-Funktion dem Sender mit derhö chsten Priorität zu.Der Master-Sender teilt den anderen Sendern über den Announcement-channel in regelmäßigen Abständen mit, an welche Adresse die Anfragenfür Bandbreite gesendet werden sollen. Wenn dieses Signal ausbleibt, wirdautomatisch ein neuer Sender als Master-Sender festgelegt.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 34

    6.6 SCHNITTSTELLE ZUM MDIS-GUIDie Schnittstelle zwischen dem Sender-seitigen MD / tq® -TELLICAST undder Sendekontrolle über das GUI (Graphic User Interface von AFD) bildetebenfalls das MD.Die GUI (oder alternativ auch ein anderer Prozess) verbinden sich über ei-nen TCP-Server-Port mit dem MD und rufen die Daten über ein ASCII-basiertes Protokoll ab. MD lässt dabei eine Abfrage nur von Rechnern zu,die in einer GUI-Rechnerliste des MD eingetragen sind.MD liest die an das GUI zu übermittelnden Daten über den Sendeerfolg derÜ bertragung aus den tq® -TELLICAST Job Files im „jobs/done“-Verzeichnisaus.

    GUI MD tq®-TELLICAST

    jobs/done

    Abfrage Abfrage

    Abbildung 12: Abruf von Informationen ü ber die Multicast-Ü bertragung durch das GUI

    Ein zentrales GUI kann die notwendigen Daten der einzelnen MD-Prozesseentweder ebenfalls direkt oder (performanter) analog zu AFD von den ein-zelnen GUIs abfragen.Von MD werden die Informationen über den Sendeerfolg wie folgt über-mittelt:

    • pro Empfänger

    • als noch zu übertragende Dateien

    • als noch zu übertragende Bytes Unabhängig vom Rhythmus und Art der vom GUI angefragten Informati-onsübergabe überträgt MD bei jeder Rekonfiguration eine aktuelle Emp-fängerliste und Channel-Liste an das GUI.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 35

    6.7 REALISIERUNG IM RAHMEN DES PROJEKTESNach der Konzeptionierung erfolgte Mitte des Jahres 2001 die Bereitstel-lung des um den Prozess „Multicast Distribution Layer“ erweiterten Multi-castübertragungssystems tq® -TELLICAST durch die Firma Tellique.Aufgabe des DWD war anschließend der Test dieser Software und darauffolgend die Aufnahme der routinemäßigen Datenverteilung über Multicast.

    6.7.1 TestsDie Funktionsfähigkeit der gelieferten Software wurde durch die Firma Tel-lique auf zwei O200-Rechnern – einem Sender und einem Empfänger –vorgeführt. Nach den ersten Konfigurationsversuchen und Tests wurde dieTestumgebung um drei Linux-PCs erweitert. Die fünf Rechner - eine O200dient als Sender - befinden sich in drei Subnetzen und bieten so eine Test-plattform für die betriebliche Konfiguration des DWD. Bei den einführendenTestläufen ermittelte Fehler wurden von Tellique nach Meldung beseitigt.Die Tests auf Datenintegrität der Multicast-Verteilung sind noch nicht be-endet. Hierfür wurde ein Testsystem entwickelt, dass eine definierte Anzahlvon binären Dateien generiert und diese dem MDiS übergibt. Auf denEmpfängern wird nach der Datenübertragung die Vollständigkeit und Integ-rität der Dateien automatisch geprüft. Dieser Test wird mehrfach und mitunterschiedlichen Dateigrö ßen durchgeführt. Auch wechselt der Senderzwischen den fünf Rechnern.Ein Bestandteil der Testprozeduren sind Durchsatztests, in denen dieLeistung des Multicastsystem gemessen und teilweise Vergleichsmessun-gen mit der DWD-eigenen operationellen Fileverteilung per FTP-Protokollvorgenommen werden.In einer zweiten Testgruppe werden Stö rungen im Netz und auf den Rech-nern simuliert und die korrekte Reaktion der Multicastdatenverteilung aufdiese Problemsituationen verifiziert. Diese Test sind für den DWD beson-ders wichtig, da im Gegensatz zu üblichen Anwendungen von Multicast-Verteilung (z.B. Video-Konferenzen), bei denen der Verlust einzelner UDP-Pakete akzeptiert werden kann, bei der Dateiverteilung im DWD mittelsMulticast keine Datei verloren gehen bzw. verfälscht werden darf. Deshalbwird dieser Test mit aller Sorgfalt durchgeführt und ist noch nicht abge-schlossen.

    6.7.2 Festlegung der Multicast-ChannelDie Festlegung der Multicast-Channel ist ein iterativer Prozess, bei dem diemeteorologisch-technischen Anforderungen (z.B. Zeitverhalten der Daten-verteilung; Prioritäten bestimmter Datenarten) und die heterogene Netz-werkleistungssituation (unterschiedlich leistungsfähige Anbindung vonDienststellen, die teilweise dieselben Daten benö tigen) abgestimmt werdenmüssen. Für die für das Projekt vorgesehene Versorgung der Regional-zentralen mittels Multicast scheint die Festlegung zunächst eine einfacheAufgabe zu sein. Für eine Planung des Gesamtnetzes ist aber eine diffe-renzierte Planung der Multicastkanäle erforderlich, bei der das Auslas-tungsverhalten der nur mit 64 kBit/sec realisierten Stichverbindungen mitzu berücksichtigen ist. Da die bisherige Fileverteilung die Daten entspre-

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 36

    chend ihrer jeweiligen Priorität über eine oder nur maximal einige wenigelogische Verbindungen von Knoten zu Knoten transportiert, fehlen Erfah-rungswerte über das Stauverhalten der notwendigen grö ßeren Anzahl vonMulticastdatenströ men an den Ü bergangspunkten zwischen schnellen undlangsamen Netzabschnitten. Die Festlegung der Multicastchannel wird zurZeit als Vorbereitung für die Inbetriebnahme parallel zu den Tests vorge-nommen und ist bisher noch nicht abschließend erfolgt.

    6.8 INBETRIEBNAHMEDa die Testphase noch nicht abgeschlossen werden konnte, kam eine In-betriebnahme während der Laufzeit des Projektes noch nicht in Frage.Noch nicht entschieden ist außerdem die Frage, ob die Versorgung derkleineren Standorte von der Zentrale in Offenbach aus erfolgen soll, oderob es besser ist, in jeder Regionalzentrale einen Multicastsender einzu-richten, der die an dieser Regionalzentrale angeschlossenen Standorte desSekundärnetzes versorgt. Im ersten Fall würden die Daten, um den teilwei-se engen zeitlichen Versorgungsanforderungen gerecht zu werden, zwei-mal gesendet werden – einmal für die Regionalzentralen und einmal mitgeringerer Bandbreite für die Standorte des Sekundärnetzes. Im zweitenFall würde ein deutlich hö herer Konfigurationsaufwand – für jede Regional-zentrale ein eigener Channel zur Versorgung der angeschlossenen Stand-orte – und eine zusätzliche Ü bergabefunktion an den Multicastsender ander Regionalzentrale benö tigt werden.

    6.9 BEWERTUNG DES ERGEBNISSESDie bisher vorliegenden Testergebnisse zeigen, dass das unter MDiS ent-wickelte Multicastsystem für eine Datendistribution innerhalb des DWDsgeeignet ist. Allerdings erfordert eine erfolgreiche Nutzung noch einenKonfigurations- und Planungsaufwand für die Umstellung des Systems vonSeiten des DWD.Ausgangspunkt der Planungen des DWD für den Betriebseinsatz warendie effektivere Nutzung der Netzwerk- und Rechnerresourcen und die Ein-sparung von Konfigurations- und Betreuungsaufwand durch eine Zentrali-sierung der Steuerung der Datenverteilung.Die als primäres Projektziel geplante Umstellung der Datenverteilung vonder Zentrale zu den Servern auf den Dienststellen bringt dem DWD zu-nächst nicht den erwarteten Nutzen, da der Aufwand für die Datenvertei-lung auf die unterschiedlichen Anwendungen auf den Servern bzw. dieUnterverteilung auf die Rechner der Dienststellen bleibt. Die durch die Auf-gabe des Hub-To-Hub Systems eingesparten Betreuungs-aufwände wer-den voraussichtlich durch den Betreuungsaufwand für die Multicast-Anwendung kompensiert werden. Eine wirksame Minderung des Aufwan-des kann nur durch die direkte Multicastversorgung der Anwendungen mitden für sie relevanten Informationen erreicht werden. Die dafür erforderli-che Migration der DWD-Anwendungen war im Projekt nicht vorgesehenund ist nur auf mittlere Sicht umsetzbar. Zur Zeit wird eine Zwischenlö sungrealisiert, bei der Multicastempfänger auf allen zu versorgenden Rechnerninstalliert und lokal die Zuordnung der Daten zu den Anwendungen vorge-nommen wird.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 37

    Eine Minderung der Netzlast im Primärring gegenüber der Unicast-Datenverteilung war von vorneherein nicht zu erwarten, da das Hub-to-Hub-System des DWD eine Art „simulierte Multicastverteilung“ im Primär-ring bewirkte. Die Daten wurden jeweils von Niederlassung zu Niederlas-sung weitergereicht, anstatt von der Zentrale an jede Niederlassungeinzeln versendet zu werden.Seit dem Sommer 2001 wurden in einer Studie des BMVBW die Mö glich-keiten zur Harmonisierung der europäischen meteorologischen Satelliten-verteildienste untersucht. Dabei stellte sich heraus, dass die Ü berlagerungder terrestrischen Netze des DWD durch eine Multicast-Datenverteilung ü-ber eine hochverfügbare Satellitenstrecke für die Grundversorgung derDWD-Dienststellen wirtschaftlich vorteilhaft ist. In Konsequenz beauftragteder DWD-Vorstand der Aufbau eines derartigen Systems bis Ende 2002.Für dieses Projekt wird die mit MDiS geschaffene Datenverteilung so mo-difiziert, dass die Verteilanforderungen des DWD durch einen Verbund vonterrestrischen und satellitengestützten Multicastverbindungen abgedecktwerden kö nnen. Durch die Verwendung von MDiS sowohl im terrestrischenNetz als auch auf der Satellitenstrecke kann eine optimale Kompatibilitätbeider Datenverteilsysteme erreicht werden, was den Verwaltungsaufwanderheblich senken kann.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 38

    7 PROJEKTERGEBNIS

    Ziel des Projektes MDiS ist der Piloteinsatz eines gesicherten Multicast-Dateiverteilsystems auf Basis des Transportprotokolles MTP/SO.Pilotnutzer im Projekt ist der DWD. Der DWD bietet sich als Pilotnutzer an,da über das AFD-System in den Standleitungen des Primärnetzes und desSekundärnetzes des DWD große Mengen komplexer Daten zwischen denNiederlassungen ausgetauscht werden, wobei an mehrere Standorte iden-tische Daten übertragen werden.Die Multicast-Dateiverteilung für den DWD wurde mit tq® -TELLICAST Fi-leBroadcast realisiert, einer von Tellique auf Basis MTP/SO entwickeltenSoftware für gesicherte Datenverteilung über Multicast. tq® -TELLICASTwurde über einen Adaptationslayer (Multicast-Distribution, MD) in die übli-che Datenverteilung des DWD über AFD integriert.In ersten Tests konnte während der Laufzeit des Projektes die Funktions-tüchtigkeit des Systems nachgewiesen werden. Der DWD hat bisher je-doch die Multicast-Datenverteilung noch nicht in den laufenden Betriebintegriert. Da die Anforderungen an die Sicherheit und die zeitkritische Ü -bertragung beim DWD besonders hoch sind, legt der DWD Wert darauf,zunächst langfristigere Tests durchzuführen. Zudem erfordert die Etablie-rung des neue System zunächst erhö hten Konfigurationsaufwand in derUmstellungsphase, um eine optimale Anpassung sämtlicher Parameter zugewährleisten. Der DWD wird deshalb das System schrittweise nach denLangzeittests einführen. Die bisher vorliegenden Testergebnisse sind je-doch schon so positiv, dass der DWD beschlossen hat, die unter MDiSverwendete Software zusätzlich zur Datenverteilung über die terrestrischenNetze auch für die Satellitendistribution einzusetzen. Damit wäre eine op-timale Kompatibilität zwischen den Systemen gegeben.Für die Integration der Multicast-Datendistribution in das AFD-System desDWD wurde die von Tellique entwickelte Software tq® -TELLICAST verwen-det. Um den universellen Einsatz von MTP/SO auch außerhalb der Einbin-dung in tq® -TELLICAST zu demonstrieren, wurde auf Grundlage des weitverbreiteten Unicast-Dateiverteilsystems rdist ein Tool zur Multicast-Dateiverteilung, mdist, entwickelt. Durch die Entwicklung von mdist ist einTool entstanden, das es Anwendern, die rdist nutzen, ermö glicht, Daten ü-ber Multicast zu übertragen, ohne die schon vorhandene Konfiguration vonrdist ändern zu müssen. Dadurch kann gesicherte Multicastübertragung füreine Vielzahl von Nutzern des Wissenschaftsnetzes des DFN interessantwerden.Weitere Anwendungsmö glichkeiten, die sich für Nutzer des Wissen-schaftsnetzes ergeben, sind unter anderem die Distribution von Softwaresowie die Realisierung von FTP-Mirror und Web-Mirror. Neben der Integra-tion in Anwendungen bietet sich IP-Multicast auch als Unterstützung derzentralen DFN-Infrastruktur, z. B. zur Verteilung von NetNews und zumWeb-Caching an. Um die Nutzung von Multicast im Bereich des B-WIN zufö rdern, wird das Protokoll MTP/SO auf Anforderung den DFN-Mitgliedernzur Verfügung gestellt, wenn Projekte unter Verwendung von Multicast in-nerhalb des B-WIN realisiert werden sollen. Ü ber eine BSD-Socket-

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 39

    ähnliche Schnittstelle kö nnen so verschiedenartige Anwendungen von denVorteilen von IP-Multicast profitieren.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 40

    8 ABKÜ RZUNGSVERZEICHNIS/GLOSSAR

    Aaccounting.dat Datei von tq® -TELLICAST, in die das System wäh-

    rend der Ü bertragungen die Informationen schreibt,welche Daten an wen übertragen wurden.

    ACK Acknowledgement, Bestätigung über den Daten-empfang, die der Empfänger an den Sender schickt.

    AFD Automated File Distributor; Dateiübertragungssys-tem des DWD.

    Announcement-Channel

    Logischer Kanal (Channel), über den tq® -TELLICASTÜ bertragungsaufforderungen und Datenschlüssel andie Empfänger verteilt.

    ASCII American Standard Code for Information Inter-change.

    ATM Asynchronous Tranfer Mode; Zellbasiertes Ü bertra-gungsverfahren.

    Bbit/s Bit pro SekundeB-WiN Breitband-Wissenschaftnetz des DFN-Vereins.bzw. Beziehungsweise

    CChannel Logischer Kanal, über den tq® -TELLICAST Daten

    versendet. tq® -TELLICAST teilt physikalische Kanälein mehrere Channel auf.(Auf IP-Ebene gleichzusetzen mit einer Multicast-Gruppe.)

    Dd. h. das heißtDFN-Verein Verein zur Fö rderung des Deutschen Forschungs-

    netzes, Betreiber des WiN und B-WiN.DWD Deutscher Wetterdienst

    Eetc. Etcetera; und so weiterEthernet LAN-Protokoll IEEE 802.3

    FFEC Forward Error Correction; Korrektur von Ü bertra-

    gungsfehlern ohne Verwendung eines Rückkanalsdurch Berechnung von fehlenden Datenpaketenüber Redundanzpakete.

    FTP File Transfer Protocol. Eine Standardanwendung fürTCP/IP, die nur die Fileübertragung und keinen File-zugriff beinhaltet.

    GGByte Gigabyteggf. Gegebenenfalls

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 41

    GUI Graphical User Interface;hier: Kontrolloberfläche des AFD-Systems desDWD.

    IIETF Internet Engineering Task Force – Standardisie-

    rungsorganisation des Internets.Invitation Empfangsaufforderung für eine Datenübertragung

    auf einem bestimmten Channel, die der tq® -TELLICAST Sender über den Announcementchannelan die tq® -TELLICAST Empfänger sendet.

    IP Internet ProtokollIRTF Arbeitsgruppe der IETF zur Entwicklung von Stan-

    dards zur gesicherten Datenübertragung.ISDN Integrated Services Digital Network; digitales Daten-

    übertragungsnetz.K

    kbit/s Kilobit pro SekundeL

    LAN Local Area Networklog.dat Datei von tq® -TELLICAST, in die Fehlermeldungen

    und Systemstatusmeldungen während des Betriebsvon tq® -TELLICAST geschrieben werden.

    MMByte/s Megabytes pro SekundeMDiS Multicast Distribution System; System zur gesicher-

    ten Ü bertragung von Multicast, das im Rahmeneines DFN-Projektes vom DWD, der Tellique GmbHund dem Technologiezentrum Informatik der Uni-versität Bremen beim Deutschen Wetterdienst inBetrieb genommen wird.

    mdist Aus rdist und MTP/SO im rahmen von MDiS entwi-ckeltes Tool zur Multicast-Dateiverteilung.

    MTP/SO Multicast Tranport Protocol / Self Organizing; vonder Tellique GmbH vertriebenes Transportprotokollzur sicheren Datenübertragung über Multicast aufder Basis des RFC 1301.

    Multicast Mehrpunktübertragung. Ü bertragung von einemPunkt zu einer Gruppe.

    Multicast-Backbone Multicastfähiger „Backbone“ im Internet.

    PDF wurde mit FinePrint pdfFactory-Prüfversion erstellt. http://www.context-gmbh.de

    http://www.context-gmbh.de

  • MDiS-Abschlußbericht - 15.02.2002 42

    NNAK Negative Acknowledgement. Ü bertragungs-kontrolle

    durch Rückmeldung vom Empfänger, wenn die er-warteten Datenpakete vom Sender nicht empfangenwurden.

    PPrimärnetz Standleitungen mit einer Bandbreite von 34 KBit/s,

    die die Zentrale des DWD in Offenbach und die 6Niederlassungen mit Regionalzentrale ringfö rmigmiteinander verbinden.

    Rrdist Programm zur Unicast-Dateiverteilung unter UNIX.

    SSekundärnetz Standleitungen geringerer Bandbreite, die kleinere

    Standorte des DWD mit den Niederlassungen mitRegionalzentralen verbinden.

    SMTP Simple Mail Transfer ProtokollT

    TCP Transmission Control Protocol. Verbindungsorien-tiertes Transportprotokoll, das in Verbindung mit IPeingesetzt wird.

    tq®


Recommended