ZIDline 04

Mail-Bastionsrechner

Daten- und Telekommunikationsverkabelung

Umlaute in E-Mails

Elektronische Zeitschriften

Nr. 4 / Dezember 2000

ISSN 1605-475X

INFORMATIONEN DES ZENTRALEN INFORMATIKDIENSTES DER TU WIEN

Seite 2 – Dezember 2000 – ZIDline 4

Inhalt

Mail-Bastionsrechner– eine elegante Lösung der Spam-Problematik. . . . . 3

Server-Zertifikate des Zentralen Informatikdienstes . . . 8

Entwicklung der Daten- undTelekommunikationsinfrastrukturzur Institutsversorgung an der TU Wien. . . . . . . . . . 9

Eine einfache Firewall-Lösung. . . . . . . . . . . . . . . . . . . 16

Chello StudentConnect an der TU Wien . . . . . . . . . . . 17

Ö oder =?iso-8859-1?Q?=D6?=Umlaute in E-Mails . . . . . . . . . . . . . . . . . . . . . . . . . 20

Effizientes Lösen numerischer Problememit MATLAB 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Das Programm ERDAS IMAGINEangewandt zur Erfassung der Schneedecke ausFernerkundungsaufnahmen. . . . . . . . . . . . . . . . . . . 27

Zeitschriften: elektronisch ! . . . . . . . . . . . . . . . . . . . . . 31

Personelle Veränderungen . . . . . . . . . . . . . . . . . . . . . . 36

Wählleitungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Auskünfte, Störungsmeldungen . . . . . . . . . . . . . . . . . . 38

Öffnungszeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

PersonalverzeichnisTelefonliste, E-Mail-Adressen . . . . . . . . . . . . . . . . 39

Editorial

Wir beginnen diese Ausgabe der ZIDline mit einemausführlichen Bericht über den notwendig gewordenenEinsatz eines Mail-Bastionsrechners zur Verhinderungvon Mail-Relaying an der TU Wien. Als weiteres Securi-ty-Thema wird eine einfache Firewall-Lösung auf Linux-Basis vorgestellt.

Zusammenfassend wird die Geschichte der Daten- undKommunikationsverkabelung der TU behandelt und dieaktuellen Entwicklungen auf dem Gebiet der Verkabe-lungstechnik werden aufgezeigt.

Aufgrund der Diskussionen der letzten Zeit anlässlichder Performance von Chello StudentConnect werden diegeschichtliche Entwicklung, die technische Ausrüstungund die Anbindung dieses Services ausführlich darge-stellt.

Vielleicht ist Ihnen schon einmal eine E-Mail mit un-lesbaren deutschen Umlauten untergekommen. Lesen Sieab Seite 20, woran das liegen kann und wie man es ver-meidet.

Die neue Version 6 des Programmpakets MATLAB

wird Effizienzsteigerungen im Bereich numerischer Be-rechnungen durch die Einbindung von LAPACK und FFTW

bringen. Untersuchungen dazu finden Sie in diesem Heft.

Die Anwendungsmöglichkeiten des auf zentralen Ap-plikationsservern des ZID installierten ProgrammpaketsERDAS IMAGINE werden anhand eines konkreten Pro-jektes vorgestellt.

Die Universitätsbibliothek der TU Wien bietet Zugangzu zahlreichen E-Journals. Diese Publikationsform wirddiskutiert und am Beispiel der IEEE/IEE Library werdenRetrievalmöglichkeiten erörtert.

Ich möchte mich an dieser Stelle herzlich bei allenAutoren dieser Ausgabe für ihre Beiträge und die guteZusammenarbeit bedanken.

Mit den besten Wünschen für 2001

Irmgard Husinsky

Impressum / Offenlegung gemäß § 25 Mediengesetz:

Herausgeber, Medieninhaber:Zentraler Informatikdienstder Technischen Universität WienISSN 1605-475X

Grundlegende Richtung: Mitteilungen des ZentralenInformatikdienstes der Technischen Universität Wien

Redaktion: Irmgard Husinsky

Adresse: Technische Universität Wien,Wiedner Hauptstraße 8-10, A-1040 WienTel.: (01) 58801-42014, 42001Fax: (01) 58801-42099E-Mail: [email protected]: http://www.zid.tuwien.ac.at/zidline/

Erstellt mit Corel VenturaDruck: HTU Wirtschaftsbetriebe GmbH,1040 Wien, Tel.: (01) 5863316

www.zid.tuwien.ac.at/zidline/

Mail-Bastionsrechner– eine elegante Lösung derSpam-ProblematikUdo Linauer

Der Mail-Bastionsrechner ist ein Teil des Firewallkonzepts für die TU Wien. Ungeachtet dessen,dass es sich um eine redundante Konfiguration mit mehreren Servern der Firma SUN handelt,wird in der Folge von dem Mail-Bastionsrechner – als funktionale Einheit – gesprochen. DerEinsatz des Mail-Bastionsrechners macht es Außenstehenden unmöglich, Mailserver an derTU Wien zum Versenden von Spam-Mail 1 zu missbrauchen. Die gesamte an der TU Wieneinlangende Mail wird dazu über den Mail-Bastionsrechner umgeleitet, wo folgende, einfacheÜberprüfung stattfindet: „Stelle die Mail zu, wenn der Empfänger in der TU Wien ist,sonst lehne sie ab.“Die Benutzer an der TU Wien müssen keine Veränderungen an ihrer Mailsoftware vornehmen. DieUmstellung wird Institut für Institut vorgenommen und soll bis zum Jahresende vollzogen sein.Notwendige zentrale Adaptionen im Domain Name Service werden in Vorgesprächen mit denAnsprechpartnern des ZID an den Instituten erörtert.

Nach einer Einführung in die Problematik von Spam-Mail wird auf die Technologie des Mail-Bastionsrechners und die für den Einsatz nötigen Vorarbeiten eingegangen. In Ergänzung dazuwerden für interessierte Leser am Ende des Artikels die technischen Hintergründe genauerbeleuchtet.

Spam-Mail

Spam-Mail ist eine Postwurfsendung im Internet.Jede(r) von uns sah sich schon mit der meistens nutzlo-sen Information konfrontiert, deren Beseitigung zwarnicht allzu viel aber doch zu viel unserer kostbaren Zeitkonsumiert. Große Stückzahlen bedeuten für Netze undMailserver eine enorme Belastung, die Geld kostet und

bisweilen sogar zu Abstürzen führt. Um Missbrauch ei-nen Riegel vorzuschieben, behandelt der österreichischeGesetzgeber Spam-Mail im Telekommunikationsgesetzwie Telefonmarketing. Sie ist ohne vorherige – jederzeitwiderrufliche – Zustimmung des Empfängers unzulässig(TKG §101 – Unerbetene Anrufe 2). Die meisten anderenStaaten sehen in ihrer Gesetzgebung die Möglichkeit des„Opt-out“ vor, das heißt, dass Empfänger sich jederzeit

ZIDline 4 – Dezember 2000 – Seite 3

1 Spam – Spam is unsolicited Mail on the Internet. From the sender's point-of-view, it's a form of bulk mail, often to a list culled from subscribers to aUsenet discussion group or obtained by companies that specialize in creating Mail distribution lists. To the receiver, it usually seems like junk Mail. Ingeneral, it's not considered good netiquette to send spam. It's generally equivalent to unsolicited phone marketing calls except that the user pays for partof the message since everyone shares the cost of maintaining the Internet. Some apparently unsolicited Mail is, in fact, Mail people agreed to receivewhen they registered with a site and checked a box agreeing to receive postings about particular products or interests. This is known as both opt-inMail and permission-based Mail. A first-hand report indicates that the term is derived from a famous Monty Python sketch ("Well, we have Spam, to-mato & Spam, egg & Spam, Egg, bacon & Spam...") that was current when spam first began arriving on the Internet. Spam is a trademarked Hormelmeat product that was well-known in the U.S. Armed Forces during World War II.2 http://www.tkc.at/WWW/RechtsDB.nsf/pages/TKG

gegen die Zusendung weiterer Mail verwehren können.Auch die Security Policy der TU Wien 3 verbietet dasVersenden von elektronischen Massensendungen (Spam-Mail). Den in den letzten Jahren geschaffenen gesetzli-chen Bestimmungen zum Trotz steigt die Anzahl vonSpam-Mail unablässig. Unterschiedliche nationaleGesetzgebungen, gefälschte Mail-Header (Absenderad-ressen) und aufgrund schlechter Erfolgsaussichten man-gelnde Kooperationsbereitschaft involvierter Providerbehindern die Ausforschung der Absender. Bisweilenlässt sich zumindest die Sperre des Absenderaccounts er-wirken. Der Erfolg ist jedoch meist nur von kurzer Dau-er. Es wäre unrichtig zu behaupten, dass ProviderSpammer als gute Kunden schätzen, ganz im Gegenteil.Spammer verbrauchen überdurchschnittlich viel Ressour-cen, behindern somit oft andere Benutzer. Die meistenProvider verfügen über Bestimmungen („Fair Use Poli-cy“, „Acceptable Use Policy“ etc.), die das Versendenvon Spam-Mail untersagen und Spammer von der Benut-zung ihrer Services ausschließen. Für den Spammer be-steht daher ein guter Grund, seine Tätigkeit nicht unterseinem Namen bei seinem Provider auszuüben, sondernfremde Ressourcen dafür zu verwenden. Dabei kommtihm eine Eigenschaft des im Internet am häufigsten ver-wendeten Mail-Protokolls SMTP 4 zugute, nämlich dieFunktion des Mail-Relays 5.

Tatsächlich wird bei weitem mehr Spam-Mail überfalsch konfigurierte, so genannte „offene Mail-Relays“Dritter versandt als „unter eigenem Namen“. Der Spam-mer bleibt dabei oft unerkannt, der Zorn der Empfängerentlädt sich auf den Administrator des Servers, der in derMail als absendender Mail-Server aufscheint. (WarumMail-Relays benötigt werden und wie sie missbrauchtwerden, können Sie am Ende des Artikels in den „techni-schen Hintergründen“ nachlesen.)

Die Internetgemeinde begnügte sich aber nicht mitzornigen Verbalattacken gegen säumige Administratoren.Es bildeten sich „Selbsthilfegruppen“ (ORBS 6 ist wohldie bekannteste), die Listen von Mailservern mit offenemMail-Relay führen. Mailserversoftware wurde dahinge-hend modifiziert, dass solche Listen automatisch heruntergeladen werden und Mail von gelisteten Servern nichtzugestellt wird. Diese Maßnahme betrifft natürlich alleBenutzer und nicht nur Versender von Spam-Mail. IhreMail kann nicht mehr zugestellt werden.

Die Situation an der TU Wien

Durchschnittlich 10 % der tatsächlich vorhandenen,teilweise auch versehentlich als solche konfiguriertenMailserver (dazu zählen praktisch alle schlampig instal-lierten Linux-Systeme) oder immerhin 6 % der offiziellin der TUNET-Datenbank eingetragenen Mailserver sind

auf der ORBS-Liste. Oft sind die verantwortlichen Admi-nistratoren völlig ahnungslos, weil die meisten Beschwer-den am ZID, dem Betreiber und Kontaktpartner für dasTUNET, einlangen. Man kann sich leicht ausmalen, wiedie betroffenen Mitarbeiter des ZID reagieren, wenn dasWörtchen Spam fällt. Da immer wiederkehrenden Ap-pelle an die Institute, die Mailserver doch in gutem Zu-stand zu halten, keinen Erfolg hatten, sahen sich dieVerantwortlichen am ZID genötigt, ein Konzept für ei-nen Mail-Bastionsrechner zu entwickeln (Anfang 1999),um dieses Problem ein für alle Mal zu lösen.

Spätestens als auch die zentralen Mailserver der TUWien (mr.tuwien.ac.at und mail.zserv.tuwien.ac.at) aufdie ORBS-Liste gesetzt wurden und damit tatsächlichtausende Kollegen betroffen waren, stand der Entschlussfest, den Mail-Bastionsrechner so schnell wie möglich fürdie gesamte TU Wien in Betrieb zu nehmen. Grund dafürwar übrigens eine besonders kniffelige Art des Mail-Re-laying. Manche Mailserver (mit offenem Mail-Relay) aufder TU Wien verwenden zum Absenden der Mail denzentralen Mail-Server der TU Wien. Wenn solch einMailserver zum Versenden von Spam-Mail verwendetwird, scheint auch der jeweilige zentrale Mailserver imMailheader auf und wird folgerichtig auf die Liste ge-setzt. Es gelang zwar immer, die zentralen Mailserverschnell wieder von der Liste herunterzubekommen, dasProblem ist aber ohne Mail-Bastionsrechner nicht zu lö-sen. Zentrale Mailserver müssen Mails, die sie aus demTUNET erhalten, weitersenden. Das ist ihre Aufgabe.

Funktionalität eines Mail-Bastionsrechners

Ein Bastionsrechner (auch application gateway) ist einServer, über den der gesamte Verkehr zwischen einer Or-ganisation und dem Rest der Welt läuft. Er befindet sichtypischerweise in der DMZ (Demilitarisierte Zone), ei-nem Subnetz zwischen internem Netz und Internet, in dasman nur über den Firewall gelangt (siehe Abbildung 1).An dieser Stelle können in einfacher Weise Überprüfun-gen auf Applikationsebene ausgeführt werden. Dazu kön-nen Sicherheitsüberprüfungen (Mail-Relaying, Viren-scans), das Einschränken der Funktionalität aus Sicher-heitsgründen (z. B. Blockieren von Java) und Ähnlicheszählen.

Ein Mail-Bastionsrechner beschränkt sich auf dieÜberprüfung des Mail-Verkehrs, in unserem Fall auf vonaußen in das TUNET über das SMTP-Protokoll einlan-gende Mails. Zu den typischen Aufgaben eines Mail-Ba-stionsrechners gehören die Verhinderung von Mail-Relaying, Virenscans und das Abweisen von Spam-Mailaufgrund von „schwarzen Listen“. An der TU Wien wer-den wir uns vorerst auf die Verhinderung von Mail-Re-laying beschränken. Weitere Funktionalität könnte bei


3 http://www.zid.tuwien.ac.at/security/policies.html4 „simple message transfer protocol“, siehe http://www.sendmail.org/5 siehe http://www.sendmail.org/6 ORBS, or the Open Relay Behaviour-modification System, is a database for tracking SMTP servers that have been confirmed to permit third-partyrelay. These servers permit spammers to connect to them from anywhere in the world, usually from a modem connection, and then forward the spam toits intended victims. (http://www.orbs.org/)

Bedarf und nach Klärung der technischen Umsetzbarkeitfolgen. Bastionsrechner werden aus Gründen der Ausfall-sicherheit und des Lastausgleichs oft in redundanter Kon-figuration (d. h. mit mehr als einer Maschine) ausgelegt.

Implementation des Mail-Bastionsrechnersan der TU Wien (tuvok.kom.tuwien.ac.at )

Die gesamte von außen ins TUNET einlangende Mailmit Ausnahme der generisch adressierten ([email protected]) wird über denMail-Bastionsrechner umgeleitet. Die Umleitung ge-schieht mittels des Domain Name Service (DNS). (WennSie Interesse an den Details haben, finden Sie diese amEnde des Artikels in den „technischen Hintergründen“.)Am Mail-Bastionsrechner läuft die jeweils aktuelle Versi-on des Mailserverprogramms „sendmail“, von dem ver-suchtes Mail-Relaying erkannt und verhindert wird. Mailan Adressaten in der TU Wien wird unverändert an dieEmpfänger weitergeleitet, Mail an Adressaten außerhalbder TU Wien wird abgelehnt.

Zusätzlich zu dieser Maßnahme muss auch der vonSMTP verwendete Port 25/tcp am Firewall gesperrt wer-den, um zu verhindern, dass Spammer unter Umgehungdes DNS direkt Mail versenden.

Diese Sperre betrifft auch Benutzer, die von außerhalbder TU Wien (Ausnahme: bei Verwendung des Einwähl-service der TU Wien oder TU Wien-Chello) einen Mail-server an der TU Wien zum Versenden von Mailverwenden wollen. Zum Versenden von Mail müssen siein Zukunft als „Ausgehenden Mailserver“ („OutgoingMail Server“) den Mailserver des verwendeten Providersangeben. Wenn die im Mail-Client angegebene Mail-adresse nicht geändert wird, kommen weiterhin alle Ant-worten auf den Mailserver an der TU Wien. Um ganzsicher zu gehen, kann zusätzlich im Mail-Client die ge-wünschte Mailadresse im Feld „Reply-to address“ ange-geben werden.

Die Einschränkung beim Absenden kann auch umgan-gen werden, indem man sich direkt auf den (Instituts-)Mailserver einloggt (z. B. mit SSH) und einen lokalenMailclient verwendet.

Weiterhin uneingeschränkt möglich ist das Lesen vonMail von (Instituts-)Mailservern auf der TU Wien. (DieProtokolle POP und IMAP sind von der Sperre nicht be-troffen.)

Wie erfolgt die Umstellung ?

Wir planen, die Umstellung schrittweise (Subnetz fürSubnetz) aber zügig bis zum Jahresende durchzuführen.Die für die IT-Infrastruktur verantwortlichen Ansprech-partner des ZID an den Instituten werden in diesen Wo-chen von uns mit der Bitte kontaktiert, die Namen derInstituts-Mailserver bekanntzugeben. Nochmals sei da-rauf hingewiesen, dass Rechner, die nur instituts- oderuniversitätsweit agieren, oder solche, die Mail nur ver-senden, nicht aber empfangen sollen (z. B. um Ergebnissevon Berechnungen zu verschicken), nicht auf diese Listegehören.

Für eine reibungslose Umstellung wäre uns sehr ge-holfen, wenn die Institute möglichst früh eine Liste derbenötigten Rechner erstellen könnten. Wichtig ist dabeiauch, alle Aliasnamen für den Mailserver anzugeben,


Abbildung 2:Beispiel: Einstellungen in Netscape Messenger

externer Mail-Server

[email protected]

Mail-Server an der TU Wien

SD

POWER NETWORKACT

PIX FirewallSERIESCISCO SYSTEMS

Firewall

Bastionsrechnerder TU Wien

in DMZ

[email protected]

[email protected]

Abbildung 1

unter denen Mail empfangen wird (z. B. Rechner server.e999.tuwien.ac.at heißt auch www.e999.tuwien.ac.at). ZurHilfestellung werden wir eine Liste mit den derzeit in derTUNET-Datenbank eingetragenen Mailservern des Insti-tuts und eine Kurzfassung dieses Artikels zur Verfügungstellen. Nachdem diese Änderungen von den Mitarbeiterndes ZID in die TUNET-Datenbank eingetragen sein wer-den, tritt die Umleitung über den Bastionsrechner inKraft. Institute, die bereits in die Verwendung der TU-NET-Datenbank eingeschult worden sind, können durchEintragung des neuen Attributs „BIND/BASTION“ dienötige Adaption selbst vornehmen. Für alle offenen Fra-gen stehen unsere Mitarbeiter natürlich gerne bereit(Kontakte siehe unten).

Mailserver im TUNET, die nicht in derDomäne tuwien.ac.at liegen

Der ZID der TU Wien als Betreiber des TUNET istverpflichtet, das Domain Name Service für die Domänetuwien.ac.at zu unterhalten. Wenn berechtigtes Allge-meininteresse besteht (vor allem für interuniversitäre Be-lange), kann in Abkommen Organisationen gestattetwerden, Services auf Rechnern zu betreiben, die zusätz-lich zum Domänennamen tuwien.ac.at auch andere Do-mänennamen führen (z. B. für den Lehrzielkatalog derServer nexus.lzk.tuwien.ac.at und www.lzk.ac.at). Dieverantwortlichen Organisationen sind verpflichtet, für dievon ihnen unterhaltenen Domänen das Domain NameService (DNS) selbst zu betreiben. Aufgrund dieser Tat-sache sind solche Server von der Verwendung des Mail-Bastionsrechners ausgeschlossen. Für allfällige Fragenstehen wir dabei natürlich gerne mit Rat und Tat bereit.

Ansprechpartner

Fragen zum Mail-Bastionsrechner:Elisabeth Donnaberger

Kl. 42042 [email protected] Haider

Kl. 42043 [email protected]

Fragen zur TUNET-Datenbank:[email protected]

Technischer Hintergrund

Mail-Relaying (Routing)

Zum Verständnis der Spam-Problematik betrachtenwir die Stationen einer Mail zwischen Absender undEmpfängerin an einem Beispiel (siehe Abbildung 3).Hans ([email protected]) möchte eine Mail an Anna([email protected]) schicken. Er editiert den Text inseinem Mail-Programm (Mail user agent = MUA, z. B.Eudora) und drückt den Send-Button. Sein MUA kontak-tiert den lokalen SMTP-Server (Mail transfer agent =MTA, z. B. sendmail, MS Exchange) – in unserem Falleinen Abteilungs-Mailserver – und überträgt die Mailüber das SMTP-Protokoll auf diesen. Der Abteilungs-Mailserver muss jetzt entscheiden, wohin er die Mailweiterschicken soll. Die Auswahl des nächsten MTAs er-folgt über das „Domain Name Service“ (DNS) und kon-kret über ein spezielles Attribut desselbigen, den sogenannten Mail eXchanger (MX) Record 7.

