PPP (Point-to-Point Protocol)
Eine Alternative zu SLIP!?

von Robert Meixner (Ausgabe 95/3, September 1995)

 

Kasten: Useful Points

 

Hinweis: Zur Lektüre dieses Artikels sind Grundkenntnisse über Funktionsweise und -umfang des Serial Line Internet Protocol (SLIP) nicht unbedingt erforderlich, aber keinesfalls von Nachteil. Wenn Sie Informationen über SLIP einholen möchten, können Sie auf den Artikel SLIP sliding away (Comment 95/1) zurückgreifen, der auch als Sonderdruck in unserer Servicestelle erhältlich ist. Erläuterungen zu vielen der im folgenden verwendeten Fachbegriffe finden Sie in der Rubrik Fachchinesisch bzw. in derselben Rubrik im Comment 95/1 (ebenfalls auch als Sonderdruck beziehbar.

Seit einiger Zeit unterstützen die Terminalserver des EDV-Zentrums zusätzlich zu den bereits bisher verfügbaren Zugriffsarten (Terminalprogramm und Telnet, SLIP) auch den Wählleitungszugang mittels PPP (Point-to-Point Protocol) zum Datennetz der Uni Wien und darüber hinaus ins Internet.

PPP kann dazu eingesetzt werden, Datenpakete (sogenannte Datagramme) des Internet Protocol (IP) für den Transport über serielle Verbindungen mit einer speziellen Transportverpackung (sogenannte Frames) zu versehen. Es eignet sich also - ebenso wie das Serial Line Internet Protocol (SLIP) - zur temporären Anbindung von Arbeitsplatzrechnern an das Internet mittels Modem und Wählleitung.

Zusätzlich unterstützt PPP aber auch die Übermittlung einer Vielzahl von Netzwerkprotokollen über synchrone und asynchrone Wähl- und Standleitungsverbindungen. Diese Vielseitigkeit von PPP bedingt ein gewisses Maß an Komplexität, weshalb hier nur ein oberflächlicher Einblick in Aufbau und Funktionsweise von PPP gegeben wird.

Point by Point

Bei PPP spielen im wesentlichen 3 Hauptkomponenten zusammen, die im Rahmen jeder PPP-Verbindung zum Einsatz kommen: Eine Methode zur Verpackung von Datagrammen verschiedener Netzwerkprotokolle, das Link Control Protocol (LCP) sowie je ein Network Control Protocol (NCP) für jedes zu übertragende Netzwerkprotokoll.

Zur Verpackung der Datagramme wird in der Regel eine Struktur verwendet, die an die Frame-Struktur des ISO-Protokolls HDLC (High-level Data Link Control) in seiner Erweiterung für asynchrone Verbindungen angelehnt ist und bei der ein Datagramm oder mehrere Datagramme eines der zu übertragenden Netzwerkprotokolle für den Transport über die serielle Verbindung mit transportbezogener Zusatzinformation versehen wird. Darunter befinden sich zwei Bytes (sogenannte Oktette) mit Information, anhand derer der Inhalt der Frames unterschieden werden kann: Mit Hilfe dieser beiden Oktette wird festgestellt, ob der Frame zur Kontrolle bzw. Steuerung der PPP-Verbindung dient, oder ob mit dem Frame Datagramme eines Netzwerkprotokolls übertragen werden und um welches Netzwerkprotokoll es sich dabei handelt. Weiters wird zum Zwecke der Erkennung von Übertragungsfehlern ein 2 bzw. 4 Oktette umfassender Prüfcode (Frame Check Sequence) generiert, in dem neben den zu übertragenden Daten auch alle relevanten Zusatzinformationen Berücksichtigung finden. Im Maximalfall umfaßt die Steuer- und Kontrollinformation 9 Oktette, von denen jedoch nicht immer alle erforderlich sind. Die nicht unbedingt nötigen Zusatzinformationen können mit Hilfe der Address-and-Control-Field-Compression und der Protocol-Field-Compression entfernt werden, wodurch eine Reduzierung auf 4 Oktette oder - falls zusätzlich auch auf den Prüfcode verzichtet wird - gar 2 Oktette möglich ist. Zusätzlich zur Frame-Struktur wird ein Verfahren definiert, mit dem in den Datagrammen enthaltene Zeichen, die von den Datenübertragungseinrichtungen und/oder von PPP als Steuerzeichen interpretiert werden könnten, vor dem Senden umcodiert und somit unschädlich gemacht werden können.

Das Link Control Protocol wird für Aufbau, Konfiguration und Abbau der PPP-Verbindung benötigt. Im Rahmen der Konfiguration der PPP-Verbindung können die beiden Kommunikationspartner alle Parameter und Optionen aushandeln, bei denen eine Abweichung von den Standardwerten vom Benutzer gewünscht wird oder aufgrund der verwendeten Datenübertragungseinrichtungen erforderlich ist. Unter anderem kann die Größe der Maximum Receive Unit (MRU) festgelegt, über den Einsatz eines Authentication Protocols abgestimmt, die Durchführung von Link Quality Monitoring (LQM) vereinbart, über die Verwendung der beiden oben genannten Kompressionsverfahren entschieden und eine Übereinkunft über die Länge des Prüfcodes getroffen werden. Weiters ist die Definition derjenigen Zeichen (Steuerzeichen) möglich, die vor der Übertragung umcodiert werden sollen. Das Link Control Protocol bietet noch eine Reihe weiterer Möglichkeiten, die PPP-Verbindung zu konfigurieren, und ist darüber hinaus auch erweiterbar; es ist jedoch zu beachten, daß es nur solche Einstellungen der PPP-Verbindung aushandelt, die von den zu übertragenden Netzwerkprotokollen unabhängig sind.

Für jedes Netzwerkprotokoll, das über eine PPP-Verbindung übertragen werden soll, muß ein Network Control Protocol (NCP) existieren: Bevor Datagramme eines Netzwerkprotokolls über die PPP-Verbindung geschickt werden können, muß mit dem entsprechenden Network Control Protocol eine Verbindung für dieses Netzwerkprotokoll aufgebaut und konfiguriert werden. Wenn mehrere verschiedene Netzwerkprotokolle verwendet werden sollen, muß für jedes dieser Protokolle mit dem entsprechenden NCP eine Verbindung aufgebaut werden. Der Abbau einer Netzwerkprotokoll-Verbindung obliegt ebenfalls dem entsprechenden NCP. Jedes Network Control Protocol ist auf die speziellen Erfordernisse zugeschnitten, die bei der Übertragung des entsprechenden Netzwerkprotokolls über eine PPP-Verbindung auftreten. So erlaubt z.B. das Internet Protocol Control Protocol (IPCP) - das Network Control Protocol für das Internet Protocol (IP) - ein dynamisches Aushandeln der IP-Adresse sowie eine Einigung der Kommunikationspartner über den Einsatz von Van-Jacobson-Header-Compression. Abgesehen von IPCP sind für eine Reihe anderer Netzwerkprotokolle NCPs verfügbar - z.B. für das AppleTalk-Protokoll, das Internetwork Packet Exchange-Protokoll (IPX) und das DECnet Phase IV-Protokoll -, und NCPs für weitere Netzwerkprotokolle befinden sich in Entwicklung.

Zusätzlich gibt es noch einige Komponenten, deren Verwendung erst durch das LCP ausgehandelt wird und die daher nicht immer zum Einsatz kommen müssen. Dazu zählen die Authentication Protocols und das Link Quality Monitoring (LQM):

PPP unterstützt zwei Authentisierungsverfahren - einerseits das Password Authentication Protocol (PAP) und andererseits das Challenge-Handshake Authentication Protocol (CHAP). Beide Protokolle sind hauptsächlich für den Einsatz auf Wählleitungsverbindungen gedacht und erlauben es dem Benutzer, sich im Rahmen der PPP-Verbindung zu identifizieren, um so eine Berechtigung für den Verbindungsaufbau nachzuweisen zu können.

Mit dem Link Quality Monitoring (LQM) kann festgestellt werden, ob und wie oft während der PPP-Verbindung Daten verstümmelt werden bzw. überhaupt verlorengehen: Wenn die Kommunikationspartner die Verwendung von LQM aushandeln, tauschen sie in periodischen Abständen sogenannte Link Quality Reports aus, anhand derer die Zuverlässigkeit der Verbindung ermittelt wird.

More Points

Wenn Sie der Meinung sind, daß Sie noch nicht genug über PPP wissen, können Sie sich durch die entsprechenden RFCs quälen (RFC = Request for Comments, die Bezeichnung für technische Vorschläge, de-facto-Standards und Standards des Internet). Die wichtigsten RFCs zu PPP sind

  • RFC1662: PPP in HDLC-like Framing
  • RFC1661: The Point-to-Point Protocol (PPP)
  • RFC1570: PPP LCP Extensions
  • RFC1334: PPP Authentication Protocols
  • RFC1333: PPP Link Quality Monitoring
  • RFC1332: The PPP Internet Protocol Control Protocol (IPCP)

Die entsprechenden Dateien finden Sie am FTP-Server der Uni Wien. Weiters ist zu PPP auch eine 8 Dateien umfassende Sammlung von Frequently Asked Questions (FAQ) verfügbar.

Strong Points

Im Vergleich mit SLIP bietet PPP einige Vorteile:

  • Bei PPP-Verbindungen können sich mehrere Netzwerkprotokolle den Übertragungskanal gleichberechtigt untereinander aufteilen. Eine SLIP-Verbindung unterstützt immer nur ein einziges Netzwerkprotokoll (in der Regel IP).
  • PPP hat ein eigenes Fehlerkorrekturverfahren: Frames, die anhand des Prüfcodes als fehlerhaft erkannt werden, werden von PPP erneut vom Kommunikationspartner angefordert. SLIP unterstützt kein Fehlerkorrekturverfahren, sondern erwartet, daß eine eventuell notwendige Fehlerkorrektur vom entsprechenden Netzwerkprotokoll durchgeführt wird - dadurch werden aber im Falle eines Fehlers einige zusätzliche Arbeitsschritte erforderlich, welche die Fehlerkorrektur und somit auch die Übertragung verlangsamen können.
  • Wenn mittels LCP die entsprechenden Steuerzeichen ausgehandelt werden, kann PPP auch auf Datenübertragungseinrichtungen verwendet werden, die mit Software-Flußkontrolle (XON/XOFF) arbeiten - z.B. zwischen Modem und Computer. Bei Einsatz von SLIP kann Software-Flußkontrolle nicht verwendet werden.
  • Unterstützen beide Kommunikationspartner dasselbe Authentisierungsverfahren, so entfällt im allgemeinen die manuelle bzw. skriptgestützte Identifizierung beim Kommunikationspartner, was in vielen Fällen auch die Verwendung von Skripts überflüssig macht. SLIP verfügt über kein Authentisierungsverfahren.
  • Im Gegensatz zu SLIP unterstützt PPP - genauer IPCP - von sich aus das automatische Aushandeln einer dynamisch zugewiesenen IP-Adresse.
  • Bei PPP handeln sich die Kommunikationspartner mittels IPCP aus, ob Van-Jacobson-Header-Compression verwendet werden soll. Bei Verwendung von SLIP muß der Benutzer wissen, ob der Kommunikationspartner Van-Jacobson-Header-Compression unterstützt oder nicht, und die Software dann selbst dementsprechend konfigurieren.
  • PPP hat sich als Standard etabliert, verfügt über alle Möglichkeiten, über die auch SLIP verfügt, ist flexibel und erweiterbar und wird laufend weiterentwickelt. SLIP hingegen ist nur ein de-facto-Standard und birgt darüber hinaus kein Entwicklungspotential mehr in sich.

Weak Points

PPP hat im Vergleich mit SLIP jedoch auch Nachteile:

  • Das Aushandeln der Einstellungen durch das LCP und das darauffolgende Aushandeln der Einstellungen durch die verschiedenen NCPs kann einige Sekunden in Anspruch nehmen. SLIP kann aufgrund seiner fest eingestellten Parameter den Betrieb sofort aufnehmen.
  • PPP-Frames, die zur Übertragung von Netzwerkprotokoll-Daten verwendet werden, enthalten zusätzlich zu den Daten standardmäßig 9 Oktette Steuer- und Kontrollinformation. Auch wenn die Verwendung von Address-and-Control-Field-Compression und von Protocol-Field-Compression ausgehandelt und die Zusatzinformation somit auf 4 Oktette reduziert werden kann, sind das immer noch 3 Oktette mehr als bei der Verwendung von SLIP, das mit einem Oktett an Zusatzinformation auskommt.
  • PPP benötigt aufgrund des komplizierten Aufbaus seiner Frames wesentlich mehr Systemressourcen (Rechenzeit, Speicher) als SLIP, das mit einer sehr einfachen Frame-Struktur das Auslangen findet. Dies könnte bei schnellen PPP-Verbindungen und unzureichend ausgestatteten Computern zu Einbußen bei der Arbeitsgeschwindigkeit führen.
  • Werden von LCP viele Steuerzeichen ausgehandelt, die vor der Übertragung umcodiert werden müssen, und enthalten die zu übertragenden Datagramme viele solcher Steuerzeichen, so erhöht sich die zu übertragende Datenmenge, da jedes Steuerzeichen, das ursprünglich mit einem Oktett dargestellt werden konnte, nach dem Umcodieren zwei Oktette beansprucht.

Tie on Points

Die Meinungen darüber, ob nun PPP oder SLIP schneller ist, gehen auseinander. Um überhaupt einen solchen Vergleich zu ermöglichen, beschränkt sich die folgende Betrachtung auf eine typische Anbindung eines Arbeitsplatzrechners an das Internet über eine asynchrone Wählleitungsverbindung, und um darüber hinaus Chancengleichheit zu gewährleisten, auf die Übertragung von IP-Datagrammen über die PPP-Verbindung. (Chancengleichheit ist jedoch - wie sich später herausstellen wird - nicht der einzige Grund, warum nur die Übertragung von IP-Datagrammen berücksichtigt wird.)

Ein rein analytischer Vergleich der beiden Protokolle unter den genannten Einschränkungen läßt kaum signifikante Unterschiede in der effektiven Datenübertragungsgeschwindigkeit und der Ausnutzung des Übertragungskanals erwarten, da

  • ohnehin beide Protokolle Van-Jacobson-Header-Compression verwenden können;
  • die Zeitspanne, die das Aushandeln der Einstellungen bei PPP-Verbindungen in Anspruch nimmt, im Vergleich zur Dauer des Verbindungsaufbaus kaum eine Rolle spielt;
  • die 3 Oktette an Zusatzinformation, um die ein typischer PPP-Frame größer als ein SLIP-Frame ist, im Vergleich zur Größe eines durchschnittlichen Frames nur einen verschwindend geringen Einfluß auf die Übertragungsdauer haben;
  • heutzutage kaum noch Computer eingesetzt werden, bei denen Rechenzeit und Speicher größere Probleme bereiten;
  • in den seltensten Fällen Steuerzeichen für Software-Flußkontrolle (geschweige denn für andere Zwecke) ausgehandelt werden müssen und
  • die genannten Nachteile - falls sie wirklich ins Gewicht fallen - im allgemeinen durch den Vorteil der schnelleren Fehlerkorrektur bei PPP ohnehin kompensiert werden.

Unterschiede in der effektiven Datenübertragungsgeschwindigkeit und in der Ausnutzung des Übertragungskanals durch PPP- bzw. SLIP-Softwarepakete können dennoch nicht ausgeschlossen werden - unter anderem auch aufgrund der eventuell unterschiedlichen Qualität der Umsetzung der Protokolle durch die Software. Will man wirklich jeden Geschwindigkeitsvorteil nützen, wird man daher im Endeffekt nicht umhinkommen, die Alternativen zu testen. Es ist jedoch anzunehmen, daß der erzielbare Geschwindigkeitsvorteil im Vergleich zum Einsparungspotential, das eine optimale Justierung des MRU-Parameters in sich birgt, minimal sein wird - ganz abgesehen von weiteren Umständen, die nicht im Einflußbereich des Benutzers liegen, wie z.B. unterschiedliche Leitungsqualität und Verbindungsgeschwindigkeit auf der Wählleitungsverbindung bei jedem Verbindungsaufbau oder unterschiedliche Auslastung der benötigten Leitungsinfrastruktur und der gewünschten Servicerechner im Internet.

Da sich die Funktionalität von derzeit angebotenen PPP-Softwarepaketen kaum von der Funktionalität von SLIP-Softwarepaketen unterscheidet, wird die Wahl desjenigen Protokolls empfohlen, das für Ihre Plattform leichter verfügbar ist und für das eine bessere Unterstützung durch den Hersteller angeboten wird. Wenn Sie bereits erfolgreich SLIP-Software verwenden, sollten Sie sich genau überlegen, ob sich der Umstieg auf PPP lohnt.

Our Points

Auf der Seite des EDV-Zentrums stehen derzeit 2 Modemserien zur Verfügung, die beide PPP unterstützen: Unter der Kopfnummer 4078770 sind 15 Modems erreichbar, die am Terminalserver PLATO.UNIVIE.AC.AT angeschlossen sind, und hinter der Kopfnummer 4068971 verbergen sich 5 Modems mit einer Verbindung zum Terminalserver HOMER.UNIVIE.AC.AT. Alle Modems des EDV-Zentrums sind so konfiguriert, daß sie folgende Einstellungen unterstützen:

  • Datenformat: 8 Datenbits, 1 Stopbit, No Parity
  • Übertragungsgeschwindigkeit: 28800, ..., 300 bit/s
  • Protokolle: V.FastClass, V.34, ..., V.22bis
  • Fehlerkorrektur (optional): V.42 LAP-M, MNP Class 4
  • Kompression (optional): V.42bis, MNP Class 5

Derzeit unterstützt keiner der beiden Terminalserver ein Authentisierungsverfahren, weshalb der Login-Vorgang manuell durchgeführt werden muß oder gegebenenfalls mit Hilfe eines Skripts automatisiert werden kann. Außerdem erlauben die Terminalserver über die PPP-Verbindung nur den Transport von IP-Datagrammen - andere Netzwerkprotokolle können nicht verwendet werden.

Your Point

Auf Ihrer Seite unterscheiden sich die Voraussetzungen für den Einsatz von PPP nur unwesentlich von den Erfordernissen, die die Verwendung von SLIP mit sich bringt - genaugenommen ist der einzige Unterschied der, daß anstelle der SLIP-Software PPP-Software benötigt wird. Detaillierte Angaben zu diesen Voraussetzungen finden Sie im Artikel SLIP sliding away.

Point-to-Point Protocol-Software

Die Konzepte von PPP müssen am Arbeitsplatzrechner durch die entsprechende Software umgesetzt werden. Dabei ist zu beachten, daß die meisten verfügbaren Produkte nicht die gesamte Funktionalität von PPP aufweisen (was für den betrachteten Verwendungszweck auch gar nicht notwendig ist), sondern häufig nur eine Submenge aller Funktionen unterstützen. So beherrscht etwa eine Vielzahl der Produkte nur IP als Netzwerkprotokoll. Teilweise wurde aber auch auf die Implementierung von Funktionen verzichtet, die hin und wieder durchaus von Nutzen wären - z.B. das Aushandeln von Steuerzeichen, um den Einsatz von Software-Flußkontrolle zu ermöglichen.

Die meisten PPP-Softwarepakete unterstützen zusätzlich auch eine Skript-Sprache, mit der sich der gesamte Verbindungsaufbau automatisieren läßt (wodurch Ihnen das lästige Eingeben der Modembefehle, des Usernamens, des Paßworts und des PPP-Kommandos erspart bleibt, das andernfalls bei jedem neuen Verbindungsaufbau nötig ist). Andere Pakete sind jedoch nicht in der Lage, Skripts zu verwenden, sondern erwarten von ihrem Kommunikationspartner, daß er ein Authentisierungsverfahren unterstützt. Solche Produkte sind derzeit an der Uni Wien - falls überhaupt - nur mit Tricks und einiger Mühe verwendbar.

Für den Endanwender steht neben kommerziellen PPP-Paketen eine Reihe von Freeware-, Public Domain- und Shareware-Produkte für die verschiedensten Rechnersysteme zur Verfügung:

  • OS/2 Warp, WindowsNT und Windows 95 werden standardmäßig mit PPP-Software ausgeliefert.
  • Benutzern von Windows 3.x wird die Verwendung von "Trumpet Winsock" empfohlen. Dieses teilweise vorkonfigurierte Shareware-Paket wird vom EDV-Zentrum zur Verfügung gestellt. Hinweise zu Bezugsquelle, Installation und Verwendung finden Sie im Informationsblatt SLIP/PPP-Software für Windows - Trumpet Winsock, das in Form einer PostScript-Datei vom FTP-Server der Universität Wien oder in Papierform über die Servicestelle des EDV-Zentrums bezogen werden kann.
  • Macintosh-Rechner können mit dem Freeware-Paket "MacPPP" PPP-tauglich gemacht werden. Alle nötigen Informationen dazu finden Sie im Informationsblatt PPP-Software für Apple-Macintosh - MacPPP. Dieses liegt ebenfalls in Form einer PostScript-Datei am FTP-Server der Uni Wien bzw. in Papierform in der Servicestelle des EDV-Zentrums auf.

The final Points

Die Konfiguration von Modem und PPP-Software sollte, wenn man sich an die entsprechenden Installations-, Konfigurations- und Bedienungsanleitungen hält, kein Problem darstellen. Einige allgemeine Einstellungsempfehlungen sowie alle üblicherweise für den Betrieb von PPP-Software notwendigen Parameter finden Sie im Kasten Useful Points. Falls die Modifikation nicht erwähnter Parameter erforderlich werden sollte, ziehen Sie bitte die Dokumentation zu Ihrer PPP-Software zu Rate.

Die prinzipielle Vorgangsweise beim Verbindungsaufbau deckt sich bis inklusive Punkt 5 mit derjenigen, die im Artikel Ausgetrickst: Auf Schleichwegen zum FTP-Server dargestellt ist. Anschließend ist nur noch ein Schritt notwendig: Sie müssen das Kommando ppp eingeben, um den PPP-Betrieb am Terminalserver zu starten. Daraufhin sollten die beiden Kommunikationspartner - Ihre PPP-Software und der Terminalserver des EDV-Zentrums - mit dem Aushandeln der Einstellungen beginnen, was in der Regel ein paar Sekunden in Anspruch nimmt. Im Anschluß daran sollte die PPP-Verbindung betriebsbereit sein.

Anhand der prinzipiellen Vorgangsweise beim Verbindungsaufbau, der Dokumentation zur PPP-Software und der Erfahrungen, die bei einem entsprechenden manuellen Verbindungsaufbau - eventuell mit einem Terminalprogramm - gewonnen werden können, kann ein Skript zur Automatisierung des Verbindungsaufbaus entwickelt werden. (Die Skriptdatei, die der Trumpet Winsock-Distribution für die Universität Wien beiliegt, ist übrigens auch PPP-tauglich, und die MacPPP-Distribution ist ebenfalls mit einer funktionierenden Skript-Datei ausgestattet.)

Nach geglückter Installation und Konfiguration der PPP-Software sowie erfolgreichem Verbindungsaufbau können Sie mit den entsprechenden Netzwerkklienten (die Sie natürlich auch auf Ihrem Arbeitsplatzrechner installieren müssen) alle Dienste des Internet in gleicher Weise benutzen wie über einen direkten Anschluß ans Internet - abgesehen von Übertragungsgeschwindigkeit und Bedienungskomfort.

100 Points

... (in Worten: einhundert Punkte) haben Sie gewonnen, wenn PPP auf Ihrem Arbeitsplatzrechner einwandfrei und zu Ihrer vollsten Zufriedenheit funktioniert. Der Gewinn berechtigt Sie zur Inanspruchnahme kostenloser Unterstützung zum Thema PPP durch das EDV-Zentrum. Sollten Sie jedoch noch immer 0 Points (in Worten: null Punkte) haben und bei Ihren Bestrebungen, mittels Wählleitungszugang ins Internet zu gelangen, bereits den Point of no return überschritten haben, so stehen Ihnen immerhin die Alternativen zu PPP zur Verfügung - möglicherweise sind beim Wählleitungszugang mittels SLIP oder mittels eines Terminalprogramms die Punkte leichter zu erringen.

Useful Points

Hinweis: Bitte seien Sie nicht beunruhigt, wenn Sie bei Ihrer PPP-Software nicht für alle nachfolgend angeführten Parameter Verwendung finden - in der Regel erfordert der Betrieb von PPP-Verbindungen nur einen Teil davon.

Telefonnummern der Modemserien:
4078770 (15 Modems in Serie, Terminalserver PLATO.UNIVIE.AC.AT)
4068971 (5 Modems in Serie, Terminalserver HOMER.UNIVIE.AC.AT)

Baud Rate:
Die serielle Leitung zwischen Modem und Computer sollte mit der höchstmöglichen vom Modem, von der seriellen Schnittstelle und von der Software unterstützten Geschwindigkeit betrieben werden.

Datenformat für die PPP-Verbindung:
8 Datenbits, 1 Stopbit, No Parity

Default Gateway:
PLATO.UNIVIE.AC.AT (131.130.99.11),
HOMER.UNIVIE.AC.AT (131.130.99.25)

Domain suffix:
UNIVIE.AC.AT

Flußkontrolle:
Software-Flußkontrolle (XON/XOFF) wird zwar theoretisch von PPP, nicht aber von jedem PPP-Softwarepaket unterstützt. Da Hardware-Flußkontrolle (RTS/CTS) ohnedies einen höheren Datendurchsatz ermöglicht und zuverlässiger arbeitet, wird deren Verwendung angeraten.

IP-Adresse:
Wird nach der Eingabe des PPP-Kommandos durch die Kommunikationspartner ausgehandelt.

MRU (Maximum Receive Unit), MTU (Maximum Transmission Unit):
Übliche Werte für MRU sind 296, 576, 1006 und 1500 - wobei 1500 die höchstzulässige Obergrenze darstellt. Es kann nach folgender Faustregel vorgegangen werden (wobei - je nach lokalen Bedingungen - meist ein Kompromiß zielführend sein wird): Bei vorwiegend interaktiver Arbeit (z.B. Telnet) bzw. bei schlechter Leitungsqualität sollte der MRU-Wert niedrig gewählt werden; für die Übertragung größerer Datenmengen (z.B. mittels FTP) bzw. bei guter Leitungsqualität empfiehlt sich ein möglichst hoher Wert für MRU. Bei bestimmten PPP-Paketen ist bei einer Änderung der MRU auch eine Adaptierung der Werte für TCP MSS und TCP RWIN notwendig.

Nameserver:
131.130.1.11, 131.130.1.12

Netmask:
255.255.255.0

PPP-Kommando:
ppp

Serial Port:
Bezeichnung der seriellen Schnittstelle, an der das Modem angeschlossen ist.

TCP MSS (TCP Maximum Segment Size):
Der Wert für TCP MSS sollte MRU - 40 betragen.

TCP RWIN (TCP Receive Windows):
Für den Wert von TCP RWIN wird die Wahl des 3- oder 4fachen Wertes von TCP MSS empfohlen.

Timeserver:
TS1.UNIVIE.AC.AT (131.130.1.12),
TS2.UNIVIE.AC.AT (131.130.1.11)