Es können auch mehrere MX-Records für dasselbeZiel eingetragen werden, um alternative, redundante Rou-ten zum Ziel zu definieren. In der Regel wird die Maildirekt an den „Eingehenden Mailserver“ („Incoming MailServer“) von Anna geschickt und dort in ihrer Mailboxabgelegt. Die Mail kann aber, wie in unserem Beispiel,zuerst an dem zentralen Mailrouter ankommen, wo dieAdresse umgeschrieben wird und die Mail an einen Insti-tutsmailserver weiter geschickt wird. Jeder der MTAs inder Kette bis auf den letzten agiert als Mail-Relay. An-nas MUA (z. B. MS Outlook) kontaktiert nun ihren „In-coming Mailserver“ über eines der gängigen Protokolle(POP, IMAP) und zeigt Hansis Mail an.

So weit, so gut. MTAs werden in der Regel von Orga-nisationen betrieben (z. B. TU Wien). Ihre Aufgabe ausder Sicht der Organisation besteht neben der internenKommunikation darin, Mail von Absendern in der Orga-nisation an Externe und Mail von externen Absendern anAngehörige der Organisation zuzustellen. Nicht er-wünscht ist das Weiterleiten von Mail von Externen anExterne (siehe Abbildung 4). Ganz offensichtlich hat derServerbetreiber davon keinen Nutzen, obwohl seine Res-sourcen verwendet werden. MTAs, die von einem exter-nen Absender zu einem externen Empfänger weiterleiten,nennen wir offene Mail-Relays.


MTA(Instituts-

Mail-Server)

MTAmr.tuwien.ac.at

(TU Wien-Mail-Server)

MTA(Firmen-

Mail-Server)

MTA(Abteilungs-Mail-Server)

MUA([email protected]) MUA

([email protected])

SD

POWER NETWORKACT


Firewall

Abbildung 3: Good Relay

7 siehe RFC 974 (http://info.internet.isi.edu:80/in-notes/rfc/files/rfc974.txt)

Offene Mail-Relays wurden in den letzten Jahren zu-nehmend für das Versenden von Spam-Mail missbrauchtund das Belassen eines solchen Zustandes durch die ver-antwortlichen Administratoren betrachten die Empfängervon Spam-Mail als Fehlverhalten. Außerdem können, wiebereits erwähnt, Mailserver und Netz durch offene Mail-Relays schwer belastet werden. Prinzipiell kann jeder ge-bräuchliche SMTP-Server so konfiguriert werden, dasseine Verwendung durch Unbefugte unterbunden ist. DerAufwand dafür ist jedoch ziemlich hoch, da es sich umhoch komplexe Programme handelt und Spammer immerwieder neue Schwächen entdecken. (Als Beispiel sei derschnelle Versionswechsel bei sendmail genannt.)

Spam-Mail

Was kann man gegen Spam-Mail unternehmen ?

Wie wir wissen, zeitigt weder die Aufforderung zurUnterlassung noch die Androhung von Rechtsmitteln daserwünschte Ergebnis. Ironischerweise sind die Absenderoft gar nicht über Mail erreichbar. Erfolgsversprechendersind einige technische Ansätze, die darauf zielen, entwe-der das Versenden oder die Annahme beziehungsweisedie Zustellung von Spam-Mail zu verhindern. Das Ver-hindern des Versendens ist das bessere Konzept, da derVerkehr minimiert wird. Zum Versenden werden vonSpammern meistens „fremde“ Server mit offenen MailRelays verwendet. Um das zu verhindern benötigt jederServer die aktuelle Version der Mailserversoftware, diedarüber hinaus richtig konfiguriert sein muss. Als Alter-native bietet sich ein Mail-Bastionsrechner an, der alleMailserver einer Organisation an zentraler Stelle schützt.

Der Empfang von Spam-Mail kann durch Überprüfungder Absender anhand „schwarzer Listen“ verhindert wer-den. (Die ORBS-Liste führt momentan über 150 000Mailserver mit offenem Mail-Relay.) Mail von Absen-

dern (Mailservern) auf der Liste wird nicht zugestellt.Natürlich sind nicht nur die Spammer, sondern alle Per-sonen, die diesen Mailserver verwenden, von der Maß-nahme betroffen. Eine weitere Methode ist das auto-matische Kopieren der eingehenden Spam-Mail in einendafür vorgesehenen Mail-Folder mittels eines Filter-Pro-gramms (z. B. procmail). Damit erspart man sich zumin-dest das Lesen der Spam-Mail.

Mail-Bastionsrechner� Domain Name Service(DNS) an der TU Wien

Das Domain Name Service DNS ist ein Dienst, derRechnernamen bzw. Internet-Adressen im Klartext (z. B.www.tuwien.ac.at) und IP-Adressen (z. B. 128.130.2.9)einander zuordnet. Für jeden Rechner beziehungsweisefür jedes Netzwerk im Internet muss ein DNS-Server die-se Informationen verwalten. Bevor eine beliebige Verbin-dung zu einem Server im Internet aufgebaut wird,kontaktiert das Client-Programm einen Domain NameServer. Dieser meldet die entsprechende numerischeAdresse zurück, worauf der Client die Verbindung zurIP-Adresse aufbauen kann.

Im Zuge der Implementierung des Firewallkonzepts istes auch zu Veränderungen im Domain Name Service(DNS) der TU Wien gekommen. Bis vor kurzem(01. 10. 2000) wurden alle Anfragen, gleichgültig, ob ausdem TUNET oder von einem externen Host, von den bei-den Nameservern (tunamea.tuwien.ac.at und tunameb.tuwien.ac.at) bearbeitet, deren Datenbestand aus den Ein-trägen in der TUNET-Datenbank generiert wird. Eineeinheitliche Sicht ist die einfachste, in vielen Belangenaber nicht optimale Lösung. So gibt es viele Rechner, dievon außen nicht zugänglich sein und damit auch nicht be-kanntgegeben werden müssen (mein Windows-PC etwa).Rechner können in der externen Sicht andere Attribute(z. B. MX-Records) haben als in der internen. Und


externer Mail-Server

[email protected]

[email protected]

SD

POWER NETWORKACT


Firewall

Mail-Server an der TU Wien

[email protected]

Abbildung 4: Bad Relay

schließlich kann ein Computer in der externen Sicht eineandere IP-Adresse haben als in der internen (NAT, IP-Masquerading), sei es aus Sicherheitsgründen, sei es umteure offizielle IP-Adressen zu sparen. Die Darstellungunterschiedlicher Sichtweisen erreicht man am bestendurch die Trennung in Nameserver für externe Anfragen(tunamec.tuwien.ac.at und tunamed.tuwien.ac.at) undsolche für interne (tunamea.tuwien.ac.at und tunameb.tuwien.ac.at). Externe Anfragen an die internen Nameser-ver werden untersagt.

Auch bei der Implementierung des Mail-Bastionsrech-ners spielt das Domain Name Service eine bedeutendeRolle. Es kommt dabei ein ähnlicher Mechanismus zumEinsatz, wie er bereits für die Zustellung von generischenMail-Adressen ([email protected]) verwendet wird. Mail mit generischer Adressierungwird zuerst an den zentralen Mailrouter mr.tuwien.ac.atumgeleitet. Dort wird die Zieladresse anhand der Datenaus den White Pages von der ursprünglichen (allgemei-nen oder generischen) in die RFC 822 Mail-Adresse um-geschrieben. Dann wird die Mail an den in der RFC 822Mail-Adresse angegebenen (Instituts-)Mailserver weiter-geleitet.

Eine derartige Umleitung wird in Zukunft auch fürden restlichen Mailverkehr vorgenommen. Sie erfolgtüber auf den Mail-Bastionsrechner lautende MX-Records.

Es muss für jeden Mailserver (eigentlich für jeden Mail-namen, unter dem der Mailserver Mail empfangen soll)das Attribut „BIND/BASTION“ in die TUNET-Daten-bank eingetragen werden. Damit wird eine alternativeRoute für die Mailzustellung definiert. Der Wert für denMX-Record wird so gewählt, dass zuerst die Route überden Mail-Bastionsrechner ausprobiert wird (höhere Prio-rität). Diese Methode gewährleistet die Zustellung unab-hängig von der Verfügbarkeit des Mail-Bastionsrech-ners. Diese MX-Records werden nur auf den neu geschaf-fenen externen Nameservern (tunamec.tuwien.ac.at undtunamed.tuwien.ac.at) eingetragen, das heißt nur von au-ßen einlangende Mail wird über den Mail-Bastionsrech-ner geleitet.

Literatur

E-mail Explainedhttp://www.sendmail.org/email-explained.html

Martin Rathmayer: Mißbrauch von Mail-Servern an derTU Wien, Pipeline 24, Februar 1998http://www.tuwien.ac.at/pipeline/p24/mailmiss.html

Elisabeth Donnaberger, Johann Kainrath: Firewall undInternet Security an der TU Wien, ZIDline 1, Juni1999, http://www.zid.tuwien.ac.at/zidline/zl01/firewall.html


Server-Zertifikatedes Zentralen InformatikdienstesTU Testzertifizierungsstelle:http://www.zid.tuwien.ac.at/security/testca/

Fingerprints der Test-CAs und der von ihnen ausge-gebenen Serverzertifikate:

Zertifikat der Root-Test-CA (PCA)gültig von Dec 30 1999 bis Dec 26 20140D:D9:02:9C:24:61:85:9E:72:59:93:28:68:3D:B3:7C

Zertifikat der Server-Test-CA (SCA)gültig von Dec 30 1999 bis Dec 27 200903:2F:CB:C6:B6:5B:FC:00:C0:56:41:DF:CD:E9:AF:98

Zertifikat der User-Test-CA (UCA)gültig von Dec 30 1999 bis Dec 27 20093C:B3:AC:1F:83:D0:C9:1E:3E:11:31:53:A0:F3:C9:88

Server-Zertifikat von verman.zserv.tuwien.ac.atgültig von Nov 19 2000 bis Nov 19 2001D8:A1:57:94:1E:D6:E3:EB:7D:1B:C7:9F:6B:8C:3F:1E

Server-Zertifikat von stud3.tuwien.ac.atgültig von Nov 20 2000 bis Nov 20 200104:CE:1E:67:57:EB:80:A0:C1:EB:0D:11:05:12:52:99

Server-Zertifikat von stud4.tuwien.ac.atgültig von Nov 20 2000 bis Nov 20 2001DB:47:20:4A:A7:90:DE:5D:D5:2B:6C:BD:CF:02:D2:21

Fingerprints der „self signed“ Serverzertifikate:

Server-Zertifikat voninfo.tuwien.ac.at (Informationsserver für die TU Wien)gültig bis Mar 27 2001

AC:3A:17:EC:76:F8:E6:3C:21:89:D6:3D:54:91:19:80

Server-Zertifikat vonswd.tuwien.ac.at (Campussoftware Verteilung)gültig bis May 25 2001

A0:DB:78:1A:02:19:DD:99:A5:19:51:B9:86:32:35:87

Server-Zertifikat voniu.zid.tuwien.ac.at (Campussoftware Verwaltung)gültig bis Mar 1 2002

A0:FF:97:E3:25:5D:07:B9:20:CC:84:D6:88:05:EB:0F

Entwicklung der Daten- undTelekommunikationsinfrastruktur

zur Institutsversorgungan der TU WienWolfgang Meyer

Die Daten- und Telekommunikationsverkabelung stellt einen wichtigen Teil der Gebäude-infrastruktur der Technischen Universität Wien dar. Es werden die aktuellen Entwicklungenauf dem Gebiet der Verkabelungstechnik und der darauf aufbauenden Netzwerktechnologienfür die Institutsversorgung dargestellt und die sich daraus ergebenden Anforderungen undMöglichkeiten aufgezeigt.

Historische EntwicklungBasierend auf dem Beschluss des Akademischen Se-

nats vom Jänner 1985 über die Errichtung von TUNETzur flächendeckenden Versorgung der TU Wien mit Da-tenkommunikation wurde begonnen, den Instituten EDV-Dienstleistung auf Basis von Terminalzugängen zu zen-tralen Rechnersystemen zur Verfügung zu stellen. Ab1989 wurde schrittweise Local Area Network Technolo-gie auf Basis von Ethernet zur flächendeckenden Versor-gung der Institute mit Datenkommunikationsanschlüsseneingesetzt.

Thinwire – Thickwire

Die für die Institutsversorgung meist zum Einsatz ge-langende Netzwerktechnologie – 10Base2-Ethernet aufThinwire Kabeln – erforderte die Verlegung von Koaxial-kabeln mit ca. 6 mm Durchmesser – Thinwire – in Formeines maximal 185 m langen Segments. Diese Segmentewurden dem damaligen Stand der Technik entsprechenddurch aktive Komponenten – Repeater – verbunden. Re-peater verbinden diese Segmente elektrisch und sorgenfür eine Signalregeneration. Diese Repeater von der Grö-ße eines kleineren PC-Gehäuses können relativ leicht invorhandenen Installationsschächten oder ähnlichen Stel-len untergebracht werden, siehe Abbildung 1.

Die weitere Verbindung innerhalb der Gebäude undzum Teil auch Gebäudeverbindungen wurden mit10Base5-Thickwire („dickes gelbes Kabel“) mit maximal500 m Segmentlänge realisiert. Damit konnten, dem da-maligen Stand der Technik entsprechend, mit geringemVerkabelungsaufwand weite Bereiche relativ schnell mitDatenkommunikationsanschlüssen versorgt werden. DieseTechnologie bietet mehrere Vorteile:


Abbildung 1: Thinwire-Repeaterin einem Installationsschacht montiert.

• Durch die Bustechnologie ist die Verlegung nur einesKabels von einem Anschlusspunkt zum nächsten erfor-derlich.

• In Kombination mit dem relativ dünnen Kabel wird dieInstallation sehr vereinfacht und es können in vielen Fäl-len vorhandene Tragsysteme, Rohre und Durchbrücheverwendet werden.

• Dort wo die Neuverlegung eines Kabelkanals unerläss-lich ist, kann ein sehr kleiner, optisch unauffälliger Ka-nalquerschnitt eingesetzt werden, wodurch die In-stallation auch in ansprechend gestalteten, historischwertvollen Räumen sehr erleichtert wird.

• Das Steckersystem ist leicht und schnell vor Ort konfek-tionierbar.

• Durch die Bustopologie ist es mittels Erweiterung der An-schlussgarnitur leicht möglich, ohne weitere Zusatzgerätean eine Anschlussdose mehrere Geräte anzuschließen.

Für die Anforderungen der frühen 90er Jahre war dieBandbreite von 10 MBit/s für alle an einem Segment an-geschlossenen Geräte gemeinsam bei weitem ausrei-chend.

Besonders aus heutiger Sicht sind mit dieser Form derVerkabelung aber auch massive Nachteile verbunden:

• Durch die Bustopologie führt ein Defekt an einer einzi-gen Steckverbindung zum Ausfall des gesamten Seg-ments, wodurch alle an diesem Segment angeschlos-senen Geräte betroffen sind. Diese Tatsache erschwertauch die Fehleranalyse.

• Die Steckverbindungen unterliegen einer signifikantenAlterung. Mit zunehmendem Alter der Verkabelungsteigt die Fehleranfälligkeit stark an.

• Durch den gemeinsamen Zugriff auf ein Kabel für meh-rere angeschlossene Endsysteme besteht prinzipiell dieMöglichkeit des Mithörens.

Die für alle Systeme gemeinsam zur Verfügung ste-hende Netzwerkbandbreite von 10 MBit/s ist für heutigeAnforderungen nicht mehr ausreichend. 10 MBit/s ent-spricht bei schnellstmöglicher Datenübertragung zwi-schen zwei Systemen z. B. mit FTP einem Durchsatz von700-900 KByte/s. Jedes heute gängige Computersystemist in der Lage, die zur Verfügung stehende Bandbreitekomplett zu nutzen, wodurch im Falle der Überlastungdie Geschwindigkeit der Übertragung für alle angeschlos-senen System drastisch beeinträchtigt wird.

Verbesserung durch Lasttrennung mit Bridges

Eine Bridge ist eine aktive Netzwerkkomponente, diein der Lage ist, Tabellen von Ethernetadressen – auchMAC-Adressen genannt – zu verwalten. Diese Ethernet-adressen, 48 Bit lang, sind weltweit eindeutig und einemNetzwerkinterface in einem Computersystem, z. B. einerNetzkarte, zugeordnet. Auf Basis dieser Adressen wirddie Kommunikation mit Ethernetpaketen – Frames – ineinem LAN – Local Area Network – abgewickelt. EineBridge verfügt typischerweise über zwei Anschlüsse fürEthernetsegmente. Die Bridge lernt durch Beobachtungdes Netzwerkverkehrs, welche Ethernetadressen welchemSegment zuzuordnen sind, und verwaltet entsprechendeTabellen. Dadurch ist eine Bridge in der Lage zu filternund Verkehr vom einen in das andere Segment nur dannweiterzuleiten, wenn die Zieladresse im anderen Segmentzu finden ist, siehe Abbildung 2.

Diese Eigenschaft ermöglicht das Auftrennen von Seg-menten und das Abschotten von Bereichen, die lokal sehrviel Netzwerkverkehr produzieren.

Repeater und Bridges zur Institutsversorgung sindnoch in manchen Gebäudeteilen – besonders an denStandorten Hauptgebäude, Getreidemarkt sowie an klei-neren Standorten wie Argentinierstraße, Karlsgasse, The-resianumgasse und Gußhausstraße 28 – in Betrieb.

Verkabelung nach EN50173Ab 1994 wurden größere Bereiche der Institutsversor-

gung nur mehr entsprechend dem damaligen Norment-wurf und der späteren Norm EN50173 (Informations-technik anwendungsneutrale Verkabelungssysteme) aufBasis von Kupferkabeln der Kategorie 5 neu errichtet.Dadurch war in der Verkabelung eine völlige Neuorien-tierung erforderlich. Diese Norm gliedert die Verkabe-lung hierarchisch in Teilbereiche:

Primäre Verkabelung: Verbindungen zwischen denGebäudeverteilern bzw. Standortverteilern

Sekundäre Verkabelung: Verbindungen der Gebäude-verteiler mit den Etagenverteilern

Tertiäre Verkabelung: Verbindungen von denEtagenverteilern zu den informationstechnischenAnschlüssen


GV

EV

SVEV

EVEV

EV

EV

GV/EV

EV

EV

TA

TATA

TATA

TA

Primäre Verkabelung

Sekundäre Verkabelung

Tertiäre Verkabelung

TA ... Endsystem (z.B. Arbeitsplatzrechner)

EV ... Etagenverteiler

GV ... Gebäudeverteiler

SV... Standortverteiler

Abbildung 3: Prinzip der Verkabelung nach EN50173

. . . . . .A C

Quelladresse Zieladresse

. . . . . .A B

Quelladresse Zieladresse

Ethernetframes

Bridge

A

C

.

.

.

.

B

.

.

.

.

.

Segment 1 Segment 2

Adress TabelleSegment 1Adress TabelleSegment 1

Adress TabelleSegment 2

Abbildung 2: Funktionsweise einer Ethernet-Bridge

Während für die Primär- und die Sekundärverkabelungwegen der Anforderung, größere Distanzen mit entspre-chenden Bandbreiten zu überwinden, der Einsatz vonLichtwellenleitern zwingend ist, wurden für die Tertiär-verkabelung die Einsatzmöglichkeiten von Lichtwellen-leitern und Kupferkabeln der Kategorie 5 miteinanderverglichen. Wegen des günstigeren Preises der aktivenKomponenten und der Interfacekarten auf der Seite derEndsysteme wurden bereits zu einem sehr frühen Zeit-punkt an der TU Wien die Weichen in Richtung flächen-deckende Versorgung mit strukturierter Verkabelung aufBasis von Kupferkabeln der Kategorie 5 gestellt. Diezum Einsatz gelangenden Kabel der Kategorie 5 bestehenaus 4 Paaren, wobei jedes Paar verdrillt („twisted pair“)ist, um die Übertragungseigenschaften zu verbessern. Deran der TU Wien ausschließlich verlegte Typ, ein so ge-nanntes Shielded-Shielded-Twisted-Pair-Kabel – SSTP –ist etwas aufwendiger aufgebaut. Jedes Paar wird von ei-ner Schirmung geschützt und alle Paare werden gemein-sam noch einmal von einem Schirm umschlossen, sieheAbbildung 4.

Dieser Kabelaufbau gewährleistet im Gegensatz zuden vor allem im angloamerikanischen Raum verbreitetenUnshielded-Twisted-Pair-Kabeln eine besonders störungs-unempfindliche Signalübertragung.

Die an der TU Wien eingesetzten Kabel sind beson-ders hochwertig und übertreffen die geforderten Werte imBereich der Übertragungsparameter bei weitem. Alle ander TU Wien verlegten Twisted-Pair-Kabel sind im Ge-gensatz zur Kategorie 5 Norm mit 100 MHz mindestensfür 300 MHz geeignet, um zukünftigen Anforderungengerecht zu werden.

Strukturierte Verkabelung

Eine der Norm EN50173 entsprechende Tertiärverka-belung erfordert die Verlegung eines Kabels von einemEtagenverteiler zu jedem Anschlusspunkt. Damit ergebensich gegenüber der oben beschriebenen Thinwire-Verka-belung gravierende Änderungen. Da zu jedem Anschluss-punkt ein eigenes Kabel verlegt werden muss, sindentsprechend umfangreiche Tragsysteme, Kabeltassenund Kabelkanäle erforderlich, die mit entsprechendembaulichem Aufwand erst neu errichtet werden müssen. Inden sternförmigen Endpunkten, den Etagenverteilern, ist

genügend Platz zur Aufnahme von 19 Zoll Schränkennotwendig, um einerseits die hohe Anzahl von Twisted-Pair-Kabeln aufführen zu können und andererseits dieUnterbringung der aktiven Netzwerkkomponenten zu er-möglichen. Diese Etagenverteiler mit einem typischenFlächenbedarf von 4-6 m2 müssen möglichst im Zentrumdes zu versorgenden Bereichs platziert werden, da diemaximale Länge eines Kabels von der Norm mit 90 mfix vorgegeben ist und unter keinen Umständen über-schritten werden darf. Da an der TU Wien Nutzflächeneine kostbare Ressource sind, ist es meist nicht einfach,in Zusammenarbeit mit den Nutzern in den betroffenenBereichen geeignete Standorte für diese Etagenverteilerzu finden, die – auch um Wartungsarbeiten zu erleich-tern – direkt von einem Gang aus zugänglich sein müs-sen. In vielen Fällen müssen diese Etagenverteiler erstdurch Abmauern von Gangnischen oder Nutzung vongrößeren Installationsschächten oder Wandverkleidungs-nischen gewonnen werden, wobei vor allem in den erstenJahren des Ausbaus der strukturierten Verkabelung ausRaumnot oft mehr improvisierte als wirklich gut geeigne-te Lösungen entstanden sind.

Trotz der aufwendigen und manchmal nicht unproble-matischen Installation weist diese sternförmige Verkabe-lung aber prinzipbedingt einige wichtige Vorteile auf:

• Da jeder Anschluss über ein eigenes Kabel verfügt, wir-ken sich Störungen auf einem Anschluss nicht unmittel-bar auf einen benachbarten Anschluss aus.

• Je nach eingesetzter aktiver Netzwerkkomponente ist esmöglich, jedem Anschluss eine von anderen Anschlüs-sen unabhängige Bandbreite zur Verfügung zu stellen.

Damit ist diese sternförmige strukturierte Verkabelungwesentlich stabiler im Betrieb und zukunftsicherer in Be-zug auf zukünftige Entwicklungen.

Der Nachteil, der sich aus der aufwendigen Installati-on ergebende höhere Preis der Errichtung einer struktu-rierten Verkabelung, wird aber durch die Vorteile inBezug auf Leistungsfähigkeit, Betriebsstabilität und Zu-kunftsicherheit mehr als aufgewogen.

Dosen, Stecker und Patchkabel

Aus Kostengründen werden ausschließlich Doppeldo-sen mit zwei RJ-45 Buchsen installiert. An jede Dosekönnen daher mittels Patchkabel zwei Endsysteme direktangeschlossen werden. Die Qualität dieser Patchkabel istausschlaggebend für die Qualität der Übertragung, dieauf der gesamten Übertragungsstrecke („Link“) vomEndsystem bis zur aktiven Netzwerkkomponente erreichtwerden kann.

Der bei Patchkabeln zum Einsatz gelangende Kabeltypist einfacher, mit geringerem Durchmesser aufgebaut, fürdie Montage von RJ-45 Steckern geeignet, und ist damitdurch das biegsamere dünnere Kabel für den Anschlussvon Endgeräten leichter handhabbar, siehe Abbildung 5rechts. Flachbandkabel, siehe Abbildung 5 links, eventu-ell ebenfalls mit passendem RJ-45 Stecker konfektioniert,wie sie teilweise für den Anschluss von Telefonen oderISDN Endgeräten verwendet werden, sind definitiv fürdie Anforderungen der Datenkommunikation nicht geeig-net und dürfen keinesfalls verwendet werden.


Abbildung 4: Aufbau eines Shielded-Shielded-Twisted-Pair-Kabels.

Als Übertragungstechnik wird auf diesen Twisted-Pair-Kabeln zum Anschluss von Endsystemen im Bereich derTU Wien ausschließlich Ethernet mit 10 MBit/s 10Base-T-Ethernet oder 100 MBit/s 100Base-TX-Ethernet eingesetzt.Diese beiden Übertragungsverfahren benötigen nur zweider vier in einem Kategorie 5 Kabel vorhandenen Adern-paare. Die besonders in der Anfangszeit der Errichtungstrukturierter Verkabelung hohen Kosten und die Tatsache,dass bis etwa 1998 keine Übertragungstechnologie für denEinsatz im TUNET relevant war, die alle vier Paare fürdie Übertragung gleichzeitig benötigt hätte, führte zu einerInstallationsform, die nur ein Kabel pro Doppeldose erfor-derte und als „halb aufgelegt“ bezeichnet wird. Hierbeiwerden zwei Paare des vierpaarigen Kategorie 5 Kabelsauf dem linken Anschluss und zwei Paar auf dem rechtenAnschluss aufgeschaltet. Seit 1998 werden keine halb auf-gelegten Anschlüsse mehr errichtet, sondern es werden anjede Doppeldose grundsätzlich zwei Kabel herangeführtund alle vier Paare pro Anschluss beschaltet („voll aufge-legt“). Dies wird in Zukunft auch den Einsatz von GigabitEthernet über Kategorie 5 Kabel ermöglichen, wobei allevier Adernpaare zur Übertragung gleichzeitig genutzt wer-den müssen.

Dosenbeschriftung an der TU Wien

Um die Anschlüsse auf den Twisted-Pair-Anschluss-dosen eindeutig zu identifizieren, wird auf jeder Doseeine Beschriftung angebracht.

TP: Bezeichnung eines Twisted-Pair-Kabelsnach TUNET Konvention

DC02O12: Raumcode der TU Wien in diesem BeispielDC: Freihaus roter Bereich02: 2. StockO12: Raumbezeichnungfortlaufende Anschlussnummer innerhalb eines Raumes1: linker Anschluss2: rechter Anschluss

TP-BH0109: Twisted-Pair-Kabel und Raumcode wie oben-1: fortlaufende Dosennummer innerhalb eines

RaumesA: linker AnschlussB: rechter Anschluss

Aufgrund dieser Bezeichnung kann daher die Art der Be-schaltung abgeleitet werden.

Telefonieverkabelung

Anschlussdosen, die ausschließlich für Telekommuni-kation verwendet werden können, siehe Abbildung 5links, sind mit „TK-“, Raumcode und fortlaufender Num-mer wie oben bezeichnet. Da eine Telekommunikations-anschlussdose üblicherweise nur von einem Adernpaarversorgt wird, ist nur der linke der beiden Anschlüsse ak-tiv und kann zum Anschluss eines Endgerätes, in der Re-gel eines Telefons, verwendet werden.

In allen Bereichen, wo seit 1998 in größerem Umfangstrukturierte Verkabelung neu errichtet wurde, wird dieseVerkabelung auch für die Telefonie benutzt. Es ist aufden 4-paarigen Twisted-Pair-Kabeln technisch leichtmöglich, sowohl 2-Draht Telefoniedienste als auch 2-Draht ISDN Dienste oder einen 4-Draht ISDN S0-Bus di-rekt an einen Arbeitsplatz heranzuführen.

An den Twisted-Pair-Anschlüssen, die für Telefoniegenutzt werden sollen, werden kleine Einsätze montiert,die den kleineren RJ11-Steckern, die für den Anschlussvon Telefonen Verwendung finden, angepasst sind. Da-durch soll, auch um Beschädigungen von Endgeräten zuvermeiden, verhindert werden, dass an Anschlüsse, diefür Telefone beschaltet sind, irrtümlich Endgeräte für Da-tenkommunikation angeschlossen werden.


Abbildung 6: Twisted-Pair-Anschlussdose, voll aufgelegt

Abbildung 7: Halb aufgelegte Anschlussdose

Abbildung 5: Links, Anschlussdose fürTelekommunikationsendgeräte, Telefone geeignet.

Rechts, Twisted-Pair-Anschlussdose für Datenkommunikation.

Durch die Versorgung von einem zentralen Punkt,dem Etagenverteiler aus, ist volle Flexibilität bei Verän-derungen von Standorten oder Neuerrichtungen von Tele-fonanschlüssen gegeben. Dies ist ein besonders in einemdynamischen universitären Umfeld wichtiger Aspekt.

Aktive Komponenten auf strukturierterVerkabelung

Für die Versorgung strukturierter Verkabelung durchaktive Komponenten gibt es grundsätzlich die Möglich-keit, so wie bei Thinwire-Verkabelung Repeater einzuset-zen. Diese Art der Versorgung, Repeater mit 10 MBit/s,wurde vor allem in den zu einem frühen Zeitpunkt mitstrukturierter Verkabelung ausgestatteten Bereichen ausKostengründen angewandt. Die prinzipellen Nachteile derVersorgung mit Repeatern bleiben dabei unverändert.Der gesamte Datenverkehr aller mittels eines Repeaterszu einem Segment zusammengefassten Anschlüsse ist aufallen Anschlüssen sichtbar, damit ist prinzipiell die Mög-lichkeit des Mithörens gegeben, und die Bandbreite von10 MBit/s steht nur einmal für alle angeschlossenen Sys-teme gemeinsam zur Verfügung.

In Fällen, wo die Anzahl der installierten Anschlüsse ineinem Raum für die Anzahl der zu betreibenden Endsyste-me nicht ausreicht, ist es, nach Prüfung der Gegebenheitendurch den ZID, prinzipiell möglich, Kleinrepeater direktan den Twisted-Pair-Anschlüssen in den Institutsbereichenzu betreiben. Dadurch kann zwar die Anzahl der zur Ver-fügung stehenden Anschlüsse erhöht werden, es müssenaber zusätzlich zur Problematik der geeigneten Verlegungeines Patchkabels von jedem Endsystem zu diesem Klein-repeater alle prinzipiellen Nachteile der Versorgung mitRepeatern in Kauf genommen werden.

Ethernet-Switche

Ab ca. 1997 wurde durch den raschen Fortschritt derNetzwerktechnik eine weitere Type von Netzwerkkompo-nenten vom Preis-/Leistungsverhältnis her relevant.Ethernet-Switche sind Multiport-Bridges. Sie funktionie-ren wie eine Bridge, nur verfügt der Switch über typi-scherweise 12 bis 48 Twisted-Pair-Anschlüsse. Für jedendieser Anschlüsse verwaltet der Switch, wie eine Bridge,Tabellen mit Ethernet MAC-Adressen und ist daher inder Lage, den Verkehr auf Basis der Ethernet Zieladressezu klassifizieren und nur auf den Anschluss (das Port)weiterzuleiten, an dem das Empfängersystem des Ether-netpaketes angeschlossen ist. Broadcast-Pakete erfahreneine spezielle Behandlung, da sie entsprechend der Defi-nition an alle Systeme innerhalb eines Segmentes einerBroadcastdomain weitergeleitet werden müssen. Die ein-zelnen Ports eines Switches sind durch eine sehr schnelleVerbindung (Backplane) miteinander verbunden, sodassein Switch in der Lage ist, mehrere Verkehrsströme mitder maximalen Geschwindigkeit der einzelnen Portsgleichzeitig weiterleiten zu können. Damit werden dieNachteile von Repeatern, Abhörmöglichkeiten und geteil-te Bandbreite für mehrere Anschlüsse, vermieden.

Grundsätzlich stehen Ethernet-Switche mit 10 MBit/sPorts und Ethernet-Switche 10/100 MBit/s Ports zur Ver-fügung, wobei 10/100 MBit/s Ports beide Geschwindig-keiten unterstützen. In der Standardkonfiguration wirddie Auswahl der maximalen Geschwindigkeit zwischendem angeschlossenen Netzwerkinterface des Endsystemsund dem Switchport automatisch ausgehandelt („autosen-sing“). Dieser Mechanismus funktioniert in den meistenFällen problemlos, es kann aber in Problemfällen aucheine fixe Einstellung vorgenommen werden.

Bei der Standardkonfiguration „half duplex“ kann derDatenverkehr auf einem Anschluss zu einem Zeitpunktnur in eine Richtung laufen, vom Switch zum Endsystemoder umgekehrt. Diese Einstellung ist für typische Ar-beitsplatzrechner sinnvoll. Für Serversysteme mit massi-vem Datentransfer in beide Richtungen kann dieKonfiguration auf „full duplex“ geändert werden, wo-durch der Datentransfer gleichzeitig in beide Richtungenermöglicht wird.

Da der Einsatz von Switches ein sehr effizientes Mit-tel zu Leistungssteigerung in lokalen Netzen ist, werdenin mit TUNET neu zu versorgenden Bereichen seit 1998fast ausschließlich Switche installiert, und wo möglichvorhandene Repeater durch Switche ersetzt.

Virtuelle LANs

Eine weitere Technologie, die eine wesentlich flexiblereGestaltung des Netzes ermöglicht, ist der Einsatz von vir-tuellen LANs (VLANs), Virtual Local Area Networks.

Ein Ethernetswitch ist in der Lage, jedes Port einemvirtuellen LAN auf Basis einer dreistelligen Nummer(VLAN-ID) zuzuordnen. Damit wird die Verbreitung desDatenverkehrs weiter eingeschränkt, da der Datenverkehrinnerhalb eines Switches prinzipiell auf ein VLAN be-schränkt bleibt. Auch Broadcasts werden nur innerhalbeines VLANs verbreitet. Diese Trennung in VLANs er-möglicht, durch die Zuordnung von unterschiedlichen or-ganisatorischen Einheiten (z. B. Instituten) zu unter-schiedlichen VLANs, mit einem Switch mehrere räum-lich benachbarte Bereiche logisch so zu trennen, dass derNetzwerkverkehr des einen Bereiches oder VLANs fürden anderen Bereich, das andere VLAN, vollständig un-sichtbar bleibt, siehe Abbildung 8.


Switch 1. Stock

Switch 2. StockVLAN1 für Institut 1

VLAN2 für Institut 2

. . . . . .

Abbildung 8: Switch mit 2 VLANs für 2 Institute

Es besteht ohne weitere netzwerktechnische Maßnah-men wie Routing – Weiterleitung von Datenpaketen aufBasis von IP-Adressen – keine Möglichkeit der Kommu-nikation zwischen unterschiedlichen VLANs, sodass jedeForm des Mithörens des Datenverkehrs eines anderenVLANs ausgeschlossen werden kann, auch wenn dieVersorgung physisch über den gleichen Switch läuft. DerEinsatz von VLANs unterstützt daher auch den Einsatzvon Firewalls, da bei passender Zuordnung von VLANszu den zwei Interfaces einer Firewall, von dieser Firewalldie vollständige Kontrolle über den Datenverkehr zwi-schen diesen VLANs ausgeübt werden kann. Diese ange-führten Möglichkeiten der Beschränkung und Kontrolledes Datenverkehrs stellen eine weitere signifikante Ver-besserung der Sicherheit der Datenübertragung in „ge-switchten“ Netzen dar.

Switche sind auch in der Lage, den Verkehr mehrererVLANs über eine physische Verbindung auf einen weite-ren Switch weiterzuleiten und dort den entsprechendenVLANs wieder richtig zuzuordnen, siehe Abbildung 8.Damit ist die Nutzung von VLANs nicht auf einen Eta-genverteiler beschränkt sondern kann – entsprechendestrukturierte Verkabelung und geeignete aktive Netz-werkkomponenten vorausgesetzt – überall in einem Ge-bäudekomplex und mit gewissen Einschränkungen auchgebäudeübergreifend an allen zentralen Standorten derTU Wien erfolgen. Es ist daher möglich, praktisch in je-dem Raum eines Gebäudes jedes VLAN zur Verfügungzu stellen und dadurch das Netz unabhängig von denräumlichen Gegebenheiten im Wesentlichen nach organi-satorischen Gesichtspunkten zu strukturieren. Die Ziel-vorstellung für die nähere Zukunft kann – vonAusnahmen und Besonderheiten, die in einem dynami-schen Universitätsbetrieb unvermeidlich sind, abgesehen– auf den Punkt gebracht werden mit:

Strategien der Neuverkabelung

In allen Projekten, wo einzelne Bereiche neu adaptiertoder komplette Gebäude neu ausgestattet werden, wirdausschließlich strukturierte Verkabelung mit voll aufge-legten Anschlüssen neu errichtet. Es werden grundsätz-lich Doppeldosen installiert, wobei von einer Anzahl vonzwei bis drei Doppeldosen pro Arbeitsplatz (also vier bissechs Anschlüssen) ausgegangen wird. In Fällen, wo inguter Kooperation mit der Wirtschaftsabteilung im Rah-men von Sanierungsmaßnahmen in einzelnen Institutsbe-reichen oder Gebäudeteilen in größerem Umfangstrukturierte Verkabelung neu errichtet wird, wird dieseVerkabelung dem Stand der Technik entsprechend auchfür die Telefonie genutzt. Damit ist die Anzahl von vierbis sechs Anschlüssen pro Arbeitsplatz erforderlich, umentsprechende Reserven für zukünftige Entwicklung zurVerfügung zu haben. Bei der Bestimmung der Anzahl dererforderlichen Anschlüsse wird – von Ausnahmen abge-sehen – ausdrücklich nicht von der aktuellen Raumnut-zung ausgegangen, da, wie die Erfahrung gezeigt hat, dieRaumnutzung in einem universitären Umfeld einer sehr

starken Dynamik unterliegt und daher unbedingt flexibleReserven geschaffen werden müssen, um zukünftigenAnforderungen gerecht werden zu können. Die nachträg-liche Erweiterung von Verkabelungssystemen ist tech-nisch sehr problematisch und extrem unökonomisch. Abdem Jahr 1999 neu verlegte Kabel sind mindestens für600 MHz geeignet, wodurch auch in dieser Hinsicht Re-serven für zukünftige Entwicklungen geschaffen werden.Jedes neu verlegte Kabel wird im Rahmen der Abnahmeauf Einhaltung der vorgeschriebenen Übertragungspara-meter nach Kategorie 5 durch eine Messung überprüft.Ab sofort werden erweiterte Anforderungen für die Ab-nahmemessungen angewandt, wodurch auch die Taug-lichkeit für Gigabit-Ethernet über Kupferkabel sicher-gestellt werden kann.

Bei der Inbetriebnahme neu errichteter strukturierterVerkabelung werden, um die Kosten für aktive Kompo-nenten zu begrenzen, auf Basis von Anforderungen derNutzer nur die Anschlüsse für Datenkommunikationdurch Verbindung mit einem Switchport aktiviert, die zudiesem Zeitpunkt wirklich benötigt werden, siehe Abbil-dung 9.

Es kann daher nicht davon ausgegangen werden, dassalle in einem Raum vorhandenen Anschlüsse, ohne wei-tere Anforderungen an den ZID zur Aktivierung weitererAnschlüsse zur Datenkommunikation unmittelbar ver-wendet werden können.

In Einzelfällen, wo besondere Anforderungen vorlie-gen oder erwartet werden können, wie z. B. in Laborräu-men mit speziellen Umgebungsbedingungen wie starkenMagnetfeldern oder in Serverräumen mit speziellenBandbreitenanforderungen, werden Lichtwellenleiteran-schlüsse für den direkten Anschluss von Endsystemen er-richtet.

Neue Gebäude

Das im Herbst 1999 in Betrieb genommene Instituts-gebäude Favoritenstraße wurde dem neuesten Stand derTechnik entsprechend ausgestattet. Es wurde eine Anzahlvon Anschlüssen errichtet, die auch Reserven für zukünf-tige Entwicklungen beinhaltet, alle aktiven Anschlüssesind für 10/100MBit/s ausgerüstet und die Anbindung derEtagenverteiler an die zentralen Netzwerkkomponenten


ein Institut� ein IP-Subnetz� ein VLANAbbildung 9: Switch mit Patchkabeln zur Aktivierung

der Twisted-Pair-Anschlüsse

wurde erstmals an der TU Wien mit Gigabit-Ethernetausgeführt.

Das am Beginn der Phase der Adaptierung befindlichefür die TU Wien neue Gebäude Perlmooserhaus (Opern-gasse 11) wird in gleicher Qualität ausgestattet werden.

Projekt Teilsanierung Gußhausstraße 25und 27-29

In den Gebäuden Gußhausstraße 25 und 27-29 sindnicht zuletzt wegen Behördenauflagen im Bereich vonBrandschutz, Fluchtwegen und Sicherheit der elektrotech-nischen Installationen umfangreiche Sanierungsmaßnah-men erforderlich, die zum Teil schon im Gange sind.

Da besonders im Bereich Gußhausstraße 27-29 bereitszu einem sehr frühen Zeitpunkt begonnen wurde, struktu-rierte Verkabelung zu installieren, ist wegen der damalsgegebenen technischen und finanziellen Rahmenbedin-gungen ein hoher Anteil von halb aufgelegten Datenan-schlüssen vorhanden. Diese Art der Installation ist für dieneue bereits am Markt verfügbare NetzwerktechnologieGigabit-Ethernet nicht mehr verwendbar. Durch die vorJahren noch hohen Errichtungskosten strukturierter Ver-kabelung bedingt, wurde nur eine geringe, den heutigenAnforderungen nicht mehr gerecht werdende Anzahl vonAnschlussdosen installiert. Derzeit besteht keine Mög-lichkeit, die strukturierte Verkabelung auch für Telefoniezu nutzen, da die vorhandenen Etagenverteiler über keineVerbindung mit der Telefonanlage verfügen. Durch dieRahmenbedingungen (wie bauliche Gegebenheiten) sindviele Etagenverteiler in kleinen Nischen hinter Wandver-bauten errichtet worden und bieten nur schlechte Voraus-setzungen für einen stabilen Betrieb und keinen Spiel-raum für zukünftige Erweiterungsmöglichkeiten.

Wegen der Erfordernisse der elektrotechnischen Pla-nung, kompletten Erneuerung der Elektroinstallationenim Haus Gußhausstraße 25 und Bereinigung der Elek-troinstallationen Gußhausstraße 27-29 und der damit ver-bundenen Neuerrichtung der Tragsysteme ergibt sich fürden ZID die Notwendigkeit, die vorhandene strukturierteVerkabelung komplett zu erneuern.

Dadurch wird es möglich sein, nach Abschluss der Ar-beiten auch in diesen Gebäuden eine dem Stand derTechnik entsprechende Ausstattungsqualität zur Verfü-gung stellen zu können.

Zukünftige EntwicklungenDie Übertragungstechnik Gigabit-Ethernet über Twis-

ted-Pair-Kabel 1000Base-T befindet sich in der Marktein-führung. Es sind jedoch Verbindungen, die weitere überdie Norm Kategorie 5 hinausgehende Spezifikationen er-füllen, erforderlich. Erste Produkte sind, wenn auch zurelativ hohen Kosten, verfügbar. Der Einsatz dieser Tech-nologie wird in den nächsten Jahren auch an der TUWien erwartet. Ein unmittelbarer Bedarf ist derzeit aber

nicht erkennbar, da einerseits die Anwendungen fehlen,die den Einsatz dieser hohen Bandbreiten und damit auchhohen Kosten rechfertigen würden, andererseits die ange-schlossenen Systeme derzeit auch meist nicht in der Lagesind, Datenströme mit diesen Geschwindigkeiten zu verar-beiten. Die in den letzten zwei Jahren neu errichteten Ver-kabelungen unterstützen diese Technologie aber bereits.

Der Standard für 10-Gigabit-Ethernet über Lichtwel-lenleiter wird innerhalb der nächsten zwei Jahre erwartet.Herstellerspezifische Lösungen befinden sich bereits vorder Markteinführung.

Fiber to the Desk

Dieses Schlagwort beschreibt den ausschließlichenEinsatz von Lichtwellenleitern bis zum Anschluss aufdem Arbeitsplatz. Den unbestrittenen Vorteilen dieserTechnologie – wie Überbrückung größerer Distanzen unddamit die Möglichkeit der Versorgung aller Arbeitsplätzeeines Hauses von einem Punkt aus und größere Reservenhinsichtlich der Bandbreite für zukünftige Entwicklungen– stehen aber gravierende Nachteile gegenüber.

Die Kosten für Interfaces mit Lichtwellenleiteran-schluss sind sowohl auf der Seite der Endgeräte als auchauf der Seite der aktiven Netzwerkkomponenten signifi-kant höher. Sollen die preiswerteren Komponenten mitkonventionellen Anschlüssen für Kupferkabel eingesetztwerden, so sind Komponenten zur Konvertierung derSignale erforderlich, die zusätzliche Kosten verursachen.

Heute dem Stand der Technik entsprechende Telefon-systeme erfordern – wie auch die im Herbst 1998 in Be-trieb gegangene neue Telefonanlage der TU Wien – denAnschluss der Endgeräte (Telefone) auf Basis von Kup-ferkabeln. Damit muss auf jeden Fall zu jedem Arbeits-platz ein Kupferkabel herangeführt werden. Es ist der-zeit keine wirtschaftlich einsetzbare Technologie bekannt,die das Führen dieser Telefoniesignale über Lichtwellen-leiter ermöglichen würde. Voice over IP – Übertragungvon Telefongesprächen über Datennetze – ist beim der-zeitigen Stand der Entwicklung vom Standpunkt derQualität, der Betriebsstabilität und der Kosten für die TUWien keine Alternative zur konventionellen Telefonie.

Daher wird in unmittelbarer Zukunft „Fiber to theDesk“ im Bereich der TU Wien keine Anwendung finden.

LinksRichtlinien für Anmeldungen:

http://nic.tuwien.ac.at/tunet/anmeldung.html

aktuelle Nameservereinträge:http://nic.tuwien.ac.at/netinfo/tcpip/hosts.tuwien

TUNET-Datenbank:http://nic.tuwien.ac.at/tunetdb/

Telekommunikation:http://www.zid.tuwien.ac.at/telekom/


Eine einfache Firewall-LösungWalter Selos

Da des Öfteren seitens der Institute der Wunsch geäußert wurde, den Netzwerk-Verkehr ausSicherheitsgründen filtern und überwachen zu können, habe wir eine einfache Firewall-Lösung aufLINUX-Basis entwickelt.

Folgende Zielsetzungen wurden dabei besonders be-rücksichtigt:

• geringe Kosten: Es reicht ein PC mit Diskettenlaufwerkund 2 Ethernetkarten, eine optionale Festplatte dient nurzum Abspeichern eines Logfiles. Die Diskette mit demBetriebssystem ist schreibgeschützt und dient nur für denBootvorgang.Während des Betriebes läuft alles in einer RAM-Disk,d. h. keine Probleme bei Stromausfall oder Einbruchs-versuchen übers Netz.Als Hardwarevoraussetzungen genügt ein Pentium oderAMD Prozessor mit ≥ 300 MHz Taktrate und ca. 64 MBRAM.

• Robustheit: Ist durch die Stabilität des LINUX-Kernelsund die RAM-Disk-Lösung gewährleistet.

• Einfachheit/Betriebssicherheit: Der Einsatz des Gerä-tes macht keine softwaremäßigen Konfigurationsarbei-ten an den übrigen Netzwerkknoten notwendig.Sollte das Gerät ausfallen, kann es durch ein adäquatesPatchkabel überbrückt werden. Freilich fehlt dann die Fi-rewall-Funktionalität, aber der Weiterbetrieb des Netzesist gewährleistet.

• einfache Konfiguration: Die Diskette ist als FAT-File-system formatiert. Damit können auf jedem Windows-oder DOS-Computer die zwei Konfigurationsdateieneditiert werden. (In der einen werden die Netzwerk-Kon-figuration, in der anderen die Filterregeln eingetragen.)Ein Neustart macht die neue Konfiguration wirksam.

Das Problem wurde so gelöst, dass der Linuxkernelmit einer Option compiliert wurde, die es ihm ermög-licht, als „Ethernet-Bridge“ zu funktionieren, währendein zusätzlicher Kernelpatch es ermöglicht, die eingebau-te Paketfilterfunktion (ipchains) auch auf die Bridge-funktion anzuwenden. Es werden aber auch andereMöglichkeiten wie z. B. IP-Masquerading unterstützt, mitder man ein privates Netz hinter einer einzigen IP-Adres-se verstecken kann.

Die wichtigste Voraussetzung für den Einsatz ist einehardwaremäßige Netzwerkkonfiguration, bei der es genaueine Verbindung zwischen dem Instituts-Subnetz unddem Rest des TUNET gibt, an der man das Gerät dazwi-schenschalten kann. Das kann ohnehin schon gegebensein oder man kann durch die Schaffung eines „virtuellenLANs“ eine solche Situation schaffen, auch wenn Teiledes Netzes sich physisch auf verschiedenen Lokalitätenbefinden. (Bitte auf jeden Fall mit der Abt. Kommuni-kation des ZID Verbindung aufzunehmen ! )

Es ist auch zu bedenken, dass man fundierte Kenntnis-se über IP-Netzwerke braucht, um die Filterregeln zu de-finieren. Sonst würde die Aufstellung eines solchenGerätes die Betreiber nur in falscher Sicherheit wiegen,was die Situation nur verschlechtern statt verbessern wür-de. Sind diese Kenntnisse nicht ausreichend vorhanden,können Sie für dieses Gerät einen Wartungvertrag ab-schließen (siehe http://evaxsw.tuwien.ac.at/pss/pss.htmlunter „Fernunterstützung“).

Weiters ist auch zu bedenken, dass die beste Firewall-Lösung nichts nützt, wenn Sie dahinter alle Möglichkei-ten von „mobile code“, wie Active-X, Scripting-Host,Java, Javascript usw. uneingeschränkt zulassen, dannkönnte mitunter „feindlicher“ Programmcode hinter demFirewall aktiviert werden, was dann alle Sicherheitsbe-mühungen unterläuft bzw. zunichte macht (siehe „Love-letter“).

Nähere Informationen über diese Firewall-Lösung sie-he unter:

http://linux.tuwien.ac.at/firewall.html

Sollten Sie noch Fragen haben oder Beratung wün-schen, kontaktieren Sie mich bitte:

Walter [email protected]. 42031 oder unsere Hotline 42124


Chello StudentConnectan der TU WienJohann Klasek

Aufgrund der Diskussionen, die in letzter Zeit anlässlich der Performance von ChelloStudentConnect aufgekommen sind, sollen in diesem Artikel neben der geschichtlichenEntwicklung die technische Ausstattung und die Anbindung dieses Services ausführlichdargestellt werden.

Geschichtliches

Nicht lange nach der Pilotprojektphase des Internetzu-gangs via Kabelanschluss ist die Möglichkeit in Betrachtgezogen worden, auch Studenten und den Mitarbeiternder TU Wien einen günstigen und schnellen Zugang alsAlternative zur bestehenden Dial-in-Infrastruktur anzu-bieten (wie dies zuvor schon der Universität Wien gelun-gen ist). Diese Überlegungen mündeten in einen von derTU Wien angestrebten Kooperationsvertrag zwischen derdamaligen Telekabel Ges.m.b.H. (heute abgelöst durcheinen Zusammenschluss aus Chello Broadband und UPCTelekabel, siehe [4]) und der TU Wien. Um hier konkretden Kooperationsvetrag zu zitieren: „Die Telekabel WienGes.m.b.H. erwartet sich einen Zuwachs an Neukundenaus diesem Zielgruppen-Segment, das traditionell zu denEarly-Adopters neuer Technologien zählt und hier aucheindeutig eine Opinion-Leader Funktion einnimmt.“

Im Gegenzug zu dieser Erwartung profitiert die TUWien von einer Entlastung der Dial-in-Zugänge und esbestünden somit auch bessere Voraussetzungen, um z. B.Vorlesungen online abzuhalten.

Um den Kabelanschluss auch wirklich attraktiv zu ge-stalten, wurde der vergünstigte Tarif „StudentConnect“zu 390,- statt des Normalpreises von 590,- ausgehandelt.Dies wurde möglich, indem sich StudentConnect Benut-zer weitgehend auf die Ressourcen der TU Wien stützen:

• E-Mail und News-Service-Infrastruktur, sowie etwaigerWeb-Space wird von Seiten der TUWien (bzw. deren In-stitute) zur Verfügung gestellt.

• DieTUWien verpflichtet sich, einenProxy-Server zu be-treiben, der den Bandbreitenkonsum für den globalen In-ternetzugriff über die externe Anbindung der TU Wien(ACOnet, siehe [8], und andere Provider) leitet (siehe [1],[3]). Dabei bleibt das Transfervolumen im Wesentlichenunbeschränkt, solange sich die Ziele der aufgebauten

Verbindung im ACOnet befinden. Dies trifft imSpeziellen auch für die über den Proxy-Server aufgebau-ten Verbindungen zu.

Der erste Ansturm, beginnend im Mai 1998, resultiertein rund 350 Anmeldungen bis Ende 1998. Die Entwick-lung nahm, sicher nicht zuletzt bedingt durch günstigeEinstiegskonditionen seitens Telekabel, einen sprunghaf-ten Verlauf, wie auch in der nachfolgenden Tabelle er-sichtlich ist. Neben den getätigten Anmeldungen sindauch die derzeit aktiven Anmeldungen angeführt, die al-lerdings nicht notwendigerweise mit den tatsächlich vor-handenen TU StudentConnect Anschlüssen überein-stimmen müssen. Die Anmeldung bescheinigt lediglichdie Zugehörigkeit zur TU Wien, ohne dass damit eineAussage über die tatsächlichen Installationen gemachtwerden könnte.

Das Verhältnis von TU Angehörigen zu Studentenverringert sich zusehends, was die Wichtigkeit dieses An-gebots für die Studenten unterstreicht.

Jahr Anmel-dungen

derzeitaktiv

davonMitarbeiter

1998 (ab Mai) 352 289 15.00 %1999 1096 1029 7.00 %2000 (bis Nov.) 1232 1221 6.50 %Summe 2680 2539

Bereits Ende 1998 zeigten sich verhältnismäßig grobeSchwankungen in der Verbindungsqualität zwischen demChello-Netzwerk und der TU, die eine vernünftige Ver-wendung der TU-Ressourcen stark beeinträchtigte. ZurVerbesserung wurde eine möglichst direkte Verbindungaus dem Chello-Netz zur TU Wien realisiert. Im Bereichdes an der Universität Wien ansässigen VIX (Vienna In-ternet eXchange, [9]) wurde vom dort einmündendenChello-Netz eine Direktverbindung zur TU Wien ge-schaltet, die dann vorerst qualitativ das hielt, was von perKabelanbindung versorgten Benutzern erwartet wurde.


Die Kapazität der Direktverbindung ist mit 10 MBit/s(jeweils beide Richtungen) ausgelegt und hat bis heutebei gleichbleibender Konfiguration keinen Engpass her-vorgerufen. Ebensowenig war in diesem Zeitraum dieVerbindung durch nennenswerte Fehlerzustände beein-trächtigt (siehe [7]).

Im Laufe des Jahres 1999 wurde die ehemalige Tele-kabel Ges.m.b.H. in den international agierenden UPC(United Pan-Europe Communications, http://www.chello.com/) Konzern eingegliedert (der sich UPC Telekabelnennt), der mit der Chello Broadband Gesellschaft eineninternational vertretenen Backbone-Betreiber vorweisenkann (siehe [4]). Das bis dahin als TeleWeb vermarkteteProdukt der Internetzugangs über Kabelanschluss wurdenun unter dem Namen „Chello“ verbreitet. Das ließ zwarVorteile für die internationale Anbindung erhoffen, stellteaber für normale StudentConnect Kunden der TU Wien –sofern sie die Dienste des Proxy-Services nutzen – keinqualitätssteigerndes Moment dar. Die in Österreich vor-herrschenden Verhältnisse nahmen leider auch in Bezugauf die TU Wien immer negativere Ausmaße an (sieheauch [5, 6]).

Massive Ausfälle, z. B. in ganzen Bereichen von Wienin Tagesausmaßen, Server-Ausfälle und -Beeinträchtigun-gen über Wochen andauernd, waren nur ein Aspekt, derdie TU Wien betraf und vor allem den StudentConnect-Benutzern das Leben erschwerte. Zum anderen Teil warseitens des ZID ein erhöhter Betreuungsaufwand notwen-dig geworden, um die Folgen der immer häufiger auftre-tenden Mängel im Installations- und Servicebereich vonTelekabel zu klären.

Erst mit Frühling 2000 stabilisierte sich die Situationhinsichtlich der Serverausstattung für Services und dieGebietsversorgung innerhalb des Chello-Netzes.

Der weitere Anstieg des Telekabelkundenstammes er-höhte auch das Transferaufkommen immens, was sichnach und nach in der zunehmenden Belegung der verfüg-baren Chello-seitigen Bandbreitenkapazität der Chello-TU-Direktanbindung auswirkte.

Die TU Wien reagierte auf das gesteigerte Transfer-aufkommen durch die Auslagerung des Proxy-Servicesam 11. 8. 2000 auf eine eigenständige Servermaschine,wo alle Ressourcen ausschließlich der Proxy-Funktionali-tät zur Verfügung stehen. Damit wurde auch der mittler-weile schon recht stark belastete Info-Server, der unteranderem die TU Wien Home-Page anbietet, wesentlichentlastet. Weiters wurde der Proxy-Server innerhalb desTUNET peripherer positioniert, sodass die vorwiegendnach außen führenden Verbindungen nun nicht mehrdurch das gesamte TUNET verlaufen.

Im Zuge diverser Security-Maßnahmen (Portsperrenbei den Kundenanschlüssen) seitens Chello kam es am6. 9. 2000 zu einer unbeabsichtigten Blockierung des Zu-gangs zum Proxy-Server der TU Wien mit Auswirkungauf alle Chello-Anschlüsse. Diese etwas vorschnellenMaßnahmen, gegen die der ZID auch protestierte, wurdenvorerst durch die dedizierte Freischaltung des Proxy-Ser-vers entschärft und später vollständig fallengelassen.

Im Laufe der Proxy-Server-Existenz für die Chello-Anbindung waren immer wieder Unregelmäßigkeiten im

Betrieb aufgetreten, welche ihren Ursprung in der Refe-renzimplentierung des SOCKS-Server von NEC hatten.Die recht starke Frequentierung des Proxy-Servers an derTU Wien brachte gänzlich neu, scheinbar ungetestet ge-bliebene Lastzustände zu Tage. Die im Frühling des Jah-res 2000 installierte und damals aktuelle Version desNEC SOCKS-Referenz-Servers [11] brachte wiederumneue Probleme mit sich, die zuerst nur mit einem Worka-round gemildert und seit kurzem durch einen am ZIDentwickelten Patch endgültig beseitigt werden konnten.

Technisches

Die Anbindung der Chello-StudentConnect-Benutzerzur TU Wien verläuft aus der Sicht des Chello-Netzesüber die externe Anbindung Chellos an das Internet. Re-gional für den Bereich Wien gesehen, bedeutet dies ei-gentlich eine Verbindung über das an der UniversitätWien ansässige VIX, da sowohl das Chello-Netz als auchdas ACOnet (mit der TU Wien als Teilnehmer am ACO-net) als Partner über das VIX kommunizieren können(siehe [8]). Mit der Inbetriebnahme der Direktverbindungzur TU Wien wurde der Weg über das ACOnet undschließlich der VIX umgangen. Diese Direktschaltung zurTU Wien verläuft vom Anschlusspunkt des Chello-Netzesam VIX (aber nicht durch den VIX) physikalisch gesehenauf der UDN-Strecke (Universitätsdatennetz) zwischenUniversität Wien und TU Wien. Die Darstellung auf dernächsten Seite soll einen Überblick dazu geben.

Die Direktverbindung ist mit einer Bandbreite von10 MBit/s (full duplex) ausgelegt und ist bis heute nochnicht an ihre Kapazitätsgrenzen gestoßen (siehe [7]). Einwesentlich kritischerer Punkt ist die Einmündung desChello-Netzes in den Bereich des VIX, wo die dort ver-fügbare Bandbreite Chellos auf EBONE, VIX und Di-rektverbindungen zu den diversen Universitäten, imspeziellen auch zur TU aufgeteilt wird. Die exakte Auf-teilung mit den Eigenschaften, wie sie Chello vorgibt, istnicht völlig klar, aber in groben Zügen bekannt. Der An-teil für die Uni-Direktverbindungen ist dabei so gering,dass bei gleichzeitiger Benützung durch mehrere Univer-sitäten die von der TU Wien bereitgestellte Bandbreiteüber die Direktverbindung (10 MBit/s) nie ausgelastetwerden konnte. Diese Chello-seitige Einschränkung gabin der jüngeren Vergangenheit auch immer wieder Anlasszur Kritik [10], wobei festzuhalten wäre, dass die TUWien hier keinen ausschlaggebenden Einfluss hat. Eben-so ist das VIX in keiner Weise an dieser Situation betei-ligt, da die Direktverbindung zur TU Wien nicht überden VIX-Verteiler verläuft, sondern nur am VIX-Standortmit dem Chello-Netz zusammentrifft.

Von der technischen Abteilung Chellos wurde einebaldige Kapazitätsaufstockung der Anbindung in Aus-sicht gestellt, die vermutlich zu einem – bis jetzt nochnicht bekannten – Ausmaß auch den Universitätsverbin-dungen zugute kommen wird.

Der Weg vom Chello-Netz zum Internet lässt sich nurdurch die Verwendung des Proxy-Servers steuern und istsonst fest vorgegeben:

• Ohne Proxy-Server wird die Chello-eigene Anbindungans Internet (EBONE oder was auch immer) herangezo-


gen. Ziele des ACOnets lassen sich über das Peering amVIX erreichen, mit Ausnahme der TU Wien, die über dieDirektverbindung erreicht wird.

• Mit dem Proxy-Server (in der für Browser üblichen Au-tokonfiguration, [2]) führen alle nicht ins Chello-Netzoder ACOnet gehenden Verbindungen zuerst zumProxy-Server, der über die Direktverbindung TU Wienerreicht wird. Der Proxy-Server stellt schlussendlich dieVerbindung zum eigentlichen Ziel über die externe An-bindung der TU Wien her.

Der Proxy-Server fungiert als Vermittler zwischen TUWien StudentConnect-Benutzern und dem Internet, wo-durch sich auch eine gewisse Beziehung zum Kostenfak-tor hinsichtlich der externen Anbindung der TU Wienergibt. Daraus resultieren entsprechende Einschränkungenbzw. Konfigurationsmerkmale am Proxy-Server:• Als Proxy-Protokoll steht SOCKSVersion 4 undVersion

5 zur Verfügung, siehe [11]. Client-Programme müssenentweder von sich aus dieses Protokoll unterstützen oderdie Netzwerkschicht des Betriebssystems wird durcheine „socksified“ Variante ersetzt bzw. ergänzt, die denSOCKS-Zugriff einem Clientprogramm völlig transpa-rent erscheinen lässt.

• Es werden nur TCP Protokolle zugelassen – UDP Ver-kehr wird nicht zugelassen.

• ICMP Verkehr (ping etc.) geht grundsätzlich nicht überden Proxy-Server (obgleich im SOCKS-Protokoll einPing Mechanismus vorgesehen ist, aber hier nicht zurAnwendung kommt).

• Es werden nur die gängigen Services durchgelassen(z. B. HTTP, HTTPS, FTP, POP, IMAP, SMTP etc.).Eine genaue Auflistung ist in [2] angegeben. Nicht unter-stützte Protokolle müssen gegebenenfalls über die kon-tingentierte proxy-lose Verbindung aufgebaut werden.

Referenzen

[1] Online-Zugang über Chello für Studierende undAngehörige der TU Wienhttp://www.tuwien.ac.at/zid/zserv/inf/chello.html

[2] SOCKS-Server Chello-Internet-Anschlusshttp://nic.tuwien.ac.at/services/socks/

[3] Online-Zugang über TeleWeb, Pipeline 25, Juni 1998,http://www.tuwien.ac.at/pipeline/p25/teleweb.html

[4] Chello (national, international) und UPC Telekabelhttp://www.chello.at/, http://www.chello.com/,http://www.telekabel.at/

[5] Chello Usergroup: http://chello.or.at/[6] Chello User-Vertreter Portal - NetWatcher

http://www.uv.chello.or.at/[7] Statistik der TU Wien - Chello Direktverbindung

http://nic.tuwien.ac.at/tunet/traffic/anbindung.cgi?log=teleweb

[8] ACOnet: http://www.aconet.at/ACOnet2000.htm[9] Vienna Internet eXchange (VIX): http://www.vix.at/[10] Diskussionen in den USENET Newsgroups

at.tuwien.tunet, at.univie.edv, at.internet.provider[11] SOCKS Referenzimplentierung

http://www.socks.nec.com/refsoftware.html


V I X

I n te r ne t

E B O N E

andere

Service Provider

Proxy

Universitäten

wiss. Organisationen

ACOnet

Ch e l l o

TU Wien

Ö oder =?iso-8859-1?Q?=D6?=Umlaute in E-MailsJohann Haider

Electronic Mail gehört heute zu den wichtigsten Anwendungen, die über das Internet abgewickeltwerden. Praktisch wird nur mehr das SMTP Protokoll verwendet, andere Formen derMailübertragung führen bestenfalls noch ein Nischendasein innerhalb geschlossenerBenutzergruppen. Das Protokoll ist nicht in einem Guss entstanden, sondern wurde im Laufe derZeit den Erfordernissen angepasst. Deshalb kann es zu Problemen bei der Darstellung kommen,wenn Sender und Empfänger sich nicht auf den gleichen Protokollstandard einigen können.

Prinzip des SMTP Protokolls

Der Sender erstellt seine Nachricht mit Hilfe des MailUser Agent (MUA), dieser reicht sie an den zugeordnetenMTA (Mail Transfer Agent) weiter. Über eine Kette vonweiteren MTAs wird die Nachricht bis zum MTA desZielrechners geschickt, wo die Mailbox des Empfängersliegt. Die Übertragung zum MUA des Empfängers wirdnicht über das SMTP Protokoll abgewickelt [14, 15].

Nachrichtenformat

Eine Nachricht besteht aus dem Message Header, indem für Menschen und Rechner lesbare Informationenstehen, und dem Message Body, das ist die vom Absen-der erstellte Nachricht.

Der Header besteht aus so genannten Fields, einigeder bekannteren sind:

From: AbsenderTo: EmpfängerSubject: BetreffMessage-ID: Eindeutige Identifikation

der Nachricht

Alle Felder bis auf Message-ID sind vom Protokollbetrachtet optional. (Die Nachricht kommt auch dann an,wenn kein To: Feld existiert, da die Zieladresse auch au-ßerhalb der Nachricht übertragen wird.)

Historischer Rückblick

Im Jahr 1977 wurde in einem Dokument über InternetText Messages ein Verfahren zum Übertragen von Nach-richten veröffentlicht. Aus diesem entwickelte sich dasSMTP Protokoll, das im Jahr 1982 in den DokumentenRFC 821 bzw. RFC 822 in die heute verwendete Formgebracht wurde. Auf Grund der Wurzeln des Internet inUS amerikanischen Militär- und Universitätseinrichtungenwurde für die Übertragung der Nachricht nur der ASCIIZeichensatz vorgesehen.

Die Möglichkeit zur Übermittlung von Nachrichten,die einen nationalen Zeichensatz verwenden, wurdenicht berücksichtigt. Trotzdem gab es bald eine Reihevon nicht standardisierten Erweiterungen der Softwarevon verschiedenen Herstellern, sodass innerhalb ge-schlossener Gruppen die Verwendung von nationalenZeichensätzen möglich war (Schweden, Japan).

8-Bit Zeichensätze waren zu dieser Zeit auf MS-DOSbzw. Macintosh Rechnern vorhanden, nicht aber auf denfür die Internet-Kommunikation verwendeten Unix Syste-men. Für verschiedene Sprachen lieferten die Herstellerder als Eingabegeräte verwendeten Terminals nationaleZeichensätze, die durch die Zweitbelegung von wenigverwendeten Sonderzeichen entstehen und in nationalenNormen bzw. später durch ISO 646 genormt wurden. Inden 80er Jahren wurde durch die ISO auch eine 8-Bit Zei-chensatzfamilie genormt, die wesentlich auf dem Multina-tional Character Set (MCS) der Fa. Digital beruhte undheute unter dem Namen der Norm ISO 8859 bekannt ist.Von diesem Zeichensatz gibt es mittlerweile 15 Varianten,wobei ISO 8859-1 (Westeuropäische Sprachen) bei unsam gebräuchlichsten ist. Der unter Windows gebräuchlicheso genannte ANSI Zeichensatz stimmt glücklicherweise imBereich der druckbaren Zeichen mit ISO-8859-1 überein.


Sender

MUA

MTA MTA

MUA

Empfänger

Tabelle ISO 8859-1

Um 1990 begann sich die Internet Engineering TaskForce (IETF) damit zu befassen, wie die gerade neu ge-normten oder vorgeschlagenen 8- und 16-Bit Zeichensätzenach ISO 8859 bzw. Unicode [5, 6] in E-Mails verwen-det werden sollten, bzw. wie der Transport dieser Datenverlustfrei erfolgen kann. Im Speziellen befassten sichverschiedene IETF Komitees:

• eine Erweiterung für eine 8-Bit Datenübertragung zu de-finieren, die kompatibel mit RFC 821 ist. Das Ergebniswar das Dokument RFC 1425 vom Februar 1993, dessenletzte Revision als RFC 1869 verfügbar ist [7, 8].

• eine Erweiterung von RFC 822 zu definieren, die es er-laubt, dem Empfänger die im Text verwendete Codie-rung der Zeichen mitzuteilen, sodass die Lesbarkeit auchdann gegeben ist, wenn kein reiner ASCII Code verwen-

det wird. Dieses Dokument wurde 1992 als RFC 1341verabschiedet, der aktuelle Stand ist in RFC 2045 bisRFC 2049 zu finden [9, 10, 11, 12, 13] und wird allge-mein als MIME-Standard bezeichnet.

Zu Beginn der 90er Jahre herrschte allgemein die An-sicht, dass in absehbarer Zeit ein Umstieg auf OSI X.400Mailprotokolle erfolgen werde und das SMTP Protokollnur mehr für einen begrenzten Zeitraum notwendig wäre.Auch an der TU Wien wurde im Jahr 1994 ein X.400 fä-higes Mailgateway installiert. Da der Support des Her-stellers nicht befriedigend war und kein Bedarf für einMultiprotokoll-Mailgateway mehr bestand, wurde dieseSoftware 1998 durch die aktuelle Release eines nurSMTP-fähigen Programmes ersetzt.


0 1 2 3 4 5 6 7 8 9 A B C D E F0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

0

16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

1

32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47

2 ! " # $ % & ' ( ) * + , - . /48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63

3 0 1 2 3 4 5 6 7 8 9 : ; < = > ?64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79

4 @ A B C D E F G H I J K L M N O80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95

5 P Q R S T U V W X Y Z [ \ ] ^ _96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111

6 ` a b c d e f g h i j k l m n o112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127

7 p q r s t u v w x y z { | } ~128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143

8

144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159

9

160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175

A ¡ ¢ £ ¤ ¥ ¦ § ¨ © ª « ¬ - ® ¯176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191

B ° ± ² ³ ´ µ ¶ · ¸ ¹ º » ¼ ½ ¾ ¿192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207

C À Á Â Ã Ä Å Æ Ç È É Ê Ë Ì Í Î Ï208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223

D Ð Ñ Ò Ó Ô Õ Ö × Ø Ù Ú Û Ü Ý Þ ß224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239

E à á â ã ä å æ ç è é ê ë ì í î ï240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255

F ð ñ ò ó ô õ ö ÷ ø ù ú û ü ý þ ÿ

Die leeren Positionen sind für nicht-druckbare Steuerzeichen reserviert.Der Zeichensatz ISO 8859-15 verwendet die Position 164 für das €-Symbol

(im Windows-Zeichensatz liegt das Euro-Symbol auf Position 128).

Übertragung von Mails mit Umlauten

Der MIME Standard schreibt vor, dass im Mailheaderfolgende Deklarationen des Inhalts enthalten sein müs-sen, wenn die Nachricht standardkonform sein soll.

Z. B.

Content-type beschreibt den Aufbau der Nachrichtan sich, welcher vom Autor der Nachricht vorgegebenwird. Content-transfer-encoding beschreibt, wiedie Nachricht während der Übertragung verpackt wird,damit sie nicht verstümmelt wird. Wenn im Verbindungs-pfad zwischen Sender und Empfänger mehrere Stationenvorhanden sind, kann es vorkommen, dass die Nachrichtein oder mehrmals zwischen beiden Content-trans-fer-encoding Varianten konvertiert wird.

Probleme bei der Darstellung vonUmlauten

Grundsätzlich sollten keine Probleme auftreten, wennalle beteiligten Programme standardkonform sind. DerMailclient des Senders und des Empfängers müssen demMIME Standard entsprechende Mails senden bzw. lesenkönnen. In [16] ist eine Liste von Programmen ange-geben, die Umlaute verarbeiten können: auf der Win-dows-Plattform u. a. MS Outlook, Netscape Communica-tor, Pegasus Mail; auf Unix-Rechnern pine und mutt.Alle MTA auf dem Weg vom Sender zum Empfängermüssen entweder RFC 821 konform sein oder dem Stan-dard RFC 1652 entsprechen. Wenn das nicht der Fall ist,besteht die Gefahr, dass eine Nachricht verstümmelt beimEmpfänger ankommt, wenn eine 8-Bit Nachricht auf demWeg einen Rechner passiert hat, der nur 7-Bit Daten ver-arbeiten kann.

Sollte einmal ein Problem auftreten („Das hat bis jetztimmer funktioniert“), kann man durch Analyse der Mail-header zeigen, wo das Problem liegt. Dazu ist es notwen-dig, den vollständigen Mailheader zu sehen, nicht nur dieAuszüge, die die Mailprogramme standardmäßig bieten.Sollte kein Mailclient bei der Hand sein, der die vollstän-dige Darstellung der Mailheader erlaubt, ist es auch mög-lich, die Mails ohne Umweg über einen Mailclient direktvom Pop Account abzurufen [15].

Codierung der Mailheader

In einem Mailheader dürfen nur Zeichen aus dem US-ASCII Zeichensatz vorkommen. Analog zur Kodierungdes Message Body wird in RFC 2047 festgelegt, wieMailheader aufbereitet werden müssen, wenn sie andere

als Zeichen aus dem US-ASCII Zeichensatz enthalten.Solche Zeichen treten insbesondere in den vom Absendereingegebenen Teilen des Header (z. B. Display Namen,Subject) auf.

Beispiel aus RFC 2047 [11]:

Wenn beide Partner mit Mailprogrammen arbeiten, diedem Standard entsprechen, werden diese Umschreibun-gen für den Benutzer niemals sichtbar. Erst wenn einesolche Nachricht mit einem Programm weiterverarbeitetwird, das mit dem MIME Standard nichts anfangen kann,wird direkt der kodierte Text angezeigt. Werden Modifi-kationen in den kodierten Teilen vorgenommen, muss dieÄnderung mit großer Sorgfalt durchgeführt werden, da-mit das Ergebnis wie erwartet ausfällt.

Ausblick

Da die 8-Bit Codes nicht ausreichen, um Texte allerWeltsprachen darzustellen, wurde von IndustrieseiteUnicode und von der ISO die Norm 10646 geschaffen.Beide Organisationen haben sich mittlerweile so weit ge-einigt, dass für die praktische Anwendung beide Normengleichgesetzt werden können. In der Version 3 ist Unico-de ein 16-Bit Code, in dem 49194 Zeichen definiert sind,darunter europäische Alphabete, Hebräisch, Arabisch,asiatiasche Schriftzeichen, mathematisch-technische Sym-bole, weiters wurden (für uns) exotische Sprachen undBraille aufgenommen [17, 18, 19, 23].

Die untersten 128 Zeichen sind mit dem ASCII Codeidentisch. Wenn ein Text hauptsächlich aus ASCII Zei-chen besteht, würde eine direkte Speicherung in 16-BitUnicode das Volumen durch Nullbytes auf das Doppeltevergrößern. Die Nullbytes können auch bei der Übertra-gung von Texten Probleme machen, deshalb wurde zumAustausch von Daten (z. B. per E-Mail) die CodierungUTF-8 entwickelt, die alle Zeichen im ASCII Zeichen-satz unverändert lässt [20, 21, 22]. In diesem Sinne wäreauch das Versenden von Mails, in deren Header steht:

Content-type: text-plain; charset=utf-8Content-transfer-encoding: quoted-printable

für die existierende Serverinfrastruktur kein Problem,allerdings gibt es wenige (PC-)Mailclients 1, die dieseCodierung unterstützen. Wenn wir in unseren E-Mailsdas € verwenden wollen, werden wir diese Unterstützungbenötigen.


From: =?ISO-8859-1?Q?Olle_J=E4rnefors?=<[email protected]>

To: [email protected],[email protected]

Subject: Time for ISO 10646?

Mime Version: 1.0Content-type: text/plain; charset=iso-8859-1Content-transfer-encoding: quoted-printable

oder

Mime Version: 1.0Content-type: text/plain; charset=iso-8859-1Content-transfer-encoding: 8bit

1 Bei einem stichprobenartigen Test erlaubte nur Microsoft Outlookdas Erstellen und Verschicken von E-Mails mit € -Symbol.

Referenzen[1] ASCII, „USA Code for Information Interchange“,

United States of America Standards Institute, X3.4,1968.

[2] Crocker, D., „Standard for the Format of ARPA In-ternet Text Messages“, RFC 822, Department ofElectrical Engineering, University of Delaware, Au-gust 1982.

[3] Postel, J., „Simple Mail Transfer Protocol“, STD10, RFC 821, USC/Information Sciences Institute,August 1982.

[4] Borenstein, N., and N. Freed, „MIME (Multipurpo-se Internet Mail Extensions): Mechanisms for Spe-cifying and Describing the Format of Internet Mes-sage Bodies“, RFC 1341, Bellcore, Innosoft, June1992.

[5] International Standard – Information Processing –8-bit Single-Byte Coded Graphic Character SetsPart 1: Latin Alphabet No. 1, ISO 8859-1:1998, 1st ed.Part 2: Latin Alphabet No. 2, ISO 8859-2:1999, 1st ed.Part 3: Latin Alphabet No. 3, ISO 8859-3:1999, 1st ed.Part 4: Latin Alphabet No. 4, ISO 8859-4:1998, 1st ed.Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1999, 2nd ed.Part 6: Latin/Arabic Alphabet, ISO 8859-6:1999, 1st ed.Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1999, 1st ed.Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1999, 2nd ed.International Standard – Information Technology –8-bit Single-Byte Coded Graphic Character SetsPart 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1998,2nd ed.International Standard – Information Technology –8-bit Single-Byte Coded Graphic Character SetsPart 13: Latin Alphabet No. 7, ISO/IEC 8859-13:1998,1st ed.International Standard – Information Technology –8-bit Single-Byte Coded Graphic Character SetsPart 14: Latin Alphabet No. 8 (Celtic), ISO/IEC 8859-14:1998, 1st ed.International Standard – Information Technology –8-bit Single-Byte Coded Graphic Character SetsPart 15: Latin Alphabet No. 9, ISO/IEC 8859-15:1999,1st ed.

[6] ISO/IEC 10646-1:1993(E), „Information technolo-gy – Universal Multiple-Octet Coded Character Set(UCS) – Part 1: Architecture and Basic MultilingualPlane“, JTC1/SC2, 1993.

[7] Klensin, J., Freed, N., Rose, M., Stefferud, E. andD. Crocker, „SMTP Service Extensions“, STD 10,RFC 1869, November 1995.

[8] Klensin, J., (WG Chair), Freed, N., (Editor), Rose,M., Stefferud, E., and Crocker, D., „SMTP ServiceExtension for 8bit-MIME transport“, RFC 1652,United Nations University, Innosoft, Dover Beach

Consulting, Inc., Network Management Associates,Inc., The Branch Office, March 1994.

[9] Freed, N., and N. Borenstein, „Multipurpose Inter-net Mail Extensions (MIME) Part One: Format ofInternet Message Bodies“, RFC 2045, Innosoft,First Virtual Holdings, November 1996.

[10] Freed, N., and N. Borenstein, „Multipurpose Inter-net Mail Extensions (MIME) Part Two: Media Ty-pes“, RFC 2046, Innosoft, First Virtual Holdings,November 1996.

[11] Moore, K., „Multipurpose Internet Mail Extensions(MIME) Part Three: Representation of Non-ASCIIText in Internet Message Headers“, RFC 2047, Uni-versity of Tennessee, November 1996.

[12] Freed, N., Klensin, J., and J. Postel, „MultipurposeInternet Mail Extensions (MIME) Part Four: MIMERegistration Procedures“, RFC 2048, Innosoft,MCI, ISI, November 1996.

[13] Freed, N. and N. Borenstein, „Multipurpose InternetMail Extensions (MIME) Part Five: ConformanceCriteria and Examples“, RFC 2049 (this document),Innosoft, First Virtual Holdings, November 1996.

[14] Crispin, M., „Internet Message Access Protocol –Version 4“, RFC 1730, University of Washington,December 1994.

[15] Myers, J. & Rose, M., „Post Office Protocol – Ver-sion 3.“, RFC 1939, Carnegie Mellon University,May 1996.

[16] Christof Awater, „Umlaute in E-Mail und Netnews“,FAQ für de.newusers.questions URL: http://www.westfalen.de/paefken/de.newusers/umlaute-faq.txt

[17] The Unicode Consortium, The Unicode Standard,Version 3.0 Reading, MA, Addison-Wesley Deve-lopers Press, 2000. ISBN 0-201-61633-5.

[18] New in Version 3.0http://www.unicode.org/unicode/standard/versions/Unicode3.0.html

[19] Unicode Blockshttp://www.unicode.org/Public/UNIDATA/Blocks.txt

[20] Yergeau, Francois, „UTF-8, a transformation formatof ISO 10646“, RFC 2279, Alis TechnologiesMontreal, January 1998.

[21] Czyborra, Roman, Unicode Übersicht, http://www.czyborra.com, Dissertation in Arbeit, Berlin2000.

[22] Lohner, Martin, „Stand der Unicode-Entwicklung“,ix 10/2000, Verlag Heinz Heise, Hannover 2000.

[23] Zagler, Wolfgang, „Kommunikationstechnik für be-hinderte und alte Menschen“, VorlesungsskriptumTU Wien, 2000, Beschreibung von ISO/DIS 11548-2.


Effizientes Lösennumerischer Problememit MATLAB 6Ernst Haunschmid, ZIDHerbert Karner, Stefan Katzenbeisser, Christoph ÜberhuberInstitut für Angewandte und Numerische Mathematik{ernst,herbert,katze,christof}@aurora.anum.tuwien.ac.at

Einleitung

MATLAB 6 (Überhuber, Katzenbeisser [4]), die neueVersion des Programmsystems MATLAB, bietet eine Rei-he neuer und verbesserter Features:

• eine erweiterte Benutzeroberfläche (komfortable Ver-waltung, Tools zum einfachen Importieren von Daten,Generieren von Abbildungen, ...),

• eine Schnittstelle für Java Routinen,

• neue Features im Bereich der Visualisierung,

• die Möglichkeit zur direkten Übernahme von C und C++Code aus Microsoft Visual Studio,

• Erweiterungen und Verbesserungen im Bereich numeri-scher Berechnungen durch Einbindung von LAPACK undFFTW.

Die Effizienzsteigerungen bei der Lösung linearerGleichungssysteme und bei der diskreten Fourier-Trans-formation sind das Thema dieses Artikels.

LAPACK

LAPACK (Linear Algebra Package) [1] ist ein frei ver-fügbares Softwarepaket von Fortran 77-Unterprogram-men, mit deren Hilfe man viele Standardprobleme derLinearen Algebra numerisch lösen kann. Das kompletteSoftwareprodukt LAPACK umfasst mehr als 600 000 Zei-len Fortran-Code in über 1000 Routinen und eine Benut-zungsanleitung. 1

LAPACK ist für numerische Probleme der Linearen Al-gebra mit dicht besetzten Matrizen und Bandmatrizen derDe-facto-Standard (Überhuber [3]). Um die Zuverlässig-keit und Effizienz von LAPACK mit der Benutzerfreund-lichkeit und dem Komfort von MATLAB zu verbinden,wurden die wichtigsten LAPACK-Programme in MAT-

LAB 6 einbezogen.

BLAS

Die bisherigen MATLAB-Versionen verwendeten Teiledes Programmpakets LINPACK [2] zur Lösung von Auf-gaben der numerischen Linearen Algebra. Sowohl LIN-

PACK als auch LAPACK basieren auf den Basic LinearAlgebra Subroutines (BLAS), einer Sammlung speziellerUnterprogramme zur Lösung elementarer Teilaufgabender Linearen Algebra. Die Verwendung der BLAS-Pro-gramme bringt einen zweifachen Nutzen:

1. Die allgemein verfügbare Fortran-Version 2 ist so pro-grammiert (mit aufgerollten Schleifen etc.), dass sieauf vielen Computern mit zufriedenstellender Gleit-punktleistung läuft.

2. Sie können leicht durch individuell optimierte (z. B. inAssembler geschriebene) Versionen ersetzt werden.Die Portabilität geht dabei nicht verloren, da auch dieFortran-Version stets verfügbar ist.

In LINPACK waren es nur Vektor-Operationen (z. B.die Bestimmung der Norm eines Vektors oder die Be-rechnung des Skalarprodukts zweier Vektoren), die mitden dafür geeigneten BLAS-1-Programmen realisiert wur-den. Der größte Teil der Algorithmen musste daher noch


1siehe http://www.netlib.org/lapack/

2siehe http://www.netlib.org/blas/

in Form von Fortran-Anweisungen implementiert werden.Erst durch das 1988 veröffentlichte BLAS-2-Softwarepa-ket für Matrix-Vektor-Operationen wurde es möglich,viele Algorithmen der numerischen Linearen Algebra sozu implementieren, dass ein großer Teil der Berechnun-gen in den BLAS-Programmen durchgeführt wird.

Um die potentielle Leistungsfähigkeit von Computernmit stark gestaffelten Speicherhierarchien in einem mög-lichst hohen Ausmaß nutzen zu können, ist es notwendig,Daten so oft es geht wieder zu verwenden, um möglichstwenig Daten zwischen den verschiedenen Ebenen derSpeicherhierarchie transportieren zu müssen. Dieses Zielkann nur dann erreicht werden, wenn man die Algorith-men nicht nur auf elementare Vektor- und Matrix-Vek-tor-Operationen, sondern auch auf elementare Matrix-Matrix-Operationen (Matrizenmultiplikationen etc.) zu-rückführt. Das 1990 veröffentlichte BLAS-3-Softwarepa-ket stellt die hierfür erforderlichen Module zurVerfügung. Die maschinenspezifische Implementierungdieser Unterprogramme kann auf modernen Computernzu noch erheblich größeren Leistungsgewinnen führen alsdie (ausschließliche) Verwendung optimierter BLAS-1-und BLAS-2-Programme.

In den LAPACK-Programmen werden alle rechenauf-wendigen Teilalgorithmen durch Aufrufe von BLAS-1-,BLAS-2- und BLAS-3-Programmen realisiert. Maschinen-abhängige, aber sehr effiziente BLAS-Implementierungensind für die meisten modernen Hochleistungsrechner ver-fügbar. Die drei Gruppen der BLAS-Programme ermögli-chen es, dass LAPACK-Programme einen hohen Grad anRechenleistung und Portabilität erreichen.

In die Version 6 von MATLAB wurde LAPACK voll-ständig integriert. Im Gegensatz zu den LINPACK-basier-ten Routinen, die Bestandteil des früheren MATLAB-Source-Codes waren, wurde in Version 6 eine andereVorgangsweise gewählt. Die LAPACK-Routinen undBLAS-Routinen sind jeweils in eigenen Dateien (als sogenannte shared objects) implementiert. Dadurch ist esmöglich, die mit MATLAB mitgelieferten BLAS- und LA-

PACK-Bibliotheken durch eigene oder systemseitig bereitsvorhandene Bibliotheken zu ersetzen.

Lösung linearer Gleichungssysteme

Durch die Verwendung von LAPACK in MATLAB 6konnte ein signifikanter Leistungsgewinn erzielt werden.Zum Vergleich wurde die Gleitpunktleistung des MAT-

LAB-Befehls A\b mit MATLAB 5.3 und MATLAB 6 experi-mentell untersucht.

Die praktischen Untersuchungen wurden auf der SGIOrigin2000 des ZID und auf verschiedenen PCs durchge-führt. Es wurden dabei die MATLAB-Versionen 5.3 und6.0 beta 5 verglichen.

Abb. 1 zeigt die Gleitpunktleistung von MATLAB 5.3und MATLAB 6 bei der Lösung linearer nichtsymmetri-scher Gleichungssysteme durch Auswertung von A\b.Für größere Gleichungssysteme ist die Version 6 zwaretwa doppelt so schnell wie ihre Vorgängerversion, aberabsolut gesehen ist die erreichte Leistung nicht befriedi-gend. Ein Fortran 77-Programm erreicht bei Verwendungoptimierter, systemseitig vorhandener LAPACK- und

BLAS-Bibliotheken (im Fall der Origin2000 wurde dieSGI Cray Scientific Library (SCSL) verwendet), mehr alsdie dreifache Gleitpunktleistung von MATLAB 6.

Eine detaillierte Analyse des Problems zeigte, dass diemit MATLAB 6 mitgelieferte BLAS-Bibliothek in Bezugauf die Gleitpunktleistung nicht mit der SCSL vergleich-bar ist. Die mitgelieferte BLAS-Bibliothek kann aber sehreinfach gegen die hochoptimierte SCSL ausgetauscht wer-den. Die damit erreichbare Gleitpunktleistung liegt nurnoch geringfügig unter der eines entsprechenden Fortran-Programmes.

Bei linearen Gleichungssystemen mit symmetrischen,positiv definiten Matrizen sind die beobachtbaren Ergeb-nisse ähnlich. Obwohl auch hier MATLAB 6 eine deutlichbessere Gleitpunktleistung erzielt als MATLAB 5.3, kön-nen die Leistungswerte eines LAPACK-Programms erstdurch das Ersetzen der in MATLAB 6 verwendeten BLAS-Bibliothek durch eine hochoptimierte Version erreichtwerden (siehe Abb. 2).

Die Eigenschaften der Systemmatrix (Bandstruktur,Symmetrie, Definitheit etc.) haben einen sehr großen Ein-fluss auf die Rechenzeit, die zur Lösung eines linearenGleichungssystems benötigt wird.

Bei der direkten Verwendung von LAPACK-Routinenunter Fortran muss der Programmierer dafür Sorge tra-gen, dass er eine den Eigenschaften der Matrix angemes-


Lapack

Matlab 5.3Matlab 6.0

Matlab 6.0 (Scsl)

Gleitpunkt-Leistung M op/s

Dimension n

500

400

300

200

100

0300025002000150010005000

100%

80%

60%

40%

20%

0%

Abbildung 1: Gleitpunktleistung von A\bin MATLAB 5.3, 6 und in LAPACK.

Lapack

Matlab 5.3Matlab 6.0

Matlab 6.0 (Scsl)

Gleitpunktleistung M op/s

Dimension n

500

400

300

200

100

0300025002000150010005000

100%

80%

60%

40%

20%

0%

Abbildung 2: Gleitpunktleistung von A\b in MATLAB 5.3, 6 undin LAPACK bei symmetrischen, positiv definiten Matrizen.

sene Routine auswählt. Zum Vergleich sind in Abb. 3 dienormierten Laufzeiten der entsprechenden LAPACK-Pro-gramme dargestellt.

Bei Verwendung von MATLAB 6 braucht der Benutzerdiese Eigenschaften weder kennen noch in irgendeinerWeise berücksichtigen; die Verwendung des MATLAB-Befehls A\b gewährleistet in allen Fällen eine Problem-lösung mit minimalem Rechenaufwand. Abb. 4 zeigt dieentsprechenden Laufzeiten.

Insbesondere hervorzuheben ist der Komfort, denMATLAB 6 gegenüber der direkten Verwendung von LA-

PACK-Programmen bietet. Man erspart sich die Auswahlder passenden Programme und auch die unübersichtli-chen und fehleranfälligen Aufrufe der LAPACK-Routinen.

Diskrete Fourier-Transformationen

MATLAB 6 enthält mit FFTW (Fastest Fourier Trans-form in the West) von Matteo Frigo und Steven Johnson

(MIT Laboratory for Computer Science) das zurzeit „in-novativste“ FFT-Pogrammpaket. In FFTW sind erste An-sätze zu einer architekturadaptiven FFT-Berechnungrealisiert. In einer Initialisierungsphase wird ein „Berech-nungsplan“ ermittelt, der die FFT-Berechnung an dieSpeicherhierarchie des Rechners anpasst.

Abb. 5 zeigt einen Vergleich der normierten Laufzei-ten der FFT-Berechnung von MATLAB 6 mit MATLAB 5.3und der in C geschriebenen FFTW-Version.

Wie man sieht, ist MATLAB 6 für lange Vektoren mehrals doppelt so schnell wie MATLAB 5.3. Der durch die In-tegration von FFTW in MATLAB entstandene Overhead istdafür verantwortlich, dass die „reine“ C-Implementierungein – geringfügig – besseres Laufzeitverhalten aufweist.

Zusammenfassung

In MATLAB 6 wurde erstmals eine sehr komfortableund gleichzeitig effiziente Möglichkeit zur Lösung nume-rischer Probleme realisiert. Man kann ohne Übertreibungvon einer neuen Generation numerischer Software spre-chen.

Literatur

[1] E. Anderson et al.: LAPACK User’s Guide, 3rd ed.,SIAM Press, Philadelphia, 1999.

[2] J. J. Dongarra et al.: LINPACK User’s Guide. SIAMPress, Philadelphia, 1979.

[3] C. W. Überhuber: Numerical Computation. Sprin-ger-Verlag, Heidelberg, 1997.

[4] C. W. Überhuber, S. Katzenbeisser: MATLAB 6.Springer-Verlag, Wien, 2000.


TridiagonalmatrixDreiecksmatrix

sym. pos. def. Matrixallgemeine Matrix

Normierte Laufzeit (T=n3)

Dimension n

ns

300025002000150010005000

5

4

3

2

1

0

Abbildung 4: Normierte Laufzeit von A\b(MATLAB 6 mit SCSL) bei verschiedenen Matrixtypen.

TridiagonalmatrixDreiecksmatrix

sym. pos. def. Matrixallgemeine Matrix

Normierte Laufzeit (T=n3)

Dimension n

ns

300025002000150010005000

5

4

3

2

1

0

Abbildung 3: Normierte Laufzeit von LAPACK-Routinenzur Lösung linearer Gleichungssysteme

bei verschiedenen Matrixtypen.

FFTWMatlab 5.3

Matlab 6.0

Normierte Laufzeit (T=N logN)

Vektorl�ange N

ns

219217215213211292725

1000

100

10

1

Abbildung 5: Normierte Laufzeit der FFT-Routinenin MATLAB 5.3, 6 und FFTW.

Das Programm ERDAS IMAGINEangewandt zur Erfassungder Schneedecke ausFernerkundungsaufnahmenJosef JansaInstitut für Photogrammetrie und [email protected]

EinleitungIm Rahmen eines Pilotprojektes, das von den Wiener

Wasserwerken angeregt wurde und für welches diese unddas Bundesministerium für Bildung, Wissenschaft undKultur Förderungsmittel zur Verfügung stellten, solltedas Schneeschmelzverhalten im Bereich der Quellen derErsten Wiener Hochquellenwasserleitung erfasst werden.Dieses Projekt konzentrierte sich auf das Gebiet derSchneealpe südwestlich der Rax [1].

Als Daten für die Schneeschmelzmodellierung, dievom Institut für Hydraulik, Gewässerkunde und Wasser-wirtschaft durchgeführt wurde, dienten

• Farbinfrarot-Luftbildaufnahmen, die zur Erfassung einesdetaillierten Geländemodelles und einer hochgenauenBodenbedeckungsklassifizierung herangezogenwurden,

• Meteorologische Beobachtungen im Bereich der Schnee-alpe,

• Bodenbeobachtungen der Schneelage und des Schnee-zustandes zu bestimmtenZeitpunkten und an bestimmtenStellen (so genannte Schneekurse),

• Auswertungen von Satellitenbildern in regelmäßigenAbständen zur Feststellung der aktuellen Schneelage.

Der erste und letzte Punkt wurden vom Institut fürPhotogrammetrie und Fernerkundung ausgeführt. Für dieSatellitenbildinterpretation gelangte das ProgrammpaketERDAS IMAGINE zum Einsatz, über welches in derFolge etwas detaillierter berichtet werden soll.

ERDAS IMAGINEDie Firma ERDAS ist im Bereich der Fernerkundung

zu einem der weltweit führenden Anbieter von Auswerte-und Interpretationssoftware geworden. Das derzeitigeProdukt heißt ERDAS IMAGINE, läuft auf verschiede-nen windows-orientierten Plattformen und ist an der TUWien unter UNIX X-Motif beim ZID installiert. Nochläuft die Version 8.3, die Nachfolgeversion 8.4 ist bereitsausgeliefert. Für all jene, die viel im GIS-Bereich (Geo-Informationssysteme) tätig sind, liegt ein besonderer Vor-teil dieses Produktes in der seit langem recht engen Ver-knüpfung der Software mit dem GIS-Paket ARCInfobzw. ARCView von ESRI, womit eine einfache gemein-same Verwendung der beiden Softwareprodukte im Rah-men einer Projektbearbeitung gewährleistet wird.

ERDAS IMAGINE ist in Module gegliedert, die wie-derum als Pakete angeboten werden: IMAGINE Essenti-als, IMAGINE Advantage und IMAGINE Professional.Letzteres ist an der TU Wien installiert. Darüber hinaus-gehende Module sind z. B. das Vector Module, VirtualGIS Module oder Developers’ Toolkit, wovon nur letzte-res hier installiert ist. Näheres über die gesamte Produkt-linie kann man bei http://www.erdas.com/ erfahren [2].

Abb. 1 zeigt die Befehlsleiste, die das zentrale Steue-rungselement des Programmes bildet, und die bereits ei-nen recht guten, wenn auch nur groben Überblick überdie Möglichkeiten des Programmes bietet.


Abb. 1: Zentrale Befehlsleiste von ERDAS IMAGINE

Der Viewer ist ein Fenster zur Darstellung, aber auchBearbeitung von Bildern. Mit Import wird das Modul fürden Daten-Import/Export aufgerufen. IMAGINE verwen-det eigene Datenformate für Bild- und Liniengraphik, esstehen aber eine große Anzahl von Konvertierungsmög-lichkeiten zur Verfügung. Mit dem Namen Composer istjenes Modul gemeint, das die so genannte Kartenblattge-staltung ermöglicht, also z. B. die Aufbereitung der Ana-lyseergebnisse für graphische Ausgabe auf einem Plotter.Die wichtigsten Programme für Fernerkundungsauswer-tungen befinden sich in der Kategorie Interpreter undClassifier. Von großem praktischen Nutzen ist der Mo-deler, mit welchem man auf graphische Weise durchPlatzieren und Verbinden von Symbolen auf einer Zei-chenfläche mit der Maus Makros erstellen kann.

Abb. 2 zeigt einen Überblick über die Programm-Ka-tegorien im Interpreter und Classifier. Als Beispiele sei-en genannt: Kontrast- und Helligkeitsmanipulation,Filterung im Orts- und Frequenzbereich, multispektraleKlassifizierung.

Abb. 3 zeigt ein einfaches Beispiel einer Modeler-An-wendung, wo aus vier Eingabe-Bildern (links) über eineFunktion (Kreis), die als Input eine Matrix (oben) für Fil-terzwecke benötigt, ein neues Bild (rechts) berechnetwird. Die genauen Werte bzw. Formeln für die jeweili-gen Elemente werden nach Doppelklick auf die Symboleüber die Tastatur eingegeben. Es gibt bereits eine großeAnzahl von fertigen Funktionen zur Auswahl.

Beispiel einer KlassifizierungIn der Folge sollen einige weitere Funktionalitäten des

Programmes anhand einer Schneeklassifizierung aus Sa-tellitenbildern erklärt werden.

Das Ausgangsmaterial für die Bestimmung der Schnee-lage bildeten Aufnahmen des französischen SatellitenSPOT, der in etwa 800 km Höhe die Erde umkreist undBilder mit einer Bodenauflösung von 20 m × 20 m indrei (bzw. vier) Spektralbereichen liefert. Abb. 4 zeigt ineinem IMAGINE Viewer ein derartiges Bild.

Man kann hier bereits zum Teil die Problematik derSchneeklassifizierung erkennen: (1) es gibt starke Eigen-und Schlagschatten aufgrund des niedrigen Sonnenstan-des von knapp 30°; (2) es gibt Bereiche, die offensicht-lich eine geschlossene Schneedecke aufweisen (z. B. aufdem Hochplateau der Schneealpe) und andere, die lückigbedeckt oder nur geringfügig beschneit sind (z. B. Be-reich am linken Bildrand oder an den nach Süden schau-enden Hängen am oberen Bildrand). Was hier nicht


Abb. 3: Makro, erstellt im Modeler

Abb. 4: SPOT Aufnahme der Schneealpevom 18. 2. 1998 (© SPOT Image, Frankreich)

Abb. 2: Module Interpreter und Classifier

unmittelbar zu erkennen ist, sind jene Gebiete, in denender Schnee den Aufnahmesensor „überbelichtet“. DieKlassifizierung hat daher nicht das einfache Problem„weiß“ von „nicht weiß“ zu unterscheiden, sondern musssich auf die spektralen Eigenschaften des Schnees kon-zentrieren, die unabhängig von dem Grad der Beleuch-tung sind und womöglich auch noch unabhängig von derArt des durchscheinenden Untergrunds im Falle geringerSchneedeckung. Man kann den Klassifizierungsansatz aufeiner komplexen Modellierung der Beleuchtungsgegeben-heiten aufbauen, man kann aber auch vereinfacht vorge-hen und trotzdem gute Ergebnisse erhalten, was imFolgenden beschrieben werden soll.

Über ein digitales Geländemodell errechnet man sichfür den Zeitpunkt der Satellitenaufnahme, wie die Schat-teneffekte aussehen sollten, handelte es sich um so ge-nannte Lambert’sche Oberflächen. Mit Hilfe desModelers und einem digitalen Geländemodell (DTM)kann man dies erreichen (Abb. 5). In der Folge wird dasSatellitenbild in Beleuchtungszonen segmentiert, welchejede für sich einer multispektralen Klassifizierung [3] un-terworfen werden. Als Klassifizierungsverfahren wurdedas in IMAGINE implementierte Verfahren ISODATA(Iterative Self-Organizing Data Analysis Technique) ver-wendet, welches eine selbständige Segmentierung desBildes durchführt, die auf der spektralen Ähnlichkeit derPixel basiert. Der Benutzer muss im Anschluss darandurch visuelle Interpretation die vom Programm geliefer-ten, nicht näher benannten Objektklassen mit Klassenna-men versehen (z. B. „volle Schneedeckung“, „lückigeSchneedeckung“, „kein Schnee“, ...). Das Endergebniswird erreicht, indem man die Einzelergebnisse der Be-leuchtungszonen zu einem Gesamtergebnis (Abb. 6) zu-sammenführt. Dazu könnte man das in Abb. 3 gezeigteMakro verwenden.

Was leistet ERDAS IMAGINE?

Weitere Möglichkeiten

Es wurde versucht, anhand eines konkreten Projektesin das Fernerkundungspaket ERDAS IMAGINE einzu-führen. Natürlich ist das Feld der Anwendungen vielfältig(siehe auch http://www.erdas.com/before/casestudies/index.html). Die folgende Liste, in der beispielhaft weite-re Möglichkeiten aufgezeigt sind, kann daher nur lücken-haft sein.

• Landnutzungs-/Bodenbedeckung• Großräumige Klassifizierung der Bodenbedeckung

zum Zwecke der Detailplanung im Mobilfunkbe-reich

• Feststellung der Waldfläche, getrennt nach Laub-,Nadel- und Mischwald

• Satellitenbildkarten• Geometrische Rektifizierung der originalen Satelli-

tenbilder auf ein kartographisches Referenzsystem• Zusammenstellung multi- und hyperspektraler Da-

tensätze zu einem aussagekräftigen Farbbild• Bildverbesserung durch Filterung, wie etwa Entfer-

nung von Bildrauschen oder Erhöhung der Bild-schärfe

• Analyse in Verbindung mit GIS-Daten• Kontrolle und Statistik der landwirtschaftlichen

Nutzung in geförderten Bereichen• Erfassung der Zunahme der Siedlungsflächen• Veränderungsfeststellung der Bodenbedeckung

bzw. -nutzung (Change Detection of Landcover orLanduse)


Abb. 5: Beleuchtung des DTMs

Abb. 6: Klassifiziertes Endergebnis – DieSchneebedeckung der Schneealpe

Abschließende Bemerkung

ERDAS IMAGINE ist ein leistungsfähiges Paket fürdie Bildverarbeitungsaufgaben der Fernerkundung. State-of-the-Art-Verfahren sind in großer Anzahl vorhanden.Darüber hinaus gibt es noch die Möglichkeit, über einsehr bequem verwendbares Makro-Tool komplexe Abläu-fe zu programmieren. In der Makro-Bibliothek sind au-ßerdem eine Reihe von Funktionen vorhanden, die überandere Module nicht aufrufbar sind. Im obiger Beschrei-bung nicht erwähnt wurde, dass auch grundlegende Funk-tionen vorhanden sind, die ein geometrisches Resamplingder Bilder in die Geometrie von kartographischen Refe-renzsystemen ermöglichen. Mit dem Developers’ Toolkitkann man selbst entwickelte C-Programme in die IMA-GINE Umgebung einbinden, allerdings muss man leiderdie schlechte Dokumentation dieses Moduls hier erwäh-nen, wodurch die Handhabung zu einem schwer lösbarenProblem wird.

Das Institut für Photogrammetrie und Fernerkundungverwendet die ERDAS-Programme nun schon seit über10 Jahren in Forschung und Lehre. Obwohl in der Zwi-schenzeit mehrere Alternativen auf dem Markt sind, stelltIMAGINE (auch trotz des relativ hohen Preises) nachwie vor ein wichtiges Produkt dar, weil es, erstens, viel-leicht auch auf Grund der langen Erfahrung der Fa. ER-DAS, mit seinem reichhaltigen Funktionsumfang undseiner Ausrichtung auf große Datenmengen ein hoch ge-schätztes Werkzeug in der Fernerkundung darstellt, undweil es, zweitens, wegen seiner großen Verbreitung inder Praxis auch als Lehrmittel für die Studierenden vongroßem Wert ist. Nicht vergessen werden soll, dass Fern-erkundung und GIS in vielen Bereichen stark miteinanderverknüpft sind, sei es, dass die Fernerkundung Daten fürGeo-Informationssysteme liefert, oder sei es, dass sichdie Auswertung in der Fernerkundung auf Informationen

aus Geo-Informationssystemen stützt. Durch die vieljähri-ge Zusammenarbeit der Firmen ERDAS und ESRI sinddie Produkte IMAGINE und ARCInfo gut miteinanderverknüpfbar, was im Wissensbereich, den das Institut fürPhotogrammetrie und Fernerkundung abdeckt, von un-schätzbarem Wert ist. Die Installation des IMAGINE Pa-ketes auf den UNIX-Servern des ZID hat sich sehrbewährt. Wie die Zukunft genau aussehen wird, hängtaber nicht unwesentlich von den Firmenstrategien ab, dievermehrt auf Microsoft Windows_xx zu setzen scheinenund die UNIX-Workstation-Linie stark in den Hinter-grund stellen oder vielleicht sogar auflassen werden.Selbst dann sollte die zentrale Verwaltung der Lizenzendurch den ZID weiterhin erhalten bleiben, da nur so Uni-versitätsvorteile genutzt werden können.

Referenzen

[1] Jansa J., Kraus K., Blöschl G., Kirnbauer R., Ku-schnig G. (2000): Modelling Snow Melt Processesin Alpine Areas. International Archives of Photo-grammetry and Remote Sensing, Vol XXXIII, PartB-???, Amsterdam, 6 pages (im Druck, erscheintwahrscheinlich nur auf CD-ROM)

[2] http://www.erdas.com/. Home Page der Fa. ERDASin den USA. In Österreich wird ERDAS (undESRI) durch die Fa. Synergis vertreten: http://www.synergis.co.at/ (2000)

[3] Kraus K. (1990): Fernerkundung, Band 2. Auswer-tung photographischer und digitaler Bilder, mit Bei-trägen von J. Jansa und W. Schneider, Dümmler/Bonn, ISBN 3-427-78671-4


Zeitschriften: elektronisch !Peter Kubalek, Hans HrusaUniversitätsbibliothek der TU Wien

Die Bedeutung der auf zahlreichen Web-Servern aufliegenden elektronischen Versionen dergedruckten Zeitschriften ist in den letzten Jahren dramatisch angestiegen. Die Universitäts-bibliothek der TU Wien versucht dem wachsenden Wunsch nach Benützung dieser E-Journalsdurch Abschluss zahlreicher Verträge mit den Produzenten bzw. Verlagen und durch Schaffungeinfacher Zugangsmöglichkeiten zu entsprechen. Der zentrale Einstiegspunkt in die über dieUniversitätsbibliothek der TU Wien angebotenen elektronischen Zeitschriften ist derzeit die Seitehttp://www.ub.tuwien.ac.at/onlinezs.htm. Hier wird neben einem Zugang über eine Liste derVerlage auch ein alphabetisches Verzeichnis aller elektronischen Zeitschriften angeboten. Zielist die Integration dieser Publikationen in den Online-Katalog (OPAC) der Universitätsbibliothek(http://aleph.tuwien.ac.at/), womit sowohl die realen als auch die virtuellen Bibliotheksbeständeüber eine einheitliche, integrierte Oberfläche zugänglich wären. Am Beispiel der IEL ( IEEE/IEEElectronic Library) werden Retrievalmöglichkeiten erörtert.

Die Nutzung der elektronischen Zeitschriften hängt mit einer Vielzahl administrativer, technischerund juristischer Probleme zusammen. Im Folgenden wird versucht, diese Problemeanzudiskutieren sowie Vor- und Nachteile dieser Publikationsform zu erläutern.

Historische Anmerkungen

Die ersten (gedruckten) wissenschaftlichen Zeitschrif-ten wurden 1665 publiziert, in Paris das „Journal desScavants“ und in London die „Philosophical Transactionsof the Royal Society of London“. Etwas mehr als drei-hundert Jahre danach erschienen die ersten elektronischenZeitschriften. Sie setzten die Tradition ihrer gedrucktenVorgänger fort, die „zur Beförderung der Entwicklungund Übermittlung wissenschaftlicher und anderer Kennt-nisse“ (CESARONE) gegründet worden waren.

Eine exakte Angabe, wann die erste elektronischeZeitschrift wirklich erschienen ist, scheint fast unmög-lich, zum Teil auch deshalb, weil frühe Experimente mitelektronischen Reihenpublikationen überwiegend nichtmit dem korrespondieren, was heute als elektronischeZeitschrift bezeichnet wird. So wurden mit Hilfe deselektronischen Mediums z. B. Register zu Bibliographienund Referateblättern erstellt. Der nächste Schritt warendie (elektronischen) Datenbanken, welche die Originalar-beiten bibliographisch nachwiesen. Diese Verweise wur-den mittels Online-Recherchen in Sekunden gefunden.Die Beschaffung der Originalliteratur, auf deren Benüt-zung der Wissenschaftler angewiesen war, dauerte Tage,

häufig Wochen und setzte zum Teil umfangreiche Recher-chen in diversen Zettelkatalogen und unterschiedlichenOnline-Katalogen (OPACs) der Bibliotheken voraus.

Ende der Siebzigerjahre dürfte das erste echte elektro-nische wissenschaftliche Journal erschienen sein (1979).In den Achtzigern wuchs die Anzahl, viele wurden aberbald wieder eingestellt. 1996 wurde in einem Überblickgeschrieben, dass als älteste noch immer publizierte elek-tronische Zeitschrift eine im Jahr 1987 gegründete ange-sehen werden kann.

Drei Barrieren werden genannt, die den Erfolg der frü-hen elektronischen Zeitschriften behinderten: eine gerin-ge Anzahl von Lesern mit der entsprechenden Computer-Ausstattung, verschiedene technische Probleme und alsDrittes das Zögern der Autoren, in einem elektronischenMedium zu publizieren. Diese Barrieren wurden in weni-gen Jahren gewaltig verkleinert, die Anzahl an Internet-Benützern geht in die Millionen. Die meisten technischenProbleme (z. B. elektronische Speicherung) wurden ge-löst. Und die Autoren publizierten elektronisch ab demZeitpunkt, als wissenschaftliche Beiräte diese elektroni-schen Publikationen dem Peer Review-Verfahren unter-zogen und damit eine entsprechende Qualitätskontrollevornahmen.


Nach Überwindung dieser Grenzen wuchs in denNeunzigerjahren die Anzahl elektronischer Zeitschriftenrapide. Das von der Association of Research Librariespublizierte „Directory of Electronic Journals, Newslettersand Academic Discussion Lists“ verzeichnete 1991 bloß27 Titel, 1997 (in der letzten gedruckten Ausgabe diesesVerzeichnisses) waren es schon mehr als 3.400 Titel –ein eindrucksvoller Beweis der wachsenden Popularitätder elektronischen Serienpublikationen.

Nicht eingetreten sind die Erwartungen der Zeitschrif-tenproduzenten, durch das elektronische Publizieren Kos-ten einzusparen, weil die überwiegenden Ausgaben einerhoch qualifizierten Zeitschrift im Bereich des Editorialsliegen und nicht im Bereich des Druckes und des Versan-des. Es wurden zwar manche traditionell entstehendenKosten durch die Verwendung des elektronischen Medi-ums eingespart, dafür fallen aber andere Ausgaben fürdie elektronische Publikation an, wie z. B. für die Ein-richtung der Webseiten oder für die Server-Ausstattungdes Verlages. Das wird als Ursache dafür bezeichnet,dass die Subskription einer elektronischen Zeitschriftkaum billiger als die traditionelle Printausgabe kommt.

Die aktuelle Situation

Welche verschiedenen Ausprägungen elektronischerZeitschriften gibt es nun derzeit ? In der Erscheinungs-weise kann man unterscheiden:

• Parallelausgaben: Neben der Druckausgabe kann dieZeitschrift auch elektronisch gelesen werden. Als (elek-tronisches) Format wird dabei meist pdf oder html ver-wendet.

• Nur elektronische Erscheinungsweise

Die erste, von der Universitätsbibliothek der Techni-schen Universität Wien abonnierte „nur“ elektronisch er-scheinende Zeitschrift war das „Journal of Functional &Logic Programming“, das von MIT Press, Cambridge,Massachusetts publiziert wird. (Ein TU-Angehöriger,ao.Univ.Prof. DI. Dr. Andreas Krall gehört dem EditorialBoard dieser Zeitschrift an; er hat auch den Abschlussdes Abonnements angeregt.) Der Bezug dieser Zeitschriftwar anfangs nicht ganz trivial. Jeweils nach Erscheineneines neuen Artikels (bzw. einer neuen Folge), wurde derEDV-Verantwortliche der UBTUW per E-Mail davonverständigt. Er rief daraufhin vom Verlagsserver mittelsFTP diese Datei(en) ab und deponierte sie auf einem Ser-ver der UBTUW, wo sie über das TU-Netz abgefragtwerden konnten.

Das erste größere Angebot, das einige Verlage derUniversitätsbibliothek für den Bezug elektronischer Zeit-schriften machten (gleichgültig, ob als Parallelausgabezur Printversion oder als „nur“ elektronische Ausgabe),war die Aufforderung, durch Vergabe von ID-Kennungenund Passwörtern den Zugang für die Universitätsangehö-rigen zu ermöglichen. Der daraus entstehende Verwal-tungsaufwand hätte die personelle Kapazität der Univer-sitätsbibliothek weit überstiegen, daher konnte diesemAngebot nicht gefolgt werden. Die Verlage selbst habenaber bald diesen großen erforderlichen Aufwand erkannt.Derzeit prüft in der Regel der Verlagsserver, ob der an-fragende Rechner aus einer zum Bezug berechtigten Do-main stammt, und schaltet zum Volltext „durch“.

Damit allerdings die Domain TU Wien als berechtigtauf einem Server eines diese Dienste anbietenden Verla-ges eingetragen wird, bedarf es einiger Vorbedingungen:In den überwiegenden Fällen (auf den Bezug im Konsor-tium und seine besonderen Umstände wird erst im Fol-genden eingegangen werden) ist erste Bedingung einaufrechtes Abonnement der Printversion einer bestimm-ten Zeitschrift an der TU. Nächste Vorbedingung ist einLizenzvertrag, dessen Abschluss sich häufig als komple-xe Angelegenheit darstellt. Vor allem, wenn in Vertrags-entwürfen Bestimmungen enthalten sind, die mit demGesetzesauftrag der Universitätsbibliothek nicht vereinbarsind. Als berechtigte Benützer werden demnach häufignur Universitätsangehörige angesehen. Nach den gelten-den Bestimmungen hat aber in Österreich jedermann dasRecht zur Benützung der aus öffentlichen Mitteln finan-zierten Universitätsbibliothek und ihrer Einrichtungen !Eine Lösung z. B. bei diesem Streitfall wurde in der De-finition eines benützungsberechtigten „walk-in-user“ ge-funden.

Vor- und Nachteile der elektronischenZeitschriften

Gegenüber den gedruckten Zeitschriften haben dieelektronischen Versionen entscheidende Vorteile:

Aktualität: In praktisch allen Fällen ist die elektronischeVersion früher verfügbar als die Printversion.

Bereitstellung: Die Zeitschrift kann direkt am Arbeits-platz unabhängig von den Bibliotheksöffnungszeiten ge-lesen werden.

Links: der Einsatz von Hypertext erlaubt direkten Zugriffzu weiteren Informationsquellen bzw. bessere Lesbarkeitder Zeitschrift durch Verweise innerhalb des Artikels.

Multimedialität: Bild- und Tonsequenzen ermöglicheneine umfangreichere Darstellung von Information.

Zugänglichkeit: Verlagsinterne Datenbanken erlaubenBoolesche Verknüpfungen und Volltextsuche in den Zeit-schriften.

Benutzerprofile: Individuelle Gestaltung des InformationRetrievals bzw. Erstellen einer persönlichen Bibliothek.

Browsen: Bessere Übersicht durch kompakte Inhaltsver-zeichnisse.

Während der Einsatz von Hypertext und Multimediabei den elektronischen Versionen der gedruckten (klassi-schen) Zeitschriften noch nicht so verbreitet ist wie beiden zahlreichen nur online vorhandenen Publikationen –das vorrangige Zielpublikum ist ja nach wie vor noch derLeser der Papierversion – so bieten die meisten größerenVerlage doch Datenbanken bzw. Suchmaschinen zur Ver-besserung des Information Retrievals, die Erstellung indi-vidueller Suchprofile, E-Mail-Services oder Listenpersönlich bevorzugter Zeitschriften an.

Der einzige Nachteil der elektronischen Zeitschriftenscheint derzeit (noch ?) die notwendige physische Ver-bindung mit dem TU-Netz zu sein – eine ortsungebunde-ne Benützung der Zeitschrift, z. B. im öffentlichenVerkehrsmittel, ist nicht möglich.


Das relativ neue Medium „elektronische Zeitschrift“ inseiner nur elektronischen Form bringt der Bibliothek un-zweifelhaft Ersparnisse: So fallen keine Buchbindekostenund keine Magazinierungskosten (Raum, Klima etc.) an,und für das Mahnen nicht rechtzeitig eingelangter Zeit-schriftenhefte ist auch kein Verwaltungsaufwand nötig.

An den Abonnementkosten bringen die angeführtenPunkte jedoch in den meisten Fällen kaum Reduktionen !Die Benützung der elektronischen Zeitschriften an denLeseplätzen in der Bibliothek ist durch die dafür nötigeAusstattung mit Rechnern sogar erheblich teurer als einnormaler Leserplatz.

Auch eine besondere Unwägbarkeit bringen die elek-tronischen Zeitschriften mit sich: die Frage der Archivie-rung. Wird die Haltbarkeit von Drucken auf Papier beientsprechender Magazinierung in Jahrhunderten gemes-sen (sieht man von den weniger alterungsbeständigenDrucken auf Papieren des vergangenen Jahrhunderts bzw.in wirtschaftlichen Krisenzeiten ab), ist die Archivierungnur elektronisch vorhandener Dateien Gegenstand kontro-versieller Diskussionen, abhängig sowohl vom Datenfor-mat als auch von der benötigten Hardware. Der Aufwandder dauernd notwendigen Sicherung und Konvertierungin die je neueste Version scheint nicht gering zu sein !

Und noch eine nicht gering zu schätzende Gefahr desDaten- (und damit drohenden Informations-)verlustes istzu bedenken: Wie ist es um die Zukunft des Verlagsser-vers und der darauf gespeicherten Jahrgänge einer Zeit-schrift bestellt, wenn die Zeitschrift den Verlag wechselt,eingestellt wird oder der Verlag zugrunde geht ? Zu demoben schon erwähnten Journal of Functional & LogicProgramming veröffentlichte der herausgebende VerlagMIT Press vor kurzem einen die Jahrgänge 1995-1998umfassenden Sammelband – also auf Papier gedruckt.Damit ist für die Archivierung vorgesorgt !

Eine andere Möglichkeit ist die Herstellung einer CD(durch den Herausgeber), die dann ebenfalls archiviertwerden kann. Der Platzbedarf für eine Archivierung mitCDs ist unzweifelhaft um vieles geringer als mit (gebun-denen) Zeitschriftenbänden. Die oben bereits erwähnteProblematik Haltbarkeit und Benützbarkeit (Lesbarkeit)ist mit einer Archiv-CD nur relativ kurzfristig gelöst !

Für Fragen der Archivierung dürften Zentralbibliothe-ken prädestiniert sein. Da es in Österreich aber nur fürPhysik und Medizin Bibliotheken solchen Typs gibt, undes auch – im Unterschied zu Deutschland, das Sonder-sammelgebiete (SSG) eingerichtet hat – keine Definitionvon Sammelschwerpunkten gibt, wäre es notwendig, dassdie österreichischen Universitätsbibliotheken Abkommentreffen, welche UB sich zur Aufrechterhaltung welchenZeitschriftenabonnementes verpflichtet. Nur: werden diebudgetären Mittel für solche Archivierungsaufgaben auchin den Folgejahren gesichert sein ?

Bedingt durch die Budgetknappheit einerseits unddurch Preissteigerungsraten wissenschaftlicher Zeitschrif-ten weit jenseits der jährlichen durchschnittlichen Infla-tionsrate andererseits (ganz zu schweigen von der durchdas Missverhältnis Euro zum amerikanischen Dollar

durchschlagenden Verteuerung amerikanischer Zeitschrif-ten !) werden von den Universitätsbibliotheken verschie-dene Auswege diskutiert und versucht, um trotzdem ihrenBenützern ein Optimum im Zugang zu den für ihre Tätig-keit notwendigen Informationen bieten zu können.

Ein Ansatz besteht im Bezug der elektronischen Zeit-schriften in Konsortien. Die Grundphilosophie bestehtdarin, dass an den im Konsortium verbundenen Bibli-otheken von einer bestimmten Zeitschrift nur an einerTeilnehmerbibliothek die Druckausgabe abonniert seinmuss, alle Konsortiumsmitglieder jedoch den elektroni-schen Zugang zu dieser Zeitschrift haben. Hier schließtsich der Kreis: einerseits die oben dargelegten Archivie-rungsaufgaben, andererseits (häufig) das Erfordernis, zu-mindest ein Print-Abonnement einer im Konsortiumangebotenen elektronischen Zeitschrift weiter zu führen.

Es wäre jetzt aber weit gefehlt anzunehmen, dassdadurch das Zeitschriftenbudget grundlegend entlastetwürde ! Weil die Verlage dann eben Gebühren verrech-nen müssen, um ihre Unkosten ersetzt zu bekommen.

Die Budgetierung wird sich ebenfalls ändern müssen:War es bislang eindeutig, wem die Kosten z. B. für einZeitschriftenabonnement zuzurechnen waren, kann diesbeim elektronischen Bezug überhaupt nicht fixiert wer-den, denn grundsätzlich haben alle Rechner im universi-tären Netz die Möglichkeit, die elektronische Zeitschriftabzufragen. Noch komplizierter wird die Zurechnung beiBenützung eines Zuganges im Konsortium. Nämlichdann, wenn der abgefragte Zeitschriftentitel nicht an dereigenen Bibliothek vorhanden ist oder gar, wenn dieseZeitschrift nicht einmal an einer der anderen Konsortial-bibliotheken abonniert ist. Derzeit ist der Bezug der elek-tronischen Zeitschriften noch häufig an ein laufendesAbonnement der Druckausgabe der Zeitschriften an dereigenen Bibliothek oder an einer anderen Bibliothek imKonsortium gebunden.

Der für das Jahr 2000 von 14 österreichischen Univer-sitätsbibliotheken abgeschlossene Vertrag mit Elsevierzum Bezug von Science Direct in Form eines Paid Trialermöglicht den elektronischen Bezug des gesamten Port-folios an Zeitschriften des Elsevier-Verlages. Damit sindum etwa 500 Zeitschriften mehr benützbar, als überhauptin gedruckter Form in Österreich abonniert sind ! Ob die-ses Mehrangebot jedoch auch sinnvoll ist, scheint zumin-dest diskutabel, denn möglicherweise hat Bob Michaelson,ein Angehöriger der Northwestern University, USARecht, der über die Qualität der Zeitschriften von Acade-mic Press und von Elsevier schreibt: „many of which areof at most marginal interest ... moreover, many of theirpublications are of mediocre quality or worse (as well asbeing far higher in price than their society-publishedcompetitors)“.

Eine genaue Auswertung der Benützungsstatistikenwird jedenfalls anzustellen sein, ob nicht ein Vertragsab-schluss auf elektronische Lieferung auf Basis bestimmterZeitschriftentitel wirtschaftlicher ist !


Informationsaufbereitung undSuchstrategien am Beispiel derIEEE/IEE Electronic Library (IEL)

Die vom IEEE (The Institute of Electrical and Electro-nics Engineers Inc.) und IEE (The Institution of Electri-cal Engineers) herausgegebene IEEE/IEE ElectronicLibrary (IEL) ist vermutlich eine der größten naturwis-senschaftlich-technischen elektronischen Volltextbibli-otheken. Seit kurzem steht sie allen Angehörigen derTechnischen Universität Wien zur Verfügung und istüber die Web-Seite http://www.ieee.org/ieeexplore/ zu-gänglich. Die IEL verfügt dzt. über mehr als 600.000 Arti-kel aus etwa 12.000 Publikationen. Abrufbar sind nichtnur die zahlreichen von IEEE/IEE publizierten Zeitschrif-ten, sondern auch Konferenzen und Normen. Der Zuwachsbeträgt ca 25.000 Seiten pro Monat, die Volltextarchivereichen meist bis in das Jahr 1988 zurück.

Nach Anwahl der Homepage von IEL (http://www.ieee.org/ieeexplore/) wird ohne Login-Prozedur eine Viel-zahl von Auswahlmöglichkeiten angeboten:

Die wichtigsten hier angebotenen Funktionen sind dieSuche in den Inhalts- bzw. Titelverzeichnissen (Tables ofContents) und die Suche in der Datenbank. Ausgewiesenbzw. in der Datenbank erschlossen sind nicht nur Zeit-schriftenartikel, sondern auch Konferenzen und Normen.Der Punkt Journals & Magazines etwa erlaubt eine Aus-wahl aus einer alphabetischen Liste aller Zeitschriften.Eine Zeitschrift (z. B. IEEE Transactions on Antennasand Propagation) präsentiert sich folgendermaßen:

Wie dieses Beispiel zeigt, können nicht nur die ein-zelnen Bände durchgesehen und im Volltext gelesenwerden, sondern es kann auch mittels einer Suchmaschi-ne in den einzelnen Artikeln dieser Zeitschrift gesuchtwerden ! Eine Suche nach dem Begriff „Antennenkopp-lung“ (antenna coupling) ergibt eine Titelliste jener Arti-kel aus der ausgewählten Zeitschrift, welche die imPunkt „Search“ eingegebenen Suchbegriffe enthält:

Das Abstract gibt nicht nur kurz den Inhalt wieder,sondern zeigt auch weitere Schlagwörter an, die zur Er-weiterung oder Ergänzung der Suche verwendet werdenkönnen. PDF-Full-Text liefert den Volltext im bekann-ten pdf-Format.

Das wichtigste Angebot zum Information Retrieval inden vielen Zeitschriftenartikeln, Konferenzberichten undNormen ist die Suche in der Datenbank. Angeboten wirdeine Autorensuche (By Author), eine einfache Such-oberfläche (Basic) und Expertenversion (Advanced).Die eingegeben Begriffe werden in den üblichen biblio-graphischen Feldern (Autor, Titel, Abstract usw.) ge-sucht, eine Volltextsuchmöglichkeit ist für die Zukunftvorgesehen.

Eine Autorensuche führt automatisch zu einem Index,in welchem die gewünschten Autoren ausgewählt und de-ren Artikel oder Beiträge angezeigt werden können. Die invielen Fällen ausreichende einfache Suche (Abb. 4) er-laubt die üblichen Booleschen Verknüpfungen („und“,„oder“, „und nicht“) in verschiedenen Feldern, Einschrän-kung oder Ausweitung auf verschiedene Publikationsfor-men (Zeitschriftenartikel, Konferenzen, Normen), zeitlicheEinschränkung und die Sortierung der Ergebnisse nach Er-scheinungsjahr, Publikationstitel oder Trefferhäufigkeit:


Abb. 1

Abb. 2

.............................................................Abb. 3

Abb. 4

Die Expertensuche (Advanced) erlaubt die Verwen-dung komplizierterer Boolescher Verknüpfungen sowieSuche in weiteren (bibliographischen) Feldern wie z. B.Konferenzdatum, Herausgeber usw.) und viele Proximity-oder Nachbarschaftsoperatoren (z. B. bedeutet „x <near/y> z“, dass der Begriff x höchstens y Wörter vom Begriffz entfernt sein darf).

Eine – zugegebenermaßen etwas konstruierte – Suchenach Anwendung der Prinzipien der unscharfen Logikauf Film- oder Photokameras im nichtmedizinischen Be-reich, wobei die Suchbegriffe nur in den Schlagwortfel-dern der Datenbank vorkommen sollen, könnte wie inAbb. 5 aussehen:

Diese Suche liefert eine Ergebnisliste analog Abb. 3.,wobei wiederum zwischen Abstract und Volltext (im pdf-Format) gewählt werden kann.

Datenbanken bzw. Suchmaschinen in teilweise hoherQualität bieten übrigens mehrere Verlage bzw. Institutio-nen an. Als weitere Beispiele seien ScienceDirect (http://www.sciencedirect.com/) des Elsevier-Verlages (1.100Elektronische Zeitschriften mit weit über 1 Million Ar-tikeln im Volltext) bzw. Springer Link (http://link.springer.de/search.htm) des Springer Verlages genannt.

Einige dieser Datenbanken bieten über die vielfältigenSuchmöglichkeiten hinaus so genannte Alert-Dienste an.Die Suche kann dabei zum späteren Gebrauch bzw. alsSDI-Profil (Selective Dissemination of Information) untereinem beliebigen Namen abgespeichert werden. Neu hin-zukommende Artikel werden danach täglich oder wö-chentlich (je nach Update-Zyklus der Datenbank) auf dieeingegebenen Suchbegriffe überprüft und ein Link aufdie neuen Treffer wird an eine gewünschte E-Mail-Adresse geschickt.

Schlussbemerkung

Die Bibliotheksdirektion ist trotz aller Bedenken vonder Bedeutung und von den Vorteilen der elektronischenZeitschriften überzeugt. Gerade im technisch-naturwis-senschaftlichen Bereich ist eine aktuelle und prompte In-formationsbeschaffung eine grundlegende Forderung andie Universitätsbibliothek, die vornehmlich durch denEinsatz der elektronischen Zeitschriften erfüllt werdenkann. Zu diesem Auftrag wird versucht werden, alle Mit-tel und Wege auszuschöpfen, um den TU-Angehörigen

die Benützungsmöglichkeiten zu intensivieren und insbe-sondere die Anzahl der elektronischen Zeitschriften nochzu vergrößern.

Die elektronischen Zeitschriften sind geradezu ein Pa-radebeispiel für den Vorteil des Internet bzw. WorldWide Web in der Informationsbeschaffung. Auch wennderen Auftritt nicht so spektakulär, bunt und tönend wieviele andere hochgepriesene Web-Dienste ist, bieten siedoch einen Grad an Zugänglichkeit und Verfügbarkeit se-riöser und überprüfter wissenschaftlicher Fachinforma-tion, der noch vor einigen Jahren kaum vorstellbar gewe-sen ist. Ein gewisses Minimum an Kenntnis der Informa-tionsaufbereitung und des Zurechtfindens in großenInformationsmengen ist unerlässlich, kann aber leicht er-arbeitet werden. Die Mitarbeiterinnen und Mitarbeiter derUniversitätsbibliothek der TU Wien helfen dabei gerne.

Zu hoffen ist, dass die Nutzung dieser Dienste ent-sprechend stark und effizient erfolgt, damit diese dochsehr aufwendigen und vor allem teuren Anschaffungenauch in Zukunft allen Angehörigen der Technischen Uni-versität Wien und den Besuchern ihrer Bibliothek ange-boten werden können.

Weiterführende Literatur

Bourguignon, Jean-Pierre: User-landscape: Needs and vi-sions of users. In: Digitising Journals. Conferenceon future strategies for European libraries. Copen-hagen 2000. S. 7-10.(http://www.deflink.dk/journals/)

Cesarone, Bernard: Writing for Electronic Journals. In:ECRP. Early Childhood Research & Practice. Jg. 1,Nr 1 (http://ecrp.uiuc.edu/v1n1/cesarone.html).

Göttker, Susanne – Volker Schümmer: Geschäftsgängeelektronischer Zeitschriften in Bibliotheken. In: Bi-bliotheksdienst, Jg. 34 (2000), H. 6, S. 991-1002.

Griepke, Gertraud: Document Delivery / Electronic Jour-nals. In: nfd, Nr 49 (1998), S. 51-52.

Ketcham-Van Orsdel, Lee – Kathleen Born: Pushing To-ward More Affordable Access. 40th Annual report.Periodical Price Survey 2000. In: Library Journal.New York. Jg. 2000, H.15. April, S. 47-52.

Marx, Werner – Gerhard Gramm: Wächst der Wissen-schaft das Wissen über den Kopf ? (http://www.mpi-stuttgart.mpg.de/IVS/literaturflut.html)

Michaelson, Bob: The Big Issue – The Future of Electro-nic Publications. In: IATUL News. Göteborg. Jg. 9(2000), Nr 2, S. 3-4. (http://educate.lib.chalmers.se/IATUL/2-00.html - Issue)

Roes, Hans: Electronic Journals: a survey of the literatureand the Net. HTML version of an article publishedin JoiN, Journal of Information Networking, Jg. 2,Nr 3, S. 169 – 186. (http://www.kub.nl/~dbi/users/roes/articles/ej_join.htm).

Runkehl, Jens – Siever Torsten: Das Zitat im Internet.Hannover 2000.


Abb. 5

Personelle Veränderungen


Herr Ing. Hans Fichtinger hat am 1. August 2000 mitdem Antritt seiner Pension einen neuen Lebensabschnittbegonnen.

Herr Fichtinger – von seinen Freunden liebevoll Fichtlgenannt – ist, was seine ursprüngliche Ausbildung be-trifft, Radiotechniker (Matura am TGM, erste Berufser-fahrungen bei der Fa. Kapsch). Ab 1961 war er aber aufin- und ausländischen Arbeitsplätzen als Computertechni-ker tätig und zählt sicher zu den Pionieren dieser Tätig-keit in Österreich.

Mit der TU Wien ist er seit 1974, zuerst als Wartungs-techniker der Computerfirma CDC und ab 1986 als Sys-temoperator am damaligen EDV-Zentrum der TU Wien,Abt. Prozessrechenanlage, verbunden.

Seine Bereitschaft zur Weiterbildung auch im Softwa-re-Bereich (VAX/VMS) führten zu seiner Höherreihungals Organisationsassistent. In den vergangenen Jahrenwar er für die Betreuung der Hardware der Arbeitsplätzein den Internet-Räumen verantwortlich. In dieser Zeithabe ich auch sein liebevolles Wesen und seine gewis-senhafte Arbeitsweise schätzen gelernt.

Mit Ing. Fichtinger verliert der ZID einen erfahrenenMitarbeiter. Wir alle wünschen ihm auch in der Pensionnoch viele gesunde und schöne Jahre.

G. Schmitt

Seit Anfang September 2000 ist Frau Gerda Bruckner([email protected], Nst. 42046) in der AbteilungKommunikation im Bereich der Dokumentation des TU-NET, insbesondere der Bearbeitung von Hostmaster An-gelegenheiten, tätig (Netzerfassung, Störungsannahme,Vergabe von Netzadressen).

Seit 11. 9. 2000 arbeitet Herr Andreas Schulz halbtags([email protected], Nst. 42081) in der AbteilungZentrale Services im Bereich der Systemadministrationder zentralen Unix-Server.

Seit November ist Herr DI Martin Holzinger (Tel:.42025, [email protected]) statt Herrn DI Mar-kus Klug, der seinen Wehrdienst ableistet, als dessenVertretung in der Abteilung Standardsoftware im Bereichdes Setups der Campussoftware tätig.

Wir wünschen allen neuen Mitarbeiterinnen und Mit-arbeitern viel Erfolg und Freude bei ihrer Tätigkeit!


Anzeige

ÖffnungszeitenSekretariat

Freihaus, 2. Stock, gelber Bereich

Montag bis Freitag, 8 Uhr bis 13 Uhr

• Ausgabe und Entgegennahme von Formularen für Be-nutzungsbewilligungen für Rechner des ZID,

• Internet-Service für Studierende: Vergabe von Benut-zungsbewilligungen, die nicht automatisch erteiltwerden können,

• allgemeine Beantwortung von Benutzeranfragen,Weiterleitung an fachkundige Mitarbeiter.

Telefonische Anfragen: 58801-42001

Internet-Räume

Die Internet-Räume (in den Gebäuden Karlsplatz, Frei-haus, Gußhausstraße, Treitlstraße, Gumpendorferstraße, Bib-liothek, Favoritenstraße) sind im Regelfall entsprechendden Öffnungszeiten des jeweiligen Gebäudes geöffnet.An Sonn- und Feiertagen ist kein Betrieb. Siehe auchhttp://www.ben.tuwien.ac.at/InternetRaeume/

Operator-Ausgabe

Freihaus, 2. Stock, roter BereichMontag bis Freitag, 7 Uhr 30 bis 20 Uhr

• Ausgabe für Farbdrucker.• Passwortvergabe für das Internet-Service für Studie-

rende.• Ausgabe diverser Informationen für Studierende, Wei-

terleitung von Anfragen an fachkundige Mitarbeiter.

http://www.ben.tuwien.ac.at/InternetRaeume/

Wählleitungen01 / 589 32 Normaltarif

07189 15893 Online-Tarif(50 km um Wien)

Datenformate:

300 - 56000 Bit/s (V.90)

MNP5/V.42bis

PPP

ISDN Synchronous PPP

Auskünfte, Störungsmeldungen

SekretariatTel.: 58801-42001

E-Mail: [email protected]

TUNET

Störungen

Tel.: 58801-42003


Rechneranmeldung


TelekomHotline: 08

(8.00-12.00 und 13.00-15.00 Uhr,

nur innerhalb der TU)


Chipkarten,

Abrechnung: 58801-42008

Netz- und SystemsicherheitE-Mail: [email protected]

Service-Line Abt. StandardsoftwareTel.: 58801-42004

SystemunterstützungComputer Help Line 42124

Web: sts.tuwien.ac.at/pss/

CampussoftwareE-Mail: [email protected]

[email protected]

Zentrale Server, OperatingTel.: 58801-42005


Internet-RäumeTel.: 58801-42006



PersonalverzeichnisTelefonliste, E-Mail-Adressen

Zentraler Informatikdienst (ZID)

der Technischen Universität Wien

Wiedner Hauptstraße 8-10 / E020

A - 1040 Wien

Tel.: (01) 58801-42000 (Leitung)

Tel.: (01) 58801-42001 (Sekretariat)

Fax: (01) 58801-42099

Web: http://www.zid.tuwien.ac.at/

Leiter des Zentralen Informatikdienstes:

W. Kleinert 42010 [email protected]

Administration:

A. Müller 42015 [email protected]

M. Haas 42018 [email protected]

Öffentlichkeitsarbeit

I. Husinsky 42014 [email protected]

Netz- und Systemsicherheit

U. Linauer 42026 [email protected]

Abteilung Zentrale Services

http://www.zid.tuwien.ac.at/zserv/

Leitung

P. Berger 42070 [email protected]

W. Altfahrt 42072 [email protected]

J. Beiglböck 42071 [email protected]

C. Bojer 42083 [email protected]

P. Deinlein 42074 [email protected]

P. Egler 42094 [email protected]

H. Eigenberger 42075 [email protected]

H. Flamm 42092 [email protected]

W. Haider 42078 [email protected]

E. Haunschmid 42080 [email protected]

F. Mayer 42082 [email protected]

J. Pfennig 42076 [email protected]

M. Rathmayer 42086 [email protected]

J. Sadovsky 42073 [email protected]

G. Schmitt 42090 [email protected]

A. Schulz 42081 [email protected]

E. Srubar 42084 [email protected]

G. Vollmann 42085 [email protected]

Werner Weiss 42077 [email protected]

Abteilung Kommunikation

http://nic.tuwien.ac.at/

Leitung

J. Demel 42040 [email protected]

S. Beer 42061 [email protected]

F. Blöser 42041 [email protected]

G. Bruckner 42046 [email protected]

S. Dangel 42066 [email protected]

E. Donnaberger 42042 [email protected]

T. Eigner 42052 [email protected]

S. Geringer 42065 [email protected]

J. Haider 42043 [email protected]

M. Hanold 42062 [email protected]

P. Hasler 42044 [email protected]

S. Helmlinger 42063 [email protected]

H. Kainrath 42045 [email protected]

J. Klasek 42049 [email protected]

W. Koch 42053 [email protected]

I. Macsek 42047 [email protected]

F. Matasovic 42048 [email protected]

W. Meyer 42050 [email protected]

R. Ringhofer 42060 [email protected]

R. Vojta 42054 [email protected]

Walter Weiss 42051 [email protected]

Abteilung Standardsoftware

http://sts.tuwien.ac.at/

Leitung

A. Blauensteiner 42020 [email protected]

C. Beisteiner 42021 [email protected]

E. Donnaberger 42036 [email protected]

G. Gollmann 42022 [email protected]

M. Holzinger 42025 [email protected]

A. Klauda 42024 [email protected]

H. Mastal 42079 [email protected]

H. Mayer 42027 [email protected]

J. Peez-Donatowicz42028 [email protected]

E. Schörg 42029 [email protected]

R. Sedlaczek 42030 [email protected]

W. Selos 42031 [email protected]

B. Simon 42032 [email protected]

A. Sprinzl 42033 [email protected]

P. Torzicky 42035 [email protected]


Fragen zu

Word,Excel, ... ?

Antwort durch dieComputer Help Line :

42124 *

* TU Nebenstelle; bei aufrechtem Vertrag

Plattform-UnterstützungAbteilung StandardsoftwareZentraler Informatikdienst der TU Wien s

ts.tuwien.ac.at/pss/

ZIDline 04

Documents

Transcript of ZIDline 04