Kopie

Transcription

Kopie

Deutsche Telekom AG - Fachhochschule Leipzig
Konzipierung eines Softwarepakets für die
Installation und Konfiguration eines
DSL-Breitbandzugangs zum IP-Backbone der
envia.tel GmbH
Diplomarbeit
Jörg Brenner
Deutsche Telekom AG - Fachhochschule Leipzig
Konzipierung eines Softwarepakets für die Installation
und Konfiguration eines DSL-Breitbandzugangs zum
IP-Backbone der envia.tel GmbH
Angefertigt von:
Jörg Brenner (98 102)
Beginn:
04. 03. 2002
Ende:
26. 08. 2002
Erstprüfer / Betreuer:
Prof. Dr. rer. nat. Thomas Möbert
Zweitprüfer / Betreuer: Dipl.-Ing. Karsten May
Vorwort
DSL ist, durch Nutzung der Kupfer-Doppelader für hohe Übertragungsbandbreiten, die Technologie, die Breitbandzugang für Privatpersonen erst möglich gemacht
hat. Der Zugang wird mit dem Point-to-Point-Protocol over Ethernet“ (PPPoE)
”
hergestellt, wofür spezielle Software (PPPoE-Clients) auf dem Markt erhältlich
ist.
Der Schwerpunkt dieser Diplomarbeit liegt bei dem Test mehrerer PPPoE-Clients auf
verschiedenen Windowsversionen hinsichtlich bestimmter Kriterien, damit der envia.tel
GmbH die Wahl eines der PPPoE-Clients ermöglicht wird. Dies schließt Leistungsmessungen ebenso ein wie Bewertung der Installationsprozedur.
Diese Diplomarbeit ist gleichzeitig der Abschluß eines vierjährigen Studiums der Nachrichtentechnik an der Fachhochschule der Deutschen Telekom AG“. Aus diesem Grund
”
gilt mein Dank an dieser Stelle den Dozenten und Lehrkräften für die Themenvermittlung und Unterstützung während des Studiums.
Für die Unterstützung bei der Erarbeitung dieser Diplomarbeit sei insbesondere den
beiden Betreuern Herrn Dipl.-Ing. Karsten May und Herrn Prof. Dr. Thomas Möbert
gedankt. Mein Dank gilt ebenfalls der envia.tel GmbH für die Unterstützung bei der
Erstellung der Arbeit.
Leipzig, August 2002
Jörg Brenner
Inhaltsverzeichnis
Abkürzungsverzeichnis
x
I
Einführung
1
II Methoden
4
1 Das OSI-Referenzmodell
5
2 G.SHDSL
2.1 Einleitung . . . . . . . . .
2.2 G.SHDSL im Netzwerk . .
2.3 Referenzmodell . . . . . .
2.4 Übertragungsmedium . . .
2.5 Rahmenstruktur . . . . . .
2.5.1 Rahmenstruktur im
2.5.2 Rahmenstruktur im
2.6 ATM-Transport über DSL
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
Aktivierungsmodus
Datenmodus . . . .
. . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 PPPoE
3.1 Vorbemerkung/Allgemeines . . . . . . . . . . . . . . . . . . .
3.2 Rahmenstruktur . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Ethernet- und PPPoE-Rahmen . . . . . . . . . . . . .
3.2.2 Struktur der PPPoE-Nutzdaten in der Discovery-Phase
3.2.3 Struktur der PPPoE-Nutzdaten in der Session-Phase .
3.3 Ablauf des Verbindungsaufbaus mit PPPoE . . . . . . . . . .
3.3.1 Überblick . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Discovery-Phase . . . . . . . . . . . . . . . . . . . . . .
3.3.3 PPP-Phase . . . . . . . . . . . . . . . . . . . . . . . .
4 Windows-Netzwerkarchitektur
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8
9
11
11
12
12
13
14
.
.
.
.
.
.
.
.
.
16
16
16
17
18
18
20
20
21
25
27
iv
Inhaltsverzeichnis
III Durchführung
31
5 Testaufbau
32
6 Testablauf
34
6.1 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
6.2 Testablauf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
7 Testprotokoll
37
IV Resultate
42
8 Vorbetrachtungen zur Auswertung
43
8.1 Datenrate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.2 CPU-Belastung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
9 Clients
9.1 cFOS DSL OEM . . . . . . . . . . . . . .
9.1.1 Stellung in der Netzwerkarchitektur
9.1.2 Installation . . . . . . . . . . . . .
9.1.3 Leistung . . . . . . . . . . . . . . .
9.1.4 Bewertung . . . . . . . . . . . . . .
9.2 Enternet 300 Win . . . . . . . . . . . . . .
9.2.2 Installation . . . . . . . . . . . . .
9.2.3 Leistung . . . . . . . . . . . . . . .
9.2.4 Bewertung . . . . . . . . . . . . . .
9.3 POETRI . . . . . . . . . . . . . . . . . . .
9.3.2 Installation . . . . . . . . . . . . .
9.3.3 Leistung . . . . . . . . . . . . . . .
9.3.4 Bewertung . . . . . . . . . . . . . .
9.4 RASPPPOE . . . . . . . . . . . . . . . . .
9.4.2 Installation . . . . . . . . . . . . .
9.4.3 Leistung . . . . . . . . . . . . . . .
9.4.4 Bewertung . . . . . . . . . . . . . .
9.5 WinPOET . . . . . . . . . . . . . . . . . .
9.5.2 Installation . . . . . . . . . . . . .
9.5.3 Leistung . . . . . . . . . . . . . . .
9.5.4 Bewertung . . . . . . . . . . . . . .
9.6 Windows XP nativ . . . . . . . . . . . . .
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
46
46
46
47
47
48
48
48
49
49
50
50
50
51
51
51
51
53
53
54
54
54
54
55
55
55
Inhaltsverzeichnis
9.7
Roaring Penguin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
V Diskussion
57
VI Anhang
62
A Grafiken
63
B Testprotokoll
75
C Systeminformationen
80
VII Installationsanleitung EnterNet
83
vi
Abbildungsverzeichnis
1.1
Vertikale Schnittstellen-Entities (modifiziert nach [5]) . . . . . . . . . .
7
ATM-Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TDM-Netzwerk mit ATM-Backbone . . . . . . . . . . . . . . . . . . . .
TDM-Netzwerk mit Ethernet . . . . . . . . . . . . . . . . . . . . . . .
Protokoll-Referenzmodell (modifiziert nach [2]) . . . . . . . . . . . . . .
SHDSL-Rahmenstruktur im Aktivierungsmodus . . . . . . . . . . . . .
SHDSL-Rahmenstruktur im Datenmodus bei synchroner Übertragung
(modifiziert nach [2]) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.7 Referenzmodell im ATM-Modus (modifiziert nach [2]) . . . . . . . . . .
9
10
10
11
12
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
Ethernet-Rahmen mit eingebetteten PPPoE-Rahmen
Payload in Discovery-Phase . . . . . . . . . . . . . .
Payload in PPP-Session . . . . . . . . . . . . . . . .
Ablauf der Discovery-Phase . . . . . . . . . . . . . .
PADI-Paket . . . . . . . . . . . . . . . . . . . . . . .
PADO-Paket . . . . . . . . . . . . . . . . . . . . . .
PADR-Paket . . . . . . . . . . . . . . . . . . . . . .
PADS-Paket . . . . . . . . . . . . . . . . . . . . . . .
PADT-Paket . . . . . . . . . . . . . . . . . . . . . . .
PPP-Phasendiagramm (modifiziert nach [10]) . . . .
.
.
.
.
.
.
.
.
.
.
16
18
19
21
22
23
23
24
24
26
4.1
4.2
4.3
Netzwerkarchitektur von Windows NT (modifiziert nach [5]) . . . . . .
Netzwerkprotokoll-Bindung . . . . . . . . . . . . . . . . . . . . . . . .
Intermediate Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
28
29
5.1
Testaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
6.1
Datenfluss und Befehle Upstream (oben) und Downstream (unten) . . .
36
9.1
9.2
Virtueller Netzwerkadapter in der Windows-Netzwerkarchitektur . . . .
NDIS Intermediate Driver zwischen Protokoll- und NIC-Treiber (modifiziert nach [7]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
A.1 Legende . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A.2 Datenrate und CPU-Belastung / Downstream / Windows 95 . . . . . .
63
64
2.1
2.2
2.3
2.4
2.5
2.6
vii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
14
52
Abbildungsverzeichnis
A.3 Datenrate
A.4 Datenrate
A.5 Datenrate
A.6 Datenrate
A.7 Datenrate
A.8 Datenrate
A.9 Datenrate
A.10 Datenrate
A.11 Datenrate
A.12 Datenrate
B.1
B.2
B.3
B.4
und
und
und
und
und
und
und
und
und
und
Testprotokoll
Testprotokoll
Testprotokoll
Testprotokoll
–
–
–
–
CPU-Belastung
CPU-Belastung
CPU-Belastung
CPU-Belastung
CPU-Belastung
CPU-Belastung
CPU-Belastung
CPU-Belastung
CPU-Belastung
CPU-Belastung
/
/
/
/
/
/
/
/
/
/
Downstream / Windows 98 . . .
Downstream / Windows ME . .
Downstream / Windows NT . .
Downstream / Windows 2000 . .
Upstream / Windows 95 . . . .
Upstream / Windows 98 . . . .
Upstream / Windows ME . . . .
Upstream / Windows NT . . . .
Upstream / Windows 2000 . . .
Windows XP & SuSE-Linux 7.1
Allgemeiner Teil I . . . .
Allgemeiner Teil II . . .
Performance Downstream
Performance Upstream .
viii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
65
66
67
68
69
70
71
72
73
74
.
.
.
.
.
.
.
.
.
.
.
.
76
77
78
79
Tabellenverzeichnis
3.1
3.2
3.3
Paket-Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TAG TYPES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Protokollcode-Gruppen . . . . . . . . . . . . . . . . . . . . . . . . . . .
ix
17
19
20
AAL
ATM Adaption Layer
AC
Access Concentrator
API
Application Programming Interface
ATM
Asynchronous Transfer Mode
CPU
Central Processing Unit
CSA
Carrier Serving Area
DEE
Datenendeinrichtung
DLL
Digital Local Line
DOS
Disk Operating System
DSL
Digital Subscriber Line
DSLAM Digital Subscriber Line Access Multiplexer
DÜE
Datenübertragungseinrichtung
HDLC
High-Level Data Link Control
IAD
Integrated Access Device
ICI
Interface Control Information
IDU
Interface Data Unit
IM
Intermediate Driver
ISO
International Organisation for Standardization
ISP
Internet Service Provider
LCP
Link Control Protocol (PPP)
LSB
Least Significant Bit
LTU
Line Termination Unit
MAC
Media Access Control
MODEM Modulator/Demodulator
MRU
Maximum Receive Unit
MSB
Most Significant Bit
MSS
Maximum Segment Size
MTU
Maximum Transmission Unit
NCP
Network Control Protocol (PPP)
NDIS
Network Driver Interface Specification
NIC
Network Interface Card
NT
Network Termination
NTU
Network Termination Unit
OSI
Open System Interconnection
x
PDH
PDU
PPP
PPPoE
PSTN
RPM
SAP
SDH
SHDSL
SDU
TDI
TDM
TTL
URL
UTOPIA
WAN
WWW
Plesiochrone Digitale Hierarchie
Protocol Data Unit
Point-to-Point Protocol
Point-to-Point Protocol over Ethernet
Public Switched Telephone Network
Redhat Package Manager
Service Access Point
Synchrone Digitale Hierarchie
Symmetrical Single Pair High Bitrate Digital Subscriber Line
Service Data Unit
Transport Driver Interface
Time Division Multiplexing
Time To Live
Uniform Resource Locator
Universal Test & Operations PHY Interface for ATM
Wide Area Network
World Wide Web
xi
Teil I
Einführung
1
Die Geschichte der Datennetze vollzog eine rasante Entwicklung in den letzten Jahrzehnten. Anfangs als militärisches Projekt geplant und genutzt, entwickelten die später
ebenfalls universitär genutzten Datennetze eine Eigendynamik, die noch bis heute anhält. Immer im Mittelpunkt standen die Zugangspunkte zu den Netzen, die erst eine
Teilnahme am Daten- und Informationsaustausch ermöglichten.
In der Frühzeit der Datennetze waren die Zugangspunkte (wenige) Terminals in den
Universitäten, die, an Groß- und Minirechner angeschlossen, nur einer exklusiven Teilnehmerzahl Netzzugang ermöglichten. Im Laufe der Zeit, mit der weiteren Miniaturisierung der Rechner bei gleichzeitiger Erweiterung der Speicherkapazität und Verarbeitungsgschwindigkeit, fand eine Entwicklung vom am Großrechner angeschlossenen
Terminal hin zum Personal Computer statt.
Dies hatte zur Folge, dass nicht nur Universitäten und dem Militär die Nutzung von
Rechenkapazität und Netzinfrastruktur möglich war, sondern die Computer eine weitere Verbreitung in Firmen und Privathaushalten erlangten. Der Zugang zu den Netzen
erfolgte nun über Datenfernübertragung (DFÜ), vor allem mit Modems. Die Zugangspunkte bildeten neben den Universitäten nun erstmals als Internet Service Provider
(ISP) auftretende Firmen. Gleichzeitig bildete sich ausserhalb der USA eine Subkultur an öffentlichen Datennetzen, wie z.B. das im deutschen Raum verbreitete Fido-Net,
die Datenaustausch über proprietäre Systeme erlaubten und untereinander weitgehend
inkompatibel waren. In dieser Zeit bildeten auch viele privat betriebene Mailboxen Zugangspunkte zu den Netzen.
Erst in den frühen 90er Jahren des vorigen Jahrhunderts begann die Verdrängung der
kleineren Netze durch das Internet – auch unter dem Gesichtspunkt der kulturellen,
wirtschaftlichen und militärischen Übermacht der USA. Immer mehr Firmennetze wurden dem Internet angeschlossen und das Internet rückte zunehmend in den Blickpunkt
der Öffentlichkeit. Waren anfangs die Computernutzer als Geeks“ verschrieen, vollzog
”
sich in dieser Hinsicht ein Wandel hin zur Normalität, was ebenfalls großen Einfluss
auf die Inhalte hatte. Dies hatte zur Folge, dass sich eine gewisse kritische Masse an
potentiellen Nutzern des Internets gebildet hatte und sich deswegen neben den großen
Providern wie AOL oder Compuserve auch viele kleinere ISP bildeten. Netzzugang wurde billiger und eine Spirale des Preisverfalls setzte sich in Gang.
All den Internetzugängen für die populäre Masse war zu der Zeit gemeinsam, dass sie
nur schmalbandigen Zugriff auf das Internet boten – ausser wenigen großen Institutionen konnten sich nur wenige kleinere Firmen oder Privatpersonen breitbandigen Internetzugang leisten. Der schmalbandige Zugriff wurde im Allgemeinen über Modems
realisiert, die mit ihren standardisierten AT-Befehlen die notwendige Kompatibilität
boten.
In den letzten Jahren entwickelte sich das Internet dank der großen Nutzerzahl zu
einer werbeorientierten Plattform, die neben den üblichen Textdokumenten mehr und
mehr audiovisuelle Informationen bietet, welche mit ihren Dateigrößen über schmalbandige Modem-Zugänge nur langsam übertragen werden können. Es entstand der
2
Bedarf nach Breitbandzugängen, dem gegenwärtig durch ISP nachgekommen wird
und so entwickelte sich ein reichhaltiges, wiewohl recht teures Angebot an verschiedenen Breitbandtechnologien wie DSL, Zugang über Satelliten oder Breitbandkabel.
Besonders ersteres entwickelte sich durch den niedrigen Preis der Deutschen Telekom
zum Volks“-Breitbandzugang, was Hardware billiger und damit wiederum für kleinere
”
Provider interessant werden lässt.
Um eine weite Verbreitung der DSL-Technologie bei den Kunden zu erreichen, stellt
sich bei den Netzbetreibern, die das Point-to-Point Protocol over Ethernet“ (PPPoE)
”
zur Abrechnung und Authentifizierung nutzen, die Frage nach einfacher Einrichtung
und Konfiguration des entsprechenden PPPoE-Clients, der dieses Protokoll implementiert. Durch die bereits erwähnte weite Verbreitung von Computern verfällt das Mono”
pol“ der Computerexperten und auch Normalnutzer wollen mit wenig Aufwand diese
Software einrichten und benutzen. Mehrere Firmen haben sich dem Ziel verschrieben,
diesem Anspruch auf dem Gebiet der DSL-Zugangssoftware gerecht zu werden und
dies gilt es mit der vorliegenden Arbeit zu überprüfen. Neben der einfachen Einrichtung interessieren dabei den Nutzer auch die Leistung des PPPoE-Clients, der möglichst die beste Performance aus der Kombination Rechenleistung/DSL-Zugang bieten
soll.
Diese Arbeit behandelt in Teil I Methoden“ alle vorbereitenden Betrachtungen zum
”
Thema OSI-Modell, PPPoE, der Windows-Netzwerkarchitektur sowie SHDSL, da letzteres bei envia.tel eingesetzt wird. Teil II Durchführung“ beschreibt die Testdurchfüh”
rung inklusive Testaufbau, -ablauf und -protokoll. Im darauf folgenden Teil III werden
die Resultate dargestellt, wobei zu jedem PPPoE-Client Bemerkungen zur Stellung in
der Netzwerkarchitektur, zur Installation und zur Leistung sowie eine abschließende
Bewertung zu finden sind. Die Diskussion in Teil IV soll Alternativen aufzeigen und
eine Bewertung der einzelnen Clients erleichtern.
Abschließend soll ein Paket auf CD entstehen, welches das PPPoE-Programm sowie eine entsprechende Anleitung für die Kunden von envia.tel enthält, damit
diese ohne weitere benötigte Software den DSL-Zugang selbste einrichten können.
3
Teil II
Methoden
4
Unter der Zielsetzung, einen Standard für den Datenaustausch zwischen verschiedenen
Kommunikationssystemen zu etablieren, entwickelte die International Organisation for
Standardization (ISO) ab 1977 das OSI-Referenzmodell (Open System Interconnection). In der vorliegenden Arbeit wird dieses Modell zur Beschreibung von Verbindungen
benutzt.
Das Referenz- oder Schichtenmodell unterteilt Kommunikationsprotokolle und -dienste
in eine Hierarchie aus sieben Schichten. Die Bezeichnung der Schichten sowie deren
Aufgaben stellen sich wie folgt dar:
Bitübertragungsschicht/Physical Layer: Diese Schicht stellt den übergeordneten
Schichten die physikalische Übertragungshardware zur Verfügung, indem sie für
eine transparente Bitübertragung über dieses Medium sorgt. Dies erfordert elektrische und mechanische Anpassung an die Parameter der Datenübertragungseinrichtung (DÜE).
Sicherungsschicht/Data Link Layer: Der serielle Bitstrom (Schicht 1) zwischen
zwei direkt benachbarten Datenendeinrichtungen (DEE) wird in der Sicherungsschicht in Abschnitte wie Rahmen oder Zellen unterteilt, damit eine Fehlererkennung und -korrektur stattfinden kann. Rahmen oder Zellen können Header,
Trailer und/oder Daten enthalten. Zusätzlich stellt diese Schicht weitere Dienste
wie Datenflußkontrolle und Blocksynchronisation bereit.
Netzschicht/Network Layer: In der Netzschicht müssen Datenquelle und Senke
nicht mehr direkt benachbart sein, die Datenübertragung im Netz erfolgt nur
über eine logische Verbindung. Dies erfordert die Umsetzung von vermittlungstechnischen Funktionen zum Routing sowie Auf- und Abbau von Netzverbindungen. Diese Schicht übermittelt des Weiteren Benutzerdaten für Billing und
Accounting. Wie in Schicht 2 kann auch hier Fehlererkennung und -korrektur
stattfinden.
Transportschicht/Transport Layer: Die Transport-Schicht sorgt für die Verbindung zweier DEE auf einer logischen Ebene, d. h. die konkrete Netzrealisierung
ist bei dieser und allen darüberliegenden Schichten ohne Belang. Es werden auf
dieser Ebene nur noch Verbindungen zwischen logischen Informationsquellen und
-senken hergestellt, welche über Transportadressen angesprochen werden. Neben
5
dem Verbindungsaufbau werden in dieser Schicht Prioritätsanforderungen oder
qualititativ unterschiedliche Verbindungen realisiert.
Sitzungsschicht/Session Layer: In der Sitzungsschicht werden Synchronisations-,
Koordinations- und Verwaltungsdienste angeboten, die für Verbindungen zwischen zwei Prozessen benötigt werden.
Darstellungsschicht/Presentation Layer: In dieser Schicht werden zum gegenseitigen Verständis der Kommunikationspartner Transformationen der Daten vorgenommen, damit diese einheitlich interpretiert werden können.
Anwendungsschicht/Application Layer: Dies ist die einzige Schicht, die eine direkte Schnittstelle zu den Applikationen bietet und Hilfsdienste zu deren Implementation anbietet.
Die lokalen aktiven Protokollelemente einer Schicht, auf deren Basis die Schnittstellendokumentation stattfindet, werden als entities 1 bezeichnet, die einer entfernten DEE
peer entities. Beide Entitäten befinden sich in einer Schicht des oben beschriebenen
OSI-Schichtmodells. Zwischen den Schichten darf Kommunikation nur über definierte Schnittstellen (Service Access Point, SAP) stattfinden. Jede Schicht stellt dabei
den nächsthöheren seine Dienste über diese dokumentierte Schnittstelle zur Verfügung und stützt sich mit Ausnahme der Schicht 1 selbst auf Dienste tieferer Schichten,
d. h. Schicht n implementiert Dienste, die von der Schicht n+1 genutzt werden können. Abbildung 1.1 stellt dar, wie die Kommunikation allgemein vertikal zwischen den
Schichten erfolgt.
Schnittstellenkommunikation im OSI-Modell
Das Paket, welches von der Schicht-n-Entität an die Entität der Schicht n-1, d. h. nach
unten weitergegeben wird, heißt interface data unit (IDU) und besteht aus Daten
(protocol data unit, PDU) sowie Schnittstellenkontrollinformation (interface control
information, ICI). Die PDU besteht aus dem Schicht-n-Header sowie Daten aus der
Schicht n+1 und ist die Dateneinheit, die an die peer entity übertragen werden soll.
Diese Einheit wird bei Weitergabe nach unten zur service data unit der Schicht n-1 (n1 SDU). Die ICI enthält Kontroll- und Adressierungsinformation, die für Verarbeitung
in Schicht n-1 notwendig sind.
Wenn Schicht n-1 die IDU erhält, löst es den Header von den Daten, verarbeitet diesen,
fügt neue Kontrollinformation sowie einen Header für die peer entity hinzu und gibt
das Paket weiter an die nächste darunterliegende Schicht.
1
Dies ist laut Zehnder [13] ein individuelles Exemplar von Elementen der realen oder der Vorstellungswelt. Sofern eine Beziehung zwischen Entitäten eine eigenständige Bedeutung in der realen
oder in der Vorstellungswelt hat, kann auch ein individuelles Exemplar einer solchen Beziehung
als Entität aufgefasst werden.
6
n IDU
n-1 ICI
nH
Daten
n PDU (n-1 SDU)
Schicht n
assimiliert
n-1 ICI
generiert
n-2 ICI
n-1
IDU
Schicht n-1
n-2 ICI
n-1 H
nH
Daten
nH
Daten
n-1 PDU (n-2 SDU)
n-1 H
nH
Dienst-Nutzung
Dienstbereitstellung
Schnittstelle n-1/n
Daten
Schnittstelle n-2/n-1
Schicht n-2
Abbildung 1.1: Vertikale Schnittstellen-Entities (modifiziert nach [5])
Im Sinne eines transparenten Datenaustausches zwischen zwei DEE2 muß gewährleistet sein, daß Schicht n der Ziel-DEE die Daten erhält, die Schicht n der Quell-DEE
gesendet hat. Dazu werden die Daten vom sendenden Prozess an Schicht 7 und von
dort vertikal nach unten durchgereicht – jede Schicht generiert dabei einen Header
mit Kontroll- und Adressinformationen und fügt die erhaltenen Daten ohne weitere Prüfung dahinter an. Nach der Übertragung auf dem tatsächlichen physikalischen
Transportmedium werden an der Ziel-DEE die Header durch die jeweiligen Schichten
verarbeitet, die angehängten Daten nach oben weitergereicht und die Nutzdaten dem
empfangenden Prozess letztlich zur Verfügung gestellt.
2
horizontaler Datenfluß
7
2 G.SHDSL
2.1 Einleitung
Symmetrical High-Density Digital Subscriber Line (SHDSL) ist eine digitale und symmetrische Übertragungstechnologie, die auf mehreren Vorgängern aufbaut. Allen gemeinsam ist die Leitungslänge, die bei maximaler Datenrate mindestens 12.000 ft bzw.
3937 m betragen muss, um den für Netzbetreiber interessanten Bereich, die Carrier
Serving Area (CSA), abzudecken. Entwickelt wurden folgende Standards für symmetrische Übertragungstechnologien:
ISDN (ab 1988)
– Standards: TS 102080 / T1.601 / G.961
– Basistechnologie
– Datenrate: 144 kBit/s pro Doppelader
– Leitungscode: 2B1Q
HDSL (ab 1994)
– Standards: T1E1.4-TR28 / G.991.1 / TS101135
– Datenrate: 784kBit/s, 1168 kBit/s (1996), 2320 kBit/s (1996)
pro Doppelader
HDSL2 (ab 1988) – T1E1.4 / HDSL2
– Datenrate: 1544 kBit/s pro Doppelader
– Leitungscode: TC-PAM
SHDSL (ab 2000) – Datenrate: 192–2320 kBit/s pro Doppelader (flexibel)
– Leitungscode: TC-PAM
SHDSL ermöglicht unter diesen drei Übertragungstechnologien als erstes variable Bitraten und damit den Einsatz in großen Netzwerken mit dem Optimum an Datenrate. Mit
SHDSL verwischt auch der Unterschied zwischen symmetrischen und asymmetrischen
Übertragungstechnologien – letztere werden benutzt, um Privatkunden möglichst preiswert Breitband-Zugang und Telefonie anbieten zu können. In den letzten Jahren erhöhte sich allerdings durch entsprechende neue Applikationen wie z.B. private Webserver der Bandbreitenbedarf und damit werden auch symmetrische DSL-Technologien
8
2 G.SHDSL
für den Privatkunden interessant. Mittelfristig werden allerdings neben SHDSL auch
die asymmetrischen DSL-Technologien im Einsatz bleiben, da sie besonders preiswert
anzubieten sind und für den Privatkundenbedarf nach einer Telefonleitung und Internetzugang ausreichen. ISDN stellt eine Alternative für diejenigen Kunden dar, die
ausserhalb der CSA wohnen.
SHDSL wird vor allem dort eingesetzt werden, wo maximale Flexibilität nötig ist,
da die 2,3 MBit/s flexibel auf Sprachkanäle und Datendienste aufgeteilt werden können und so verschiedene Konfigurationen wie z. B. 9 Sprachkanäle zusammen mit
1,7 MBit/s Internet-Zugang möglich sind.
2.2 G.SHDSL im Netzwerk
DSL-Lösungen sind unabhängig von dem Backbone, an den die Anbindung mittels
DSL erfolgt – diese Flexibilität ermöglicht neben dem Aufbau neuer Netze die Integration in bereits bestehende, heterogene Netze. Vor allem letzteres war die Zielvorgabe bei der Entwicklung von DSL. Beispielhaft ließen sich mehrere Szenarien anführen:
• Ein Unternehmen pflegt ein ausgedehntes Netzwerk mit vergleichsweise wenigen
Anschlussteilnehmern. Die unternehmenseigene Netzinfrastruktur liegt in Form
von Kupferdoppeladern vor oder ist über das öffentliche Fernsprechnetz realisiert.
Mit der DSL-Technologie kann preiswert die Bandbreite erhöht werden.
• Netzbetreiber, die ebenfalls als Internet Service Provider (ISP) agieren, können
mittels xDSL breitbandige Internetanbindung bis 2 MBit/s zusätzlich zu einem
bereits existierenden Telefonanschluss anbieten. Dies kann ohne Investition in
die Leitungsinfrastruktur geschehen, da für Telefonie und Datenverkehr nur die
Kupfer-Doppelader genutzt wird. Die Marktentwicklung in den letzten Jahren
zeigt dieses Bedürfnis vor allem für Geschäftskunden auf.
Voice
GW
Voice
Switch
LAN
IAD
DSL
ATM
Backbone
DSLAM
Telefon
ISP
Abbildung 2.1: ATM-Netzwerk
9
Internet
PSTN
2 G.SHDSL
• Mit xDSL lässt sich der vorhandene analoge Telefonanschluss über Kupferdoppelader auf mehrere Anschlüsse aufweiten, ohne in die Infrastruktur investieren
zu müssen. Dies ist aus Kostengründen ebenfalls für Netzbetreiber interessant.
Voice
Switch
PSTN
LAN
IAD
DSL
DSLAM
Telefon
ATM
Backbone
ISP
Internet
Abbildung 2.2: TDM-Netzwerk mit ATM-Backbone
Die Art der DSL-Anbindung an den Backbone des ISP ist abhängig von der BackboneStruktur des Telefondienstleisters. Bei ATM-Netzwerken (siehe Abb. 2.1) geschieht
die Anbindung mit einem Integrated Access Device (IAD), welches sowohl Sprache als
auch Daten in ATM-Zellen konvertiert. Sprache wird mit AAL11 oder AAL2, Daten
mittels AAL5 konvertiert. Die ATM-Zellen werden wiederum in einen SHDSL-Rahmen
eingeordnet, der eigentlichen Übertragungseinheit auf der DSL-Strecke. Auf Seite des
Netzanbieters werden die ATM-Zellen aus dem SHDSL-Rahmen im DSLAM extrahiert
und mit einem ATM-Switch entweder an ein Voice Gateway oder einen ISP weitergeleitet.
Verfügt der Netzanbieter über ein TDM-Netzwerk, geschieht die Anbindung mit einem
NT. Diese Lösung ähnelt, was die Sprachübertragung betrifft, eher der klassischen“
”
Telefonie – die digitalisierte Sprache wird ähnlich wie bei ISDN direkt in den SHDSLRahmen eingebettet. Die Daten müssen vor der Einbettung, falls der Netzbetreiber
über einen ATM-Backbone verfügt, entweder per IAD in ATM-Zellen konvertiert oder
in ein Datensicherungsprotokoll wie HDLC gepackt werden. Daraus resultiert ein Mix“
”
verschiedener Zellen im SHDSL-Rahmen, die auf der Gegenseite entsprechend dem
PSTN oder dem ATM-Netzwerk zugeführt werden müssen. Abbildung 2.2 zeigt diese
Voice
Switch
PSTN
LAN
IAD
DSL
DSLAM
Ethernet
ISP
Telefon
Abbildung 2.3: TDM-Netzwerk mit Ethernet
1
ATM Adaption Layer
10
Internet
2 G.SHDSL
Möglichkeit. Verfügt der Netzbetreiber über kein ATM-Netzwerk, kann anstelle der
ATM-Zellen direkt mit Ethernet-Frames gearbeitet werden – die Weiterleitung zum
ISP findet dann entweder mit normalem Ethernet zusammen mit Repeatern oder mit
Long Range Ethernet statt, welches weit längere Übertragungswege ermöglicht; dies
ist in Abbildung 2.3 dargestellt.
2.3 Referenzmodell
Die Protokoll-Referenzmodell ist in Abbildung 2.4 dargestellt und stellt eine symmetrische Verbindung mit einer Bandbreite bis 2320 kbit/s sowie einen optionalen unabhängigen Schmalbandkanal mit 8 kbit/s bereit. Letzterer kann sowohl für einen ISDN-BA
als auch einen Analog-Telefonanschluss genutzt werden.
Das SHDSL-Übertragungssystem besteht aus der Line Termination Unit (LTU) auf
Netzbetreiberseite und der Network Termination Unit (NTU) auf Kundenseite. Beide
Teile bilden, zusammen mit der Schicht Physical Media Specific Transmission Convergence (PMS-TC), dem Transceiver sowie der Digital Loop Line (DLL), den vom physischen Medium abhängigen SHDSL-Kern, der die an seinen internen Schnittstellen anliegenden Daten transparent zwischen LTU und NTU überträgt. Neben dem Datenaustausch sind dem Kern Aufgaben wie (De)Scrambling, (De)Codierung, (De)Modulation,
Echo-Unterdrückung sowie das Timing-Verhalten übertragen.
Vom physischen Medium unabhängig ist die Schicht Transmission Protocol Specific
Transmission Convergence (TPS-TC), die anwendungsspezifische Aufgaben wie zum
Beispiel Kanal-(De)Multipexing, Rahmung, Rahmensynchronisation, Fehlererkennung
und Wartung übernimmt.
2.4 Übertragungsmedium
Um mittels SHDSL Daten zu übertragen, wird ein physisches Übertragungsmedium
benötigt. Dieses ist die im Ortsnetz eingebundene digitale Ortsleitung (digital local line,
DLL), welche im Allgemeinen aus einer Kupfer-Doppelader besteht. Ausnahmen für
die letztere Regel stellen die Fälle dar, wo mittels FTTH (fibre to the home) oder FTTC
UNI
NTU
LTU
Transport-Protokoll
Transport-Protokoll
TPS-TC
TPS-TC
PMS-TC
PMS-TC
Transceiver
Transceiver
physisches Medium
SNI
Abbildung 2.4: Protokoll-Referenzmodell (modifiziert nach [2])
11
2 G.SHDSL
(fibre to the curb) die Ortsleitung auf Basis optischer Übertragungsmedien realisiert
ist und jegliche DSL-Derivate nicht genutzt werden können.
Unter Voraussetzung der Doppelkupferader muss SHDSL mit einer Vielzahl von verschiedenen Leitern operieren können, damit SHDSL weit verbreitet eingesetzt werden
kann. Vor allem ältere, unter Umständen noch mit Papier isolierte, oder besonders
lange Leitungen stellen in der Hinsicht hohe Anforderungen an das Übertragungssystem. Variierende elektrische Parameter bei unterschiedlichen Leitungen sind z. B.
die Impedanz oder die Gruppenlaufzeit, andere charakteristische, die Leitungen beschreibende Merkmale wären z. B. Noise (Rauschen) oder Übersprechen. Letzteres
entsteht bei elektromagnetischer Kopplung zweier oder mehrerer Leitungen. Grundsätzlich kann SHDSL auch auf Leitungen mit ungünstigen Parametern eingesetzt
werden, da durch die flexible Bitrate sowie variablem Pegel eine Anpassung möglich
ist.
2.5 Rahmenstruktur
2.5.1 Rahmenstruktur im Aktivierungsmodus
Der SHDSL-Rahmen ist unterschiedlich zusammengesetzt, je nachdem, ob sich die
Verbindung im Aktivierungs- oder Datenmodus befindet.
Der Aktivierungsmodus dient zur Stabilisierung der Verbindung, indem alle Transceiverkoeffizienten ausgetauscht und die Rahmen synchronisiert bzw. entsprechend ausgerichtet werden. Der Rahmen ist innerhalb dieser Phase 4227 Bit groß, in Abbildung
2.5 dargestellt und wie folgt zusammengesetzt:
• 14 Bit Rahmensynchronisation
• Precoder-Koeffizienten 1. . .180 zu je 22 Bit, mindestens 128 Koeffizienten sind
notwendig
• Encoder-Koeffizienten A, B zu je 21 Bit
21
128
67
16
reserviert
CRC
PrecoderKoeffizient 03
21
Betreiberdaten
...
22
EncoderKoeffizient B
22
EncoderKoeffizient A
22
22
SHDSLRahmen
14
RahmenSynchronisation
• 128 Bit betreiberspezifische Daten
[Bits]
Abbildung 2.5: SHDSL-Rahmenstruktur im Aktivierungsmodus
12
2 G.SHDSL
• 67 reservierte Bits
• 16 CRC-Bits zur Fehlererkennung und -korrektur
2.5.2 Rahmenstruktur im Datenmodus
n*8
n*8
n*8
2
[Bits]
leer
n*8
...
...
Payload-Block 48
i
12 * ( i + n * 8 )
Payload-Block 37
B4
...
10
Overhead
B3
Payload-Block 36
B2
Overhead
i
B1
Payload-Block 25
i
12 * ( i + n * 8 )
Zi
...
Payload-Block 24
i
10
...
Overhead
Z3
Payload-Block 13
Z2
...
Payload-Block 12
Z1
12 * ( i + n * 8 )
Payload-Block 03
PayloadBlock
10
Payload-Block 02
SHDSLRahmen
(6 ms)
Overhead
12 * ( i + n * 8 )
Payload-Block 01
2
Sync-Wort
14
Bn
n*8
[Bits]
Abbildung 2.6: SHDSL-Rahmenstruktur im Datenmodus bei synchroner Übertragung
(modifiziert nach [2])
Nach der Stabilisierung der Verbindung können im Datenmodus Nutzdaten übertragen
werden. Die Bitstruktur der SHDSL-Rahmenstruktur vor Scrambling und Codierung
ist in Abbildung 2.6 dargestellt.
Die nominelle Rahmenlänge beträgt 6 ms, innerhalb derer die vier Rahmengruppen
übertragen werden, in welche jeder Rahmen eingeteilt ist. Die erste Gruppe beginnt
mit einem 14 Bit-Synchronisationswort, auf das zwei Overhead-Bits und der Payload
folgen. Letzterer ist in 12 Blöcke unterteilt, wobei jeder einzelne Block aus i+n×8 Bits
besteht; dabei stellt n die Anzahl der B-Kanäle dar (3 ≤ n ≤ 36) und i die Anzahl der
Z-Bits, welche für Signalisierung und Wartung notwendig sind (0 ≤ i ≤ 7). Abhängig
von der Datenrate, ergibt sich für jeden Block eine Anzahl von 24 bis 289 Bits, da
für n = 36 Werte für i > 1 nicht zugelassen sind. Die drei folgenden Gruppen haben
alle dieselbe Struktur und bestehen aus zehn Overhead-Bits und 12 Payload-Blöcken;
letztere haben dieselbe Struktur wie die der ersten Gruppe. Jeder Rahmen enthält
somit
• Synchronisationswort (14 bit)
• 32 Overhead-Bits
• 1152 bis 13872 Payload-Bits;
13
2 G.SHDSL
damit ergeben sich die bereits angeführten Bitraten von
1152 bit
= 192000 bit/s =
b 192 kbit/s
6 × 10−3 s
bzw.
13872 bit
= 2312000 bit/s =
b 2312 kbit/s
6 × 10−3 s
zuzüglich jeweils 8kbit/s.
Nach den vier Blöcken können bei plesiochroner Übertragung null oder vier Stopfbits eingefügt sein, die tatsächliche Rahmenlänge variiert also je nach Anzahl der
Stopfbits und Übertragungsrate. Bei synchroner Übertragung werden an Stelle der
Stopfbits zwei ungenutzte Bits eingefügt, um eine Rahmenlänge von 6 ms zu erreichen.
Die tatsächliche Belegung der einzelnen Bits innerhalb des Rahmens variiert je nach
Übertragungsrichtung LTU2 →NTU3 oder NTU→LTU – dies betrifft allerdings nur
das NTU local power status bit“, welches bei Übertragung in Richtung NTU unbe”
legt ist. Für eine detaillierte Liste der Rahmenbelegung sei an dieser Stelle auf [2]
verwiesen.
2.6 ATM-Transport über DSL
Bei envia.tel ist ein ATM-Backbone vorhanden, dementsprechend wird die DSL-Anbindung wie in Abschnitt 2.2 beschrieben realisiert. Dies bedeutet, dass Daten und
Sprache in ATM-Zellen in den SHDSL-Rahmen eingepackt werden müssen. Diese Funktionalität besitzt der auf ITU-T-Spezifikation I.432 basierende Sublayer ATM-TC, der
LTU NTU
Utopia Level 2
gültige Daten
Takt
Daten
OAM
TxRef (Knoten 2)
RxRef (Knoten 1
ATM-TC
PMS-TC & PMD
Abbildung 2.7: Referenzmodell im ATM-Modus (modifiziert nach [2])
2
3
Line Termination Unit
Network Termination Unit
14
2 G.SHDSL
dazu an den PMS-TC und PMD angeschlossen wird; das entsprechende Referenzmodell ist in Abbildung 2.7 zu sehen. Neben der Verbindung zwischen ATM- und SHDSLLayer sorgt der ATM-TC u. a. für Entkopplung der Schichten, Einfügen und Auslösen
von ’Idle’-Zellen und ’Header Error Control’-Bytes, (De)Scrambling des Zell-Payloads
sowie Bit-Timing und -Anordnung.
Die Verbindung zwischen ATM- und ATM-TC-Layer wird über die u. U. nur logisch
realisierte Schnittstelle Utopia Level 2 hergestellt. Diese Schnittstelle stellt das Bindeglied zwischen dem ATM-Layer und der physischen Schicht (PHY) dar. Die Daten
werden vom IAD in ATM-Zellen gepackt und über den Datenpfad Utopia Level 2 sowie ATM-TC in die SHDSL-Nutzdaten übertragen. Dies geschieht in big endian byte
order 4 , d.ḣ. das MSB einer Zelle wird zuerst in den SHDSL-Payload eingefügt. Neben den Daten können zwischen PMS-TC und ATM-TC Takt- sowie OAM-Daten5
übertragen werden, um einwandfreien Betrieb zu gewährleisten.
4
5
siehe Glossar
Operation and Maintenance
15
3 PPPoE
3.1 Vorbemerkung/Allgemeines
Die Entwicklung von PPPoE vollzog sich für die Netzbetreiber aus der Notwendigkeit heraus, mit xDSL realisierte Breitbandzugänge Authentifizierung zu ermöglichen
und eine Abrechnung erstellen zu können – dazu ist eine gezielte Erfassung einzelner Hosts innerhalb eines LANs nötig, was mit Schicht-3-Protokollen wie IP nicht
möglich ist.Aus diesem Grunde wurde das PPPoE-Protokoll entwickelt, welches sich
direkt auf das bereits vorhandene und bewährte Point-to-Point- sowie das EthernetProtokoll stützt. Neben dem Abrechnen der Verbindungen ist es möglich, dynamisch
IP-Adressen zu vergeben sowie preiswerte Ethernet-NICs in den Hosts oder bereits
existierende Ethernet-Netzwerke zu nutzen. Nachteile ergeben sich vor allem durch
die Schachtelung zweier Protokolle ineinander und dem damit entstehenden größeren
Overhead – dies ist angesichts der Übertragungsraten in einem LAN verglichen mit
xDSL allerdings eine eher philosophische Frage. Das PPPoE-Protokoll befindet sich in
Schicht 2 des OSI-Schichtmodells, das heißt im data link layer und bietet so die Basis
für Schicht-3-Protokolle wie das Internet Protocol.
3.2 Rahmenstruktur
EthernetRahmen
PPPoERahmen
Zieladresse
(6 Byte)
Ver
(4 Bit)
Quelladresse
(6 Byte)
Typ
(4 Bit)
Ether_Type
(2 Byte)
Code
(1 Byte)
Nutzdaten
*
Session_ID
(2 Byte)
Länge
(2 Byte)
Rahmenprüfsumme
Nutzdaten
*
Abbildung 3.1: Ethernet-Rahmen mit eingebetteten PPPoE-Rahmen
16
3 PPPoE
3.2.1 Ethernet- und PPPoE-Rahmen
Ein durch DSL übertragener Rahmen besteht aus einem Ethernet-Rahmen und dem
darin eingebetteten PPPoE-Rahmen. Die Struktur besteht im Einzelnen aus den in
3.1 dargestellten Feldern.
Ethernet-Rahmen
Zieladresse:
Die Zieladresse ist eine 6-Byte-Ethernetadresse. In der DiscoveryPhase kann eine Unicast- oder Broadcast-Adresse angegeben werden,
in der PPP-Session-Phase kann nur die in der Discovery-Phase ermittelte Unicast-Adresse des anderen Endgeräts angegeben werden.
Quelladresse: Die Quelladresse enthält immer die Ethernet-MAC-Adresse des Geräts, von dem die Datenübertragung initiiert wurde.
Ether_Type:
Wird in der Discovery-Phase auf 0x8863 und in der PPP-SessionPhase auf 0x8864 gesetzt. Nur diese beiden Werte sind möglich.
Nutzdaten:
Enthält PPPoE-Rahmen (siehe unten).
Prüfsumme:
Enthält Rahmenprüfsumme.
PPPoE-Rahmen
VER und TYP:
Diese Felder sind jeweils 4 Bit groß und enthalten die Versionsnummer der PPPoE-Spezifikation. Beide Felder enthalten im Falle des
RFC2516 die 0x1.
Code:
Das Code-Feld ist 8 Bit groß und enthält abhängig von den gesendeten
Paketen die in Tab. 3.1 dargestellten Werte.
Tabelle 3.1: Paket-Codes
Paket
Discovery-Phase:
PPPoE Active Discovery
Session-Phase:
immer
Code
Initiation (PADI)
0x09
Offer (PADO)
0x07
Request (PADR)
0x19
Session Confirmation (PADS) 0x65
Terminate (PADT)
0xa7
0x00
17
3 PPPoE
Session_ID:
Dieses 2-Byte-Feld enthält einen vorzeichenlosen Wert in big endian
byte order 1 außer dem reservierten Wert 0xffff. Die Session-ID wird
in der Discovery-Phase festgelegt und kennzeichnet als fixer Wert zusammen mit der Ziel- und Quelladresse die PPP-Session.
Länge:
Dieses Feld kennzeichnet mit einem zwei Byte großen Wert die Länge
der PPPoE-Nutzdaten exklusive der Header; wie bei der Session-ID
ist die Länge in big endian byte order organisiert.
3.2.2 Struktur der PPPoE-Nutzdaten in der
Discovery-Phase
Der PPPoE-Payload enthält in der Discovery-Phase null oder mehr Tags, die nach
dem in Abblidung 3.2 dargestellten TLV-Schema2 in network byte order organisiert
sind:
Tag_Type
(2 Byte)
Tag_Length
(2 Byte)
Tag_Value
*
Abbildung 3.2: Payload in Discovery-Phase
TAG_TYPE:
Dieses Feld ist 2 Byte groß, spezifiziert den Typ des Tags und darf
nur die in Tabelle 3.2 angeführten Werte enthalten.
TAG_LENGTH:
Dieses 2-Byte-Feld enthält ohne Vorzeichen die Größe des Feldes
TAG VALUE in Byte.
TAG_VALUE:
In diesem Feld ist der Wert des Tags entsprechend des TAG TYPE
angegeben.
3.2.3 Struktur der PPPoE-Nutzdaten in der
Session-Phase
Die in der PPP-Session auftretende Rahmenstruktur des PPPoE-Payloads sowie der
Inhalt der Felder ist entsprechend Abb. 3.3 festgelegt.
1
Die Bezeichnungen big endian bzw. network byte order und little endian byte order zeigen an, wie
die Bytes eines Datenwortes gespeichert werden. In big endian byte order erhält das höchstwertige
Byte die niedrigste Adresse und wird damit zuerst übertragen. Bei little endian gilt genau das
Gegenteil, d. h. das niedrigstwertige Byte wird zuerst gespeichert und übertragen. Da die Übertragung in Datennetzen in big endian stattfindet, müssen Rechner mit little endian-Prozessoren
wie z. B. Intel oder VAX die Daten vor dem Übertragen zuerst konvertieren.
2
TLV = type-length-value
18
3 PPPoE
Tabelle 3.2: TAG TYPES
TAG TYPE
0x0000
0x0101
0x0102
0x0103
0x0104
0x0105
0x0110
0x0201
0x0202
0x0203
Protocol
(1/2 Byte)
Name
End-Of-List
Service-Name
AC-Name
Host-Uniq
AC-Cookie
Vendor-Specific
Relay-Session-Id
Service-Name-Error
AC-System-Error
Generic-Error
Information
*
Padding
*
Abbildung 3.3: Payload in PPP-Session
Protocol:
Dieses Feld mit einer Größe von einem oder zwei Byte enthält einen
Protokollcode, der das Datagramm3 im Informationsfeld eindeutig
charakterisiert. Die Übertragung geschieht in network byte order.
Die im Protocol-Feld enthaltenen Protokollcodes sind entsprechend
des Erweiterungsmechanismus für Adressfelder der ISO 3309 vereinbart. Dabei dient das LSB eines Bytes zur Kennzeichnung, ob ein
weiteres Protokollbyte folgt – ist es gesetzt, folgt kein weiteres Protokollbyte und umgekehrt. Dies ermöglicht optimale Erweiterbarkeit im
Hinblick auf zukünftige, über PPP transportierbare Übertragungsprotokolle, da der Adressraum für neue Protokollcodes kaum begrenzt ist.
Beim PPP werden im Allgemeinen zwei Byte für den Protokollcode
verwendet, deswegen ist das LSB des höchstwertigen Bytes zur Kennzeichnung, dass ein weiteres Byte folgt, immer ‘0’ und die Codes sind
insgesamt immer ungerade, da das LSB des niedrigstwertigen Bytes
immer ‘1’ ist.
Die möglichen Adressbereiche sind für bestimmte Protokollfamilien
reserviert und in Tab. 3.3 dargestellt.
Die konkreten Codes für einzelne Protokolle sind ebenso wie die Protokollgruppen unter [1] zu finden. Die wichtigsten Protokollwerte für
eine IP-Verbindung sind 0x0021 (Internet Protocol), 0x8021 (Internet
Control Protocol) sowie 0xc021 (Link Control Protocol).
3
Übertragungseinheit in der Netzschicht (network layer ), die in ein oder mehr Pakete für die Sicherungsschicht gekapselt sein kann.
19
3 PPPoE
Tabelle 3.3: Protokollcode-Gruppen
Adressbereich
0x0***–0x3***
0x4***–0x7***
0x8***–0xb***
0xc***–0xf***
Protokollgruppe
Schicht-3-Protokolls mit zugehörigem NCP
Schicht-3-Protokoll ohne zugehörigem NCP
Network Control Protocols (NCP) des PPP
Link Layer Protocol (LCP)
Information:
Dieses Feld besteht aus null oder mehr Bytes und enthält das Datagramm, welches im Protokollfeld spezifiziert wurde. Die Länge dieses
Feldes inklusive Padding wird durch die MRU4 festgelegt und beträgt
bei PPPoE maximal 1492 Byte. Diese Zahl resultiert aus der maximalen Ethernet-MRU von 1500 Byte abzüglich sechs Byte für den
PPPoE- und zwei Byte für den PPP-Header.
Padding:
Für die Übertragung kann das Informationsfeld durch Padding-Bits
bis zur MRU aufgefüllt“ werden. Die Trennung zwischen Informa”
tions- und Füllbits obliegt der PPP-Implementation.
3.3 Ablauf des Verbindungsaufbaus mit
PPPoE
3.3.1 Überblick
PPPoE besitzt zwei getrennte Phasen, eine Discovery- und eine Session-Phase. Um eine
Verbindung aufzubauen, muss zuerst die Discovery-Phase durchlaufen werden, um die
Ethernet-MAC-Adresse des Access Concentrator (AC) zu erhalten und eine Session
ID zu etablieren. Da prinzipiell mehrere ACs vorhanden sein können, mit denen der
Host eine Verbindung aufbauen könnte, müssen in dieser Phase alle ACs gefunden und
vom Host einer ausgewählt werden.
Mit diesem AC wird im Anschluss die PPP-Session aufgebaut. Dazu müssen LCPPakete zur Konfiguration und Test der Verbindung zwischen den DEE ausgetauscht
werden, anschließend kann eine Authentifizierung mit einem Authentication Protocol
erfolgen. Die Spanne reicht dabei von einfachen Passwortverfahren im Klartext bis
zu stark verschlüsselter Authentifizierung mit Smart-Card. Mit NCP-Paketen werden
dann im Anschluss ein oder mehrere Schicht-3-Protokolle ausgewählt und konfiguriert, über die im Anschluss an die Konfiguration die Datenübertragung stattfinden
soll.
4
Maximum Receive Unit
20
3 PPPoE
Die Verbindung bleibt bestehen, bis entweder ein PADT-, LCP- oder NCP-Paket die
Verbindung explizit schließt oder ein externes Ereignis zum Abbruch der Verbindung
führt.
3.3.2 Discovery-Phase
Der Kommunikationsablauf in der Discovery-Phase findet in fünf Teilschritten statt.
Um den Verbindungsaufbau einzuleiten, sendet der Host ein Initiation-Paket an die
Broadcast-Adresse und damit das gesamte erreichbare Netz, in dem er einen bestimmten Dienst anfordert. Ein oder mehrere Access Concentrator, die genau diesen Dienst
anbieten, können daraufhin mit einem an den Host adressierten Offer-Paket ihre Dienste anbieten. Der Host kann anschließend mit einem Request von einem AC den angebotenen Dienst anfordern, welchen der AC mit einem Session-confirmation bestätigt.
Auf diese ‘Entdeckungsphase’ folgt die PPP-Session, in der Authentifizierung und Datenübertragung stattfindet. Anschließend kann von einem der Endgeräte mit einem
Terminate-Paket die Verbindung abgebrochen werden. Der komplette Ablauf ist in
schematischer Form in Abb. 3.4 dargestellt. Bei allen Teilschritten ist ETHER_TYPE im
Ethernet-Rahmen auf 0x8863 gesetzt.
PPPoE Active Discovery Initiation (PADI)
Das PADI-Paket dient dem Auffinden aller AC, die einen bestimmten Dienst anbieten, daher wird im Ethernet-Rahmen als DESTINATION_ADDR die Broadcast-Ethernetadresse gesetzt. In TAG_TYPE kann nur ein Dienst entsprechend Tabelle 3.2 explizit angefordert werden. Die in Abb. 3.5 angegebene Kombination aus Tag_TYPE = 0x0101
(Service-Name) und TAG_LENGTH = 0x0 bedeutet, dass vom Host jeder Dienst akzeptiert wird. Weitere Tags können optional angegeben werden. Das CODE-Feld zeigt
den Pakettyp an und wird entsprechend Tab. 3.1 auf 0x09, das SESSION_ID-Feld auf
0x0000 gesetzt. Nach dem Senden dieses Pakets wartet der Host einen bestimmten
Zeitraum auf PADO-Pakete, d.h. Antworten von möglichen ACs. Sollte innerhalb dieses Zeitraums keine Antwort eingegangen sein, so empfiehlt das RFC 2516[4], dass
der Host das PADI-Paket erneut sendet, die Wartezeit auf PADO-Pakete allerdings
AC
Host
PPPoE Active Discovery Initiation
PPPoE Active Discovery Offer
PPPoE Active Discovery Request
PPPoE Active Discovery Session Confirmation
...
PPPoE Active Discovery Terminate
Abbildung 3.4: Ablauf der Discovery-Phase
21
3 PPPoE
[bit]
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
4
0xffffffff
0xffff
Host_mac_addr
8
12
Host_mac_addr (cont)
[byte]
ETHER_TYPE = 0x8863
v=1
t=1
CODE = 0x09
16
SESSION_ID = 0x0000
LENGTH = 0x0004
20
TAG_TYPE = 0x0101
TAG_LENGTH = 0x0000
24
Abbildung 3.5: PADI-Paket
verdoppelt wird. Als maximale Gesamtgröße wird vom RFC2516 1484 Bytes inklusive PPPoE-Header angegeben, um einem Relay-Agent die Möglichkeit zu geben, eine
Relay_Session_ID hinzuzufügen.
PPPoE Active Discovery Offer (PADO)
Wenn ein AC ein PADI-Paket erhält und den geforderten Service anbietet, sendet
er an den Host ein PADO-Paket zurück. Als Zieladresse für das PADO-Paket ergibt
sich automatisch die MAC-Adresse des Hosts, das CODE-Feld wird auf 0x07 und die
Session_ID auf 0x0000 gesetzt. Letztere ist noch nicht vereinbart und wird deswegen
auf Null gesetzt. Im PPPoE-Payload müssen vom AC mindestens der Name des ACs
(AC_NAME) und dieselbe Bezeichnung des im PADI geforderten Dienstes enthalten sein,
sowie optional weitere Tags.
PPPoE Active Discovery Request (PADR)
Nachdem der Host die vorgegebene Zeit auf PADO-Pakete gewartet hat, kann er aus
allen erhaltenen PADO-Paketen durch die angebotenen Dienste und Namen der ACs
einen AC auswählen und diesem mit einer PADR-Nachricht seine Wahl mitteilen. In
der Nachricht muss deshalb als Zieladresse die Unicast-MAC-Adresse des ACs gesetzt
und wiederum der entsprechende geforderte Dienst enthalten sein. Der Paket-Code
für das PADR-Paket ist 0x19 und als Session_ID muss 0x0000 eingetragen werden.
22
3 PPPoE
[bit]
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Host_mac_addr
4
Access_Concentrator_mac_addr
Access_Concentrator_mac_addr (cont)
ETHER_TYPE = 0x8863
v=1
t=1
8
12
CODE = 0x07
16
SESSION_ID = 0x0000
LENGTH = 0x0020
20
TAG_TYPE = 0x0101
TAG_LENGTH = 0x0000
24
TAG_TYPE = 0x0102
TAG_LENGTH = 0x000f
28
0x46
0x6c
0x79
0x20
32
0x74
0x6f
0x20
0x74
36
0x68
0x65
0x20
0x4d
40
0x6f
0x6f
0x6e
[byte]
44
Abbildung 3.6: PADO-Paket
[bit]
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
AC_mac_addr (cont)
4
Host_mac_addr
ETHER_TYPE = 0x8863
v=1
8
12
t=1
CODE = 0x19
[byte]
16
SESSION_ID = 0x0000
LENGTH = 0x0020
20
TAG_TYPE = 0x0101
TAG_LENGTH = 0x0000
24
Abbildung 3.7: PADR-Paket
23
3 PPPoE
[bit]
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Host_mac_addr
4
8
12
Access_Concentrator_mac_addr (cont)
[byte]
ETHER_TYPE = 0x8863
v=1
t=1
CODE = 0x65
16
SESSION_ID = 0x5a7f
LENGTH = 0x0020
20
TAG_TYPE = 0x0101
TAG_LENGTH = 0x0000
24
Abbildung 3.8: PADS-Paket
PPPoE Active Discovery Session Confirmation (PADS)
Nach dem Erhalt eines PADR-Pakets wird vom AC eine PPP-Session vorbereitet,
dazu wird von ihm eine einzigartige Session_ID generiert. Die Zieladresse das PADSPakets ist die des Hosts, als CODE wird 0x65 und als Session_ID die bereits generierte
ID eingesetzt. Der geforderte Dienst muss wie in den vorangegangenen Nachrichten
als TAG_NAME enthalten sein; weitere TAGs sind optional.
PPPoE Active Discovery Terminate (PADT)
Diese Nachricht dient zum Abbau der Verbindung zwischen AC und Host und
kann von beiden Seiten geschickt werden. Dazu muss die entsprechende Unicast-Zielund Quelladresse, die Session_ID der zu schließenden Verbindung sowie im CODEFeld 0xa7 angegeben werden; Tags sind nicht nötig. Nach dem Abbau der Session
[bit]
1
2
3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Dest_mac_addr
Dest_mac_addr (cont)
4
Source_mac_addr
Source_mac_addr (cont)
ETHER_TYPE = 0x8863
v=1
SESSION_ID = 0x5a7f
12
t=1
CODE = 0xa7
LENGTH = 0x0020
Abbildung 3.9: PADT-Paket
24
8
16
20
[byte]
3 PPPoE
darf von beiden Seiten keinerlei PPP-Traffic mehr gesendet werden. Vorrangig sollten Verbindungen allerdings über entsprechende PPP-Mechanismen geschlossen werden.
3.3.3 PPP-Phase
Die PPP-Session durchläuft fünf getrennten Phasen zwischen Aufbau und Terminierung der Verbindung – Abbildung 3.10 zeigt ein vereinfachtes Phasendiagramm dieser
einzelnen Abschnitte. Mit LCP-Nachrichten wird der Ablauf der PPP-Verbindung über
die fünf Phasen gesteuert.
Phase 1: Link Dead Zu Beginn jeder Verbindung befindet sich die PPP-Verbindung
in Phase 1 ‘Link Dead’. Diesen Status erhält die PPP-Verbindung, solange die pysikalische Schicht nicht bereit ist – da bei PPPoE die PPP-Verbindung erst nach
Durchlaufen der Discovery-Phase initiiert und damit die physikalische Schicht
bereits genutzt wird, kann direkt zur nächsten Phase ‘Establish’ übergegangen
werden. Sollte die Verbindung auf PPP-Ebene beendet werden, wird die LinkDead-Phase dennoch durchlaufen, da jede PPP-Verbindung zwangsläufig mit dieser Phase beginnt und endet – die Verweildauer in dieser Phase ist bei PPPoE
aber in jedem Falle extrem kurz.
Phase 2: Link Establishment Die zweite Phase dient dem ‘Link Establishment’,
dem eigentlichen Verbindungsaufbau. Über das Link Control Protocol (LCP)
werden Nachrichten ausgetauscht, mit denen die Verbindung konfiguriert wird.
Es werden mit dem LCP nur die Optionen konfiguriert, die von übergeordneten
Netzwerkprotokollen unabhängig sind – die Konfiguration der einzelnen Netzwerkprotokolle findet mittels des Network Control Protocol (NCP) in der Netzwerkphase statt. Das Link Establishment ist beendet, wenn von beiden Seiten
Config-Ack gesendet wird. Durch Senden des LCP-Pakets Configure-Request
in den Phasen Authenticate oder Network findet ein Rückfall in diese Phase
statt.
Phase 3: Authentication Die Durchführung einer Authentifizierung in dieser Phase setzt voraus, dass diese Option beim Verbindungsaufbau in Phase 2 angefordert wurde, da sie bei PPP nicht zwingend vorgeschrieben ist. Sollte die Authentifizierung scheitern, wird direkt mit Link Termination fortgefahren. In der
Authentifizierungsphase kann noch vor der eigentlichen Authentifizierung die
Verbindungsqualität mit Paketen des Quality Protocol festgestellt werden.
Phase 4: Network-Layer Protocol In dieser Phase werden die einzelnen Netzwerkprotokolle wie z. B. IP mit dem zugehörigen NCP konfiguriert. Sobald ein NCP
nach der Konfiguration den ‘Opened’-Zustand erreicht hat, werden die Netzwerkprotokoll-Pakete über die PPP-Verbindung transparent übermittelt, zusammen
mit eventuell auftretenden NCP- oder LCP-Paketen.
25
3 PPPoE
Abbildung 3.10: PPP-Phasendiagramm (modifiziert nach [10])
Phase 5: Link Termination Die in Phase 4 geöffnete Verbindung kann aufgrund
verschiedener Gründe5 durch Terminate-Pakete des Link Control Protocol jederzeit geschlossen werden und die PPP-Verbindung damit in Phase 5 überführt werden. Das PPP gibt die Meldung über das Schließen der Verbindung an
das übergeordnete Netzwerkprotokoll weiter, anschließend wird die physikalische
Verbindung getrennt. Letzteres ist bei Implementation eines PPPoE-Treibers
nicht zwingend erforderlich, dennoch ist dieses Verhalten z. B. nach einem Authentifizierungsfehler möglich. Nach der Link Termination Phase wird die PPPVerbindung wieder in Phase 1 überführt.
Weitere Informationen der beim verbreiteten Point-to-Point-Protocol zum Einsatz
kommenden Protokollen wie LCP, NCP und Authentifizierungsprotokoll sowie deren
Optionen, können dem RFC 1661 [10] entnommen werden.
5
z. B. Verlust des Trägersignals oder nicht abgeschlossene Authentifizierung
26
4 WindowsNetzwerkarchitektur
Dieser Abschnitt dient der Einordnung der PPPoE-Clients in die Netzwerkarchitektur von Windows. Die Architektur wird hier lediglich in Grundzügen skizziert. Es
wird dabei nur auf Windows NT eingegangen, da Windows 2000 und XP las unmittelbare Nachfolger auf dessen Netzwerkarchitektur aufbauen. Unter den DOS-basierten
Systemen stellen Windows 98 und ME im Grunde ähnliche Architekturen bereit,
lediglich Windows 95 lässt auf Grund seines Alters einige neue Merkmale vermissen.
Der Grund für die Erweiterung der Netzwerkarchitektur liegt in der wachsenden Bedeutung bestimmter Betriebssystem-Merkmale wie z. B.
• Mehrbenutzerfähigkeit
• preemptives Multitasking
• Netzwerkfähigkeit,
die schlussendlich eine komplette Neuentwicklung der Architektur von Windows NT
erforderten, da nur so Microsoft diesen Anforderungen an moderne Betriebssysteme
RPC
7 -- Anwendungsschicht
6 -- Darstellungsschicht
NetBIOS-Treiber
Provider
Redirektoren
Pipes
Server
Winsock
User Mode
Kernel Mode
5 -- Sitzungsschicht
Transport Driver Interface (TDI)
4 -- Transportschicht
TCP/IP
3 -- Netzschicht
IPX/SPX
Transport-Protokolle
NetBEUI
2 -- Sicherungsschicht
andere
LLC
NDIS-Schnittstelle
MAC
Netzwerkkartentreiber
1-- physikalische Schicht
Netzwerkkarten
Abbildung 4.1: Netzwerkarchitektur von Windows NT (modifiziert nach [5])
27
gerecht werden konnte. Die Netzwerkfähigkeit ist dementsprechend in das Betriebssystem eingebaut und läuft komplett im Kernel-Modus – Applikationen können im
User-Modus über entsprechende Application Programming Interfaces (API) auf die
tieferliegenden Schichten zugreifen.
Abbildung 4.1 zeigt, wie die Netzwerkarchitektur im OSI-Modell implementiert ist.
Einzelne der dargestellten Schichten wie z. B. die physikalische Schicht entsprechen
dabei genau denen des OSI-Modells, die Grenzen zwischen den definierten Schichten des theoretischen Modells sind in der praktischen Umsetzung dennoch eher fließend.
Alle Teile im application layer repräsentieren die bereits erwähnten User-Mode-Applikationen.
Die im Zusammenhang mit der Treiberprogrammierung wichtigen zwei Schnittstellen
innerhalb der Netzwerkarchitektur stellen das Transport Driver Interface (TDI) sowie
die Network Driver Interface Specification (NDIS) dar. Diese sogenannten boundary
layers schließen die Protokolle der Transport-Schicht ein und ermöglichen damit eine
weitgehende Unabhängigkeit der Netzwerk-/Transport-Protokolle von den Netzwerkgeräten sowie den aufsetzenden Applikationen. Dies ist vor allem für von Microsoft
unabhängige Entwickler notwendig, da über diese dokumentierten APIs eine Erweiterung der Netzwerkfähigkeiten des Betriebssystems möglich ist – beispielhaft sei die
Erweiterung um das PPPoE-Protokoll genannt. Die tatsächlichen Verbindungen zwischen Netzwerkprotokollen, physikalischen Geräten und Applikationen werden über
Bindungen“ (siehe Abbildung 4.2) realisiert und damit die Kommunikation über die
”
Schnittstellen hinweg gesteuert.
TDI
Das Transport Driver Interface definiert eine Netzwerkschnittstelle im kernel mode,
die direkt auf den Stack der Transportprotokolle aufsetzt. Daten, Events sowie Adressen werden über diese Schnittstelle in einem standardisierten und erweiterbaren Format ausgetauscht und ermöglichen den TDI-Netzwerkclients, mit einem Minimum an
Applikation
TDI
IPX/SPX
TCP/IP
NIC #1
NIC #2
NDIS
Abbildung 4.2: Netzwerkprotokoll-Bindung
28
transportspezifischen Code auszukommen. Aus Gründen der Abwärtskompatibilität
existieren ab Windows 2000 zwei Emulationsmodi für Clients, die auf die Socketsoder NetBIOS-Schnittstelle angewiesen sind. Diese Emulation wird über jeweils ein
Modul realisiert, welches auf TDI aufsetzt und unter Performance-Verlust native
Funktionsaufrufe sowie Parameter umsetzt und die entsprechende TDI-Funktion aufruft.
NDIS
Die NDIS, welche in Grundzügen von Microsoft und 3Com 1988 entwickelt wurde, stellt
eine standardisierte Kommunikation zwischen dem MAC-Sublayer1 und höherliegenden Protokolltreibern bereit und ermöglicht damit von Gerätetreibern unabhängige
Protokolltreiber.
Transport Driver
Interface (TDI)
LAN-Protokolle
LAN-Medientyp
NDIS-Schnittstelle
Dies wird über den sogenannten NDIS Wrapper realisiert, der alle nach NDIS spezifizierten Geräte- bzw.
Netzwerkkartentreiber. Er stellt damit eine Schnittstelle zwischen diesen Teilen der Netzwerkarchitektur
dar – die Protokolltreiber kommunizieren demzufolge
nicht mehr mit den Gerätetreibern direkt, sondern
mit dem NDIS Wrapper, über den lediglich Bindungen zwischen den Komponenten festgelegt werden.
Der Vorteil der Network Driver Interface Specification liegt in der möglichen Modularität, da durch
dessen Nutzung physikalische Geräte oder Protokolle unabhängig und ohne Änderung der Parameter der
verbleibenden Komponente ausgetauscht werden können.
NDIS Intermediate
nativer Medientyp
NDIS-Miniport
Netzwerkkarte
Es werden drei verschiedene Typen von Treibern in
Abbildung 4.3: Intermediate
der NDIS-Hierarchie unterschieden: Die oben bereits
Driver
erwähnten Protokolltreiber befinden sich am oberen
Ende der Hierarchie und stellen die unterste Schicht
für die auf die NDI-Schnittstelle aufsetzenden Transporttreiber dar – Beispiele für
solche Protokolle wären TCP/IP oder IPX.
An unterster Stelle befinden sich die Netzwerkkarten- bzw. Miniport-Treiber, welche
direkt mit den physikalischen Netzwerkgeräten kommunizieren können – mit diesen
Treibern wird der Versand/Empfang von Daten über die NIC realisiert. MiniportTreiber stellen dem NDIS Einstiegspunkte“ bereit, über die der Zugriff auf den Mi”
niport stattfinden kann, nutzen aber ihrerseits Funktionen der NDIS zum Zugriff auf
Betriebssystemfunktionen. NDIS unterstützt Miniport-Treiber sowohl für verbindungsorientierte (ATM, ISDN) als auch verbindungslose (Ethernet, Token Ring) Protokolle.
1
Im MAC-Sublayer befinden sich die Treiber für die Netzwerkgeräte (siehe Abb. 4.1)
29
Zwischen Protokoll- und Netzwerkkartentreibern befindet sich eine dritte Gruppe, die
Intermediate Drivers. Diese kommunizieren mit den höherliegenden Protokoll- und
den tieferliegenden Miniport-Treibern und agieren zum Beispiel als Paketfilter oder
Load Balancing Driver. Abbildung 4.3 zeigt die NDIS-Hierarchie, die Stellung des
Intermediate Drivers sowie die Anbindung an das TDI.
PPPoE-Treiber können an unterschiedlicher Stelle in der Netzwerkarchitektur angesiedelt sein, die Einordnung wird bei Vorstellung der einzelnen Clients in Abschnitt 9
vorgenommen.
30
Teil III
Durchführung
31
5 Testaufbau
Die im Abschnitt 2.2 angeführten zwei Möglichkeiten der Netzrealisierung eines Backbones gilt es zusammen mit der entsprechenden PPPoE-Software zu testen. Dazu sind
zwei Rechner nötig, einer direkt am Backbone und einer an der DSL-Strecke angeschlossen. Diese können direkt kommunizieren und erlauben damit einen aussagefähigen Test der DSL-Leitungen, da die zwischenliegenden Leitungsabschnitte kurz sind
und kein öffentlicher Zugriff auf einen der beiden Rechner stattfindet. Die DSL-Strecke
sollte unbelastet sein, um eine Verfälschung der Messergebnisse bei der Erfassung der
Netto-Datenrate zu vermeiden.
Um die Ergebnisse auf die typische Kundenkonfiguration übertragen zu können, muss
die PC-Konfiguration so gewählt werden, dass sie in etwa der erwarteten Rechnerkonfiguration der Zielgruppe entspricht. Die Zielgruppe bilden vor allem mittelständische,
nicht vorrangig aus der IT-Branche stammende Unternehmen – dies impliziert eine
konservative Rechneraufrüstung im Rahmen der Abschreibungsfrist. Es ist also mit
Rechnerkonfigurationen im Alter von mehreren Jahren zu rechnen. Die Nutzung eines
eher älteren PCs bietet bei der Erfassung der CPU-Belastung jedes Clients bei der
Übertragung den Vorteil, sinnvolle Werte zu erhalten.
Aus den vorhergehenden Betrachtungen ergibt sich somit, dass neben der bereits beim
Netzbetreiber vorherrschenden Netzinfrastruktur, die DSLAM, Router, Switches etc.
einschließt, lediglich zwei PC sowie ein IAD notwendig sind. Es werden folgende Hardware konkret benutzt:
Client-PC – HP Vectra VEi8
– CPU: Intel PIII 650MHz
– Netzwerkkarte: 3Com 3C905C-TX
– RAM: 128 MB
– Festplatte: IBM-DJNA-370910
– Systemkonfiguration: siehe Anhang
Server-PC – Toshiba Satellite Pro490CDT
– CPU: Intel Pentium II 266 MHz
32
5 Testaufbau
– Netzwerkkarte: 16-bit Ethernet 10/100
– RAM: 64 MB
– Systemkonfiguration: siehe Anhang
IAD
– Siemens Attane i210
– Umsetzung von Sprache mit AAL1 und Daten mit AAL5; Umsetzen
auf SHDSL
– Bereitstellung 4×S0 und 1×10BaseT
– Nutzung der vollen SHDSL-Bandbreite für Datenübertragung, jegliche
Sprachkanäle sind deaktiviert
Der Testaufbau ist in Abbildung 5.1 dargestellt, die dargestellten Protokollverbindungen stellen lediglich die logischen Verbindungen dar. Er bietet die Möglichkeit, die maximale Datenrate im Verhältnis der Rechnerbelastung zu messen und damit dem Netzbetreiber die Möglichkeit zu geben, sowohl die Konfiguration der einzelnen beteiligten
Geräte anzupassen als auch Empfehlungen an die Zielgruppe hinsichtlich Betriebssystem oder Hardwarekonfiguration zu geben. Die Bezeichnung der Rechner mit ’Client’
Server
AC
Ethernet
Switch
ATM
DSLAM
ATM
IAD
G.SHDSL
ATM
1) physikalische Verbindung
Client
Ethernet
PPPoE
1)
2)
2) logische Verbindung
Abbildung 5.1: Testaufbau
und ’Server’ wird beibehalten, um den Standort der Rechner eindeutig identifizieren zu
können. Soll die Datenrichtung angegeben werden, wird auf die Begriffe upstream und
downstream zurückgegriffen. Upstream bezeichnet den Datenfluss in Richtung Server,
also zum Backbone; downstream bezeichnet die umgekehrte Richtung. Beide Begriffe
haben sich bei Dial-Up- bzw. DSL-Verbindungen im Home-Bereich etabliert, deswegen
wird die Bezeichnugnsweise hier übernommen.
33
6 Testablauf
6.1 Software
Bei einer Zusammenstellung eines Softwarepakets für einen DSL-Zugang gehört dem
PPPoE-Client als Zugangssoftware das Hauptaugenmerk. Aus dem am Markt befindlichen Angebot muss eine Auswahl getroffen werden, die in ökonomischer und technischer Hinsicht den Bedürfnissen von envia.tel und deren potentiellen Kunden am
nächsten kommt.
Vor dem Test wurde seitens envia.tel zuerst eine Vorauswahl getroffen, in welche nur
diejenigen PPPoE-Clients einbezogen wurden, die lediglich reine Zugangsfunktionalität
bieten. Die Ursache für diese Entscheidung ist, dass erweiterte PPPoE-Clients mit z. B.
Routerfunktionalität mehr kosten, der zusätzliche Funktionsumfang für envia.tel aber
ohne Belang ist. Letzteres hat seinen Grund darin, dass PPPoE nur in Ausnahmefällen und für einzelne Hosts eingesetzt werden soll und bei LANs ausschließlich PPPoA
zum Einsatz kommt. Desweiteren werden herstellerspezifische Lösungen für bestimmte Endgeräte aus nachvollziehbaren Gründen ausgeklammert. Die Vorauswahl bilden
folgende Kandidaten:
• RASPPPOE 0.98
• WinPoET v2.51
• cFOS v4.12
• POETRI 1.9.11 deutsch
• Enternet 300 v1.5c SP2
Diese Clients werden hinsichtlich verschiedener Kriterien getestet, um dem Netzbetreiber die Möglichkeit zu bieten, den besten Kompromiss aus Preis und Leistung zu finden. Alle Testergebnisse sind in einem Spreadsheet (MS Excel) zusammengetragen und
bilden das Grundgerüst für die Bewertung (siehe Abschnitt 7).
Die Betriebssysteme, auf denen die PPPoE-Clients getestet werden, müssen dem Kundenkreis angepasst sein. Dies ist der Grund für den Einsatz verschiedener WindowsVersionen, die auf entsprechend alter Hardware eingesetzt werden. Es werden folgende
Windows-Versionen zum Test benutzt:
34
6 Testablauf
• Windows 95
• Windows 98 Second Edition
• Windows NT 4.0 SP6
• Windows 2000
Neben dem Test der obengenannten Clients auf den Windows-Betriebssystemen findet
ein Test zwei weiterer Clients statt. Der Windows-XP-Client sowie Roaring Penguin
auf SuSE-Linux 7.1 werden getestet, um die Leistungsfähigkeit vergleichen zu können.
Die Tests finden außer Konkurrenz statt, da zum einen der Kundenkreis, der Linux
einsetzt, für envia.tel nicht relevant ist und zum anderen die Leistungsfähigkeit eines
in das Betriebssystem eingebauten Clients von Interesse ist, insbesondere im Hinblick
auf die Installation.
Als Testprogramme dienen NetIO 1.14 und CPUCool 7.1.1 sowie top. Ersteres setzt direkt auf den TCP/IP-Stack auf und überträgt in Intervallen von jeweils zehn Sekunden
Daten mit steigender Blockgrösse und ermöglicht so die Bewertung der Effizienz der Datenübertragung der einzelnen Clients. Ein kompletter Testzyklus dauert 60 Sekunden,
innerhalb derer Blockgrößen von 1, 2, 4, 8, 16 und 32 Kilobytes bei der Übertragung
genutzt werden. Das Programm benutzt dabei eine Client-Server-Kommunikation –
dabei werden die Daten vom Client an den Server übertragen, welcher die Zeit protokolliert, diese dem Client sendet und dieser damit die Datenrate berechnen und
ausgeben kann. Ausgegeben wird jeweils das arithmetische Mittel der Datenrate eines
Testblocks (zehn Sekunden).
6.2 Testablauf
Jedes Betriebssystem wird nacheinander auf dem Client-Rechner installiert und konfiguriert. Dabei werden aktuelle Netzwerk- und Grafikkartentreiber installiert und Änderungen der TCP-Konfiguration vorgenommen. Dies betrifft das TCP-Empfangsfenster,
welches über Registry-Einstellungen auf 32K geändert werden muss; die zu ändernden
Registry-Schlüssel sind folgende:
Windows 9x:
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\. . .
. . .Services\VxD\MSTCP]
→ DefaultRcvWindow=32767
Windows NT:
[HKEY_LOCAL_MACHINE\SYSTEM \CurrentControlSet\. . .
. . .Services\Tcpip\Parameters]
→ TcpWindowSize=dword:00007fff
Windows 2000:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\. . .
. . .Services\Tcpip\Parameters]
→ GlobalMaxTcpWindowSize=dword:00007fff
35
6 Testablauf
Daten (Upstream)
Upstream
Client (HP Vectra)
Server (Toshiba Satellite)
netio -t <IP-Adresse Server>
netio -t -s
<IP-Adresse Client>
<IP-Adresse Server>
Daten (Downstream)
Downstream
Client (HP Vectra)
Server (Toshiba Satellite)
netio -t -s
netio -t <IP-Adresse Client>
<IP-Adresse Client>
<IP-Adresse Server>
Abbildung 6.1: Datenfluss und Befehle Upstream (oben) und Downstream (unten)
Die Erhöhung der TCP Window Size auf 32 Kilobyte verhindert eine Begrenzung der
Übertragungsgeschwindigkeit, die bei zu kleinem Fenster entstehen würde1 . Der Grund
liegt darin, dass jedes TCP-Paket vom Empfänger bestätigt werden muss und diese
Bestätigung eine gewisse Laufzeit bis zum Sender besitzt. Ist das vor der Übertragung
zwischen Sender und Empfänger vereinbarte Empfangsfenster zu klein, entstehen Pausen, in denen der Sender auf die Empfangsbestätigung warten muss und erst mit Erhalt
derselben weitersendet. Dieses Problem tritt besonders bei Breitband-Verbindungen
wie z. B. DSL statt, da über Wide Area Networks aufgrund der Routerbelastung sowie
des nötigen Protokolloverheads längere Paketlaufzeiten nicht zu vermeiden sind. Eine
Änderung ist bei Windows notwendig, da die vorgegebenen Empfangsfenster von 8
bzw. 16 Kilobyte zu klein sind.
Versuche mit kleineren Empfangsfenstern brachten erkennbar niedrigere Datenraten,
die Erhöhung auf Werte über 32 Kilobyte führte dagegen zu keiner weiteren Erhöhung
der Datenrate.
Der Testablauf wird jeweils über Batchdateien so gesteuert, dass pro PPPoE-Client
fünf komplette Testzyklen bei Datenfluss vom Server zum Client (downstream) als
auch vom Client zum Server (upstream) durchgeführt werden. Dies hat den Vorteil,
kurzfristige Leistungsschwankungen ausgleichen zu können. Der Datenfluss sowie die
Parameter für NetIO sind in 6.1 dargestellt.
Die CPU-Belastung während der Übertragung auf Windows-Betriebssystemen wird
mit CPUCool protokolliert. CPUCool läuft mit niedrigster Priorität, um die Übertragung sowenig wie möglich zu beeinflussen. Das Programm misst die komplette
CPU-Belastung, was ebenfalls periphere Belastungen wie z. B. Festplattenzugriffe einschließt, welche die CPU ebenfalls belasten. Unter Linux wird top zur Messung der
CPU-Belastung benutzt, dabei wird allerdings nur die Belastung gemessen, die der
PPPoE-Client hervorruft.
1
Weitere, häufig propagierte Änderungen wie z. B. der Time To Live (TTL) haben keinen Einfluss
auf die Datenrate [11]
36
7 Testprotokoll
Die erfassten Daten werden grundsätzlich in fünf verschiedene Kategorien eingeteilt:
Allgemeine Angaben, Installation/Deinstallation, Verbindungseinrichtung, regulärer
Betrieb und Performance. Diesen Kategorien werden entsprechende Kriterien untergeordnet, die im folgenden beschrieben sind, falls die Bezeichnung nicht selbsterklärend
ist.
Allgemeine Angaben
In diesem Abschnitt werden alle grundlegenden Angaben erfasst:
Version:
– Programmrevision
Hersteller:
– Name des Herstellers
Bezugsquelle:
– Bezugsquelle im WWW (URL)
unterstützte Betriebssysteme:
– alle von der angegebenen Programmrevision
unterstützten Betriebssysteme
Preis pro Lizenz:
– Erfassung des Preises für Einzel- und Mehrfachlizenzen
Zusatzfunktionen, -optionen:
– weitere, über die notwendigen Features hinaus gehenden Funktionen
AC-Serverdienst: Client kann als Access Concentrator benutzt werden
Firewall: Client bietet Firewallfunkionalität,
d. h. ermöglicht die Sperrung unerwünschten
Datenverkehrs
Routing/IP-Masquerading: zeigt, ob Routing
mit IP-Masquerading möglich ist, d. h. ob der
Rechner mit installiertem Client routen kann
und damit mehrere Rechner den gleichen Zugang nutzen können
Dokumentation / Sprache:
– Erfassung, ob Dokumentation vorhanden ist
und deren Sprache
37
7 Testprotokoll
Installation, Deinstallation
Dieser Abschnitt des Testprotokolls enthält Angaben zur Installations- und Deinstallationsprozedur. Dies schliesst nur die Installation der Software an sich ein – sofern eine
spezifische Verbindungseinrichtung während der Installation statt findet, wird diese
ebenfalls berücksichtigt. Verbindungseinrichtung meint in diesem Zusammenhang die
Einrichtung eines Accounts“ mit Name und Passwort, der für den DSL-Zugang eines
”
Providers notwendig ist. Da die Software prinzipiell nicht auf einen Provider beschränkt
ist, sind mehrere Verbindungen oder Accounts möglich.
Installer
– Angaben zum Installer wie Name bzw. Typ
sowie die Interface-Sprache
Art der Einbindung in das System
– gibt an, ob die PPPoE-Software als virtuelle Ethernet-Karte ( LAN-Emulation“), neu”
es Protokoll oder als virtuelles Modem installiert wird
notwendige Aktionen (default)
– Anzahl und Angabe aller bei der Installation
notwendigen Handlungen bzw. Entscheidungen (Voreinstellung in Klammern)
notwendige Angaben (default)
– Eingaben, die vom Anwender getätigt werden müssen (Voreinstellung in Klammern)
Neustarts Installation/Deinstallation – Anzahl der Neustarts jeweils für Installation und Deinstallation (in Klammern Angabe
des Betriebssystems)
Platzbedarf in Megabyte
– von der Software ungefähr benötigter Festplattenplatz in Megabyte
Bemerkungen
– zuätzliche Angaben zu Installationsvoraussetzungen bzw. Abweichungen von der Norm
Verbindungseinrichtung
Im Gegensatz zum vorigen Abschnitt sind in diesem Abschnitt nur Angaben zur allgemeinen Verbindungseinrichtung aufgeführt. Obwohl theoretisch mehrere Accounts
möglich sind, beschränkt sich dies praktisch im Allgemeinen auf eine Verbindung,
da der Anschluss eines Rechners mit jeweils einer Netzwerkkarte an mehrere DSLLeitungen eher unüblich ist. Hier nicht mit aufgeführt sind Aktionen und Angaben,
die im Rahmen der Installationsprozedur nötig sind.
Frontend
– Angaben zum Frontend wie Name bzw. Typ
sowie die Interface-Sprache
– Eingaben, die vom Anwender getätigt werden müssen (Voreinstellung in Klammern)
38
7 Testprotokoll
Verbindungsoptionen
– optionale Einstellungen, die nur für eine spezifische Verbindung gelten
TCP/IP
– Einstellungen, die TCP/IP betreffen und im
DFÜ-Netzwerk eingestellt werden können
IP-Adresse: Auswahl, ob fixe Adresse für PC
vergeben oder diese vom Server bezogen werden soll
DNS-Adressen: Auswahl, ob fixe DNS-Adressen vergeben oder diese vom Server bezogen
werden sollen
IP-Headerkomprimierung: Wahl, ob IP-Header komprimiert werden sollen
Standard-Gateway benutzen: gibt an, ob der
zugewiesene Standard-Gateway der WANVerbindung benutzt werden soll
Netzwerkanmeldung
– Wahl, ob NetBIOS-Anmeldung im Netz mit
Windows-Anmeldenamen und -Kennwort erfolgen soll
– Idle Timeout 0min. . .23h: gibt an, ob bei
Leerlauf der Verbindung eine Trennung erfolgt und ob die Zeitspanne, nach der getrennt werden soll, einstellbar ist
Verbindungsprotokoll verwenden
– Angabe, ob Protokoll erstellt werden soll
Auswahl Netzwerkkarte
– Wahl der Netzwerkkarte
Wahl Verschlüsselung
– Wahl des PPP-Authentifizierungsprotokolls
– PAP (unverschlüsselt) oder CHAP (verschlüsselt) im Allgemeinen
Auswahl Server / Service
– Auswahl eines Servers oder Service für Verbindung – betrifft den Einsatz bei verschiedenen DSL-Anbietern und erlaubt Änderung
der Einstellung für Verbindung
PPP-Konfiguration
– LCP-Erweiterungen aktivieren: Aktivierung
der LCP-Extensions nach RFC 1570
Softwarekomprimierung aktivieren: PPPKomprimierung
bei
Verbindung
mit
Windows-PCs aktivieren
Mehrfachverbindungen für Einzelverbindungen aushandeln: Nutzung von Multilink-PPP
39
7 Testprotokoll
Route bei Verbindung nicht verändern
– Einstellung, ob die festgelegte Route bei Verbindungsaufbau geändert werden soll oder
die alte Route beibehalten wird
globale Verbindungsoptionen
– Einstellungen, die für alle Verbindungen gelten
TCP/IP
– siehe Verbindungsoptionen
Verbindungsprotokoll verwenden
Netzwerkanmeldung
MSS begrenzen
– Möglichkeit zur Begrenzung der maximalen
Segmentlänge (TCP/IP)
MTU ändern
– Festlegung einer anderen MTU als dem Eintrag in der Windows-Registry
regulärer Betrieb
Alle für den regulären Betrieb relevanten Angaben sind in diesem Abschnitt aufgeführt.
Diese Informationen entscheiden über die Langzeittauglichkeit eines Clients, daher sind
sie getrennt aufgeführt. Nach der Installation wird der Kunde vorrangig mit dem Interface für den regulären Betrieb in Berührung kommen, dass heisst mit dem konkreten
Verbindungsauf- und -abbau.
Interface
– Angaben zum Frontend wie Name und Sprache, bei
– bei Angabe mehrerer Schnittstellen sind mehrere Frontends vorgesehen
Konfig. Verbindungsverhalten
– hierunter fallen Informationen, die das Verhalten des Clients bei der Verbindungsaufnahme betreffen
selbst. Verbindungsaufnahme BS-Start
– Client stellt bei dem Start des Betriebssystems selbständig die Verbindung her – dies
schliesst eine Trennung bei Herunterfahren
des Computers mit ein
selbst. Verbindungsaufn. Programmstart
– Client stellt bei seinem Start selbständig die
Verbindung her
Dial-on-Demand
– selbständige Verbindungsaufnahme bei Aufruf einer nicht im lokalen Netz befindlichen
IP-Adresse
selbst. Trennung b. Leerlauf / einstellbar
– zeigt an, ob eine Trennung bei Leerlauf möglich ist und ob die Zeitdauer einstellbar ist
(in Klammern Einstellmöglichkeiten)
40
7 Testprotokoll
weitere konfigurierbare Parameter
– weitere Parameter, die vom Benutzer konfiguriert werden können
Wiederwahl bei Verbindungsabbruch
– zeigt, ob Client selbständig Verbindung wieder herstellt, wenn diese aus verschiedenen
Gründen getrennt wurde
Sound/Browser b. Verbindungsaufbau
– gibt an, ob bei Verbindungsaufnahme eine
Klangdatei abgespielt oder der Browser direkt gestartet wird
Wahlwiederholung
– zeigt, ob Client ständig versucht, Verbindung
aufzubauen, falls dies beim ersten Versuch
nicht funktioniert hat
Daten- und Gebührenbudget pro Monat
– Client besitzt die Möglichkeiten, Budgets zu
verwalten und gibt dem Nutzer die Möglichkeit der Begrenzung des Datenvolumens bzw.
der Gebühren pro Monat
Begrenzung Upstreamgeschwindigkeit
– zeigt an, ob Upstream-Geschwindigkeit limitiert werden kann, um volle Geschwindigkeit
beim Download zu erreichen
protokollierte Standardinformationen – Informationen über die Protokollierung der
Informationen Zeit, Gebühr und Datenvolumen bei Angabe der möglichen Zeitintervalle
Logfile
– Informationen über weitere protokollierbare
Informationen
Zeit Verbindungsaufbau/-abbruch
– Zeit des Verbindungsaufbaus und -abbruchs
Session-Statistik: read/write bytes
– Statistik, wieviel Bytes pro Verbindung gelesen bzw. geschrieben wurden
Ethernet-Frames
– ermöglicht die Protokollierung aller EthernetRahmen
AT-Befehle
– ermöglicht die Protokollierung aller AT-Befehle
Performance
In diesem Abschnitt sind die einzelnen Testergebnisse angegeben – die erzielte Datenrate in Kilobyte pro Sekunde ist abhängig von der Paketgröße1 aufgeführt und der
Maximal-, Minimal- und Durchschnittswert pro Client je Betriebssystem angegeben.
Die Werte sind in Up- und Downstream unterteilt, um eine getrennte Bewertung in
dieser Hinsicht zu ermöglichen.
1
1, 2, 4, 8, 16, 32 Kilobyte
41
Teil IV
Resultate
42
8 Vorbetrachtungen zur
Auswertung
8.1 Datenrate
Um die von NetIO erhaltene Datenrate in Bezug zur maximalen Datenrate über die
G.SHDSL-Verbindung setzen zu können, ist eine Abschätzung des Gesamt-Overheads
nötig.
G.SHDSL: Die unterste Schicht der Übertragung ist G.SHDSL, welche eine maximale Nutzdaten-Übertragungsrate von 2312 kbit/s bietet.
ATM:
Über DSL wird ATM übertragen, welches einen fünf Byte großen Header
pro 53-Byte-Zelle aufweist – der Overhead durch das genutzte AAL5
beträgt 56 Byte (Trailer) bei 65 KByte Nutzdaten.
56 Byte
5 Byte
+
= 0.0952 =
b 9.52 % Overhead
53 Byte 65536 Byte
PPPoE:
PPPoE weist zwei ineinander geschachtelte Protokolle auf, dementsprechend ist zweimal Overhead vorhanden. Ethernet besitzt bei 1500 Byte
Nutzdaten 18 Byte Overhead, darauf setzt PPPoE auf, welches bei einer
maximalen MTU von 1500 (Beschränkung durch Ethernet) einen Header von acht Byte besitzt. Die Nutzdatengröße für die nächste Schicht
beträgt noch 1492 Byte.
18 Byte
8 Byte
+
= 0.0172 =
b 1.72 % Overhead
1518 Byte 1500 Byte
TCP/IP:
Die nächsthöhere und letzte Schicht ist TCP/IP, diese Protokollkombination weist einen Header von insgesamt 40 Byte pro 1492 Byte auf.
40 Byte
= 0.0268 =
b 2, 68 % Overhead
1492 Byte
43
Der Gesamtoverhead summiert sich also auf
9.52 % + 1.72 % + 2, 68 % = 13, 92 %
und damit ergibt sich bei Abzug des Overheads von 2320 kBit/s eine maximale Datenrate von 1997,1 kbit/s =
b 249,6 kByte/s – dies entspricht somit in etwa der im
Test zu erwartenden Maximal-Datenrate. Diese kann aus verschiedenen Gründen noch
variieren, je nachdem, ob bestimmte Optionen benutzt werden, die zusätzlichen Overhead produzieren oder diesen reduzieren; denkbar wäre in diesem Zusammenhang z. B.
Headerkomprimierung.
In diesem Zusammenhang wird sich fast zwangsläufig ein Einbruch der Datenrate bei
kleinen Paketgrößen ergeben, da bei diesen eine gewisse Fragmentierung durch die
darunter liegenden, jedes mit anderer Nutzdatengröße versehenen, Protokolle entsteht.
Mit großen Paketen lässt sich der Container für Nutzdaten komplett füllen, was die
Fragmentierung reduziert bzw. vermeidet. Die maximale Paketgröße von 32 Kilobyte
NetIO ist dabei vollkommen ausreichend, da keines der Protokolle mehr Nutzdaten
als 1500 Bytes pro Paket bzw. Zelle in der vorliegenden Konfiguration zuläßt – die
Beschränkung stellt in dieser Hinsicht Ethernet dar.
8.2 CPU-Belastung
Der Vergleich der CPU-Belastung ermöglicht es, die Clients hinsichtlich effizienter
Nutzung der Ressourcen zu bewerten. Dabei wird die Vergleichbarkeit dadurch gewährleistet, dass alle Software-Clients jeweils pro Betriebssystem verglichen werden –
unterschiedlich effiziente TCP/IP-Stacks innerhalb der Windows-Versionen zum Beispiel betreffen dementsprechend alle Clients gleichermaßen.
Der Vergleich der PPPoE-Clients ermöglicht nebenbei einen Vergleich der Betriebssysteme untereinander, vor allem im Bereich des Multitaskings und der Effizienz des
TCP/IP-Stacks. Eine Bewertung der Multitaskingfähigkeit ist möglich, da zum Test
mehrere Programme nötig sind – dies sind die PPPoE-Software, das Programm zum Ermitteln der Datenrate ( NetIO“) und das Monitoring-Programm zum Überwachen der
”
CPU-Belastung ( CPUCool“). Aufgrund der moderneren Betriebssystem-Architektur
”
ist zu erwarten, dass die CPU-Belastung bei den auf NT basierenden Windowsversionen tendenziell geringer sein wird.
Bestehende Unterschiede zwischen den PPPoE-Clients können prinzipiell aus mehreren
Ursachen resultieren:
• Die Nutzung effizienter Algorithmen bei der Programmierung belastet durch
schnellere Abarbeitung den Prozessor weniger. Jedes TCP/IP-Paket muss zum
Beispiel in einen PPPoE-Rahmen verpackt werden – Unterschiede in der Effizienz
der Algorithmen bei der Anfügung der Rahmeninformationen sind denkbar. Die
44
erwarteten Unterschiede sind auf heutigen Prozessoren sicher eher gering, aber
durchaus noch vorhanden.
• Durch Quellcodeoptimierungen vor allem auf Compiler-Ebene kann die Software
auf bestimmte Prozessoren optimiert werden. Dies stellt immer einen Kompromiss dar, da die Optimierung auf einen Prozessortyp andere benachteiligt – so
ist eine Optimierung auf Intel-Prozessoren denkbar, was in einer reduzierten Abarbeitungsgeschwindigkeit auf AMD-Prozessoren resultiert.
• Unterschiedliche Konzepte wie zum Beispiel Modem- oder LAN-Emulation erfordern die Ansteuerung verschiedener Schnittstellen innerhalb des Betriebssystems.
Dies kann durch eine erhöhte Anzahl von Abstraktionsebenen die Effizienz reduzieren.
• Clients, die für eine große Anzahl von Betriebssystemen verfügbar sind, erfordern
unter Umständen eine stärkere Abstrahierung bei einzelnen Programmteilen, um
den Portierungsaufwand für den Hersteller zu begrenzen. Dies resultiert in einer
verringerten Performance im Vergleich zu Clients, die für nur wenige Betriebssysteme verfügbar sind und dementsprechend optimiert werden können.
Die in den folgenden Abschnitten enthaltenen Abbildungen stellen die CPU-Belastung
in Prozent sowie die durchschnittliche Übertragungsrate dar.
45
9 Clients
9.1 cFOS DSL OEM
cFOS nimmt neben RASPPPOE eine Sonderstellung ein, da dieser Client, im Gegensatz zur üblichen Lösung mit virtuellem Netzwerkadapter, auf Basis einer ModemEmulation arbeitet. Er implementiert ein Software-Modem, welches sich als virtueller COM-Port installiert und darüber kommuniziert – dies hat den Vorteil, dass auf
das DFÜ-Netzwerk zur Verbindungsherstellung und -konfiguration zurückgegriffen werden kann. Ein zusätzlicher Vorteil ist die Möglichkeit, das Software-Modem über ATBefehle zu steuern, da dies den Einsatz einer breiten Palette von Programmen wie
z. B. Terminal-Programmen ermöglicht, die lediglich über die serielle Schnittstelle Daten austauschen können.
9.1.2 Installation
Die Installation der OEM-Version von CFos, der lediglich unbenötigte Teile wie ISDNoder Firewall-Funktionalität fehlen, benötigt als einzige keinerlei Aktionen bei der
Installation. Zur Verbindungseinrichtung müssen lediglich Benutzername, Kennwort
und Bezeichnung für die DFÜ-Verbindung angegeben werden. Es installiert sich in das
vordefinierte Verzeichnis C:\CFos und richtet sich automatisch als Software-Modem
unter COM-Port 4 ein. Für den unerfahrenen Benutzer ist diese Lösung sicherlich die
einfachste.
Nach den Angaben kann die Verbindung über die bereits auf dem Desktop angelegte
Verknüpfung hergestellt werden. Auffällig ist das von CFos genutzte Fenster über der
Startleiste, auf das nicht verzichtet werden kann – es ist lediglich die Angabe anderer
Skins möglich.
Mittels AT-Befehlen kann der Client vielfältig angepasst werden – die Spanne der
Konfigurationsmöglichkeiten reicht von Budgetverwaltung bis Firewall. Zur Flexibilität dieser Lösung kommt die komplizierte Konfiguration über Terminal-Programm
46
9 Clients
oder AT-String bei der Verbindungskonfiguration, die vor allem im Gegensatz zur
einfachen Installation steht.
9.1.3 Leistung
Die Leistungsbewertung für CFos kann nur negativ ausfallen: Es konnten auf Windows 95/98 Upstreamraten von lediglich 37. . .44 Kilobyte/s erreicht werden, was diesen Client für sinnvollen Betrieb an einer symmetrischen DSL-Verbindung ausschließt.
Auf Windows ME, NT und 2000 werden zumindest bei größeren Paketen akzeptable
Datenraten von über 100 Kilobyte/s erreicht, vor allem unter Windows 2000 ist die
Verbindung vergleichbar mit den besten Clients. Downstream werden im Gegensatz
dazu Datenraten knapp unter dem theoretischen Limit erreicht.
Die CPU-Belastung fällt negativ auf, da sie auf allen Betriebssystemen mit Ausnahme von Windows NT / Upstream unabhängig von der Richtung des Datenflusses
die CPU am stärksten belastet. Im Downstream schwankt die durchschnittliche CPUBelastung zwischen 7 und 15 % und Upstream zwischen 3 und 6 % (bei der Ausnahme
Windows NT liegt die Belastung unter einem Prozent) Bei den niedrigen Datenraten ist die CPU-Belastung beim Vergleich mit anderen Clients noch höher zu gewichten.
9.1.4 Bewertung
Als die schlechten Ergebnisse mit dem Hersteller diskutiert wurden, konnte dieses Verhalten nicht schlüssig erklärt werden – dabei ist es einem Kunden einer symmetrischen
DSL-Verbindung mit theoretischen 2,3 MBit/s sicherlich schwer zu vermitteln, warum
er bei Uploads lediglich 16 % der maximalen Datenrate aufgrund dieser Software nutzen kann. Es bleibt zu vermuten, dass CFos den DSL-Teil des Clients lediglich an
ADSL-Verbindungen getestet hat, wo diese Einbrüche in der Datenrate nicht auffallen
können.
Die Ergebnisse wurden ob ihrer drastischen Abweichung vom theoretischen Maximum
mehrfach auf einer nur für CFos aufgesetzten Windows-Installation getestet, die Ergebnisse änderten sich dabei nicht.
Unerfahrenen Benutzern kommt die leichte Installation entgegen, die auch SupportAufwand seitens des Anbieters reduzieren dürfte. Die Konfiguration mit ATBefehlen ist sehr flexibel, dürfte aber trotzdem nur wenigen Benutzern zusagen.
47
9 Clients
9.2 Enternet 300 Win
Enternet von Efficient Networks stellt dem System einen virtuellen Netzwerkadapter1 zur Verfügung. Dies wird über einen Miniport-Treiber realisiert, der über die
NDIS-Schnittstelle Daten erhält und die Daten für die reale Netzwerkkarte horizontal
direkt an diese weiterreicht. Die Stellung des Miniport-Treibers innerhalb der WindowsNetzwerkarchitektur ist in Abbildung 9.1 dargestellt.
Dieses Konzept wird von Windows durch die virtuellen erweiterten Treiber (Virtual
Extended Driver, VxD) unterstützt. Die Bereitstellung der PPPoE-Funktionalität mittels eines VxD läuft allerdings der Netzwerkarchitektur und dem OSI-Modell zuwider
– dies liegt daran, dass Miniports normalerweise Treiber für reale Hardware darstellen
und nicht als Zwischenglied“ fungieren. Für derartige Aufgaben sind die Intermediate
”
Driver (IM) ab Windows 98 vorgesehen.
Das Konzept des virtuellen Netzwerkadapters bietet vor allem den Vorteil, den PPPoEClient auf allen Windows-Versionen inklusive Windows 95 einsetzen zu können, da bei
letzterem das Konzept des IM noch nicht verwirklicht ist, VxDs aber bei allen Versionen möglich sind. Zusätzlich können sich Performance-Vorteile durch den teilweisen
Verzicht auf die NDIS-Schnittstelle ergeben.
9.2.2 Installation
Die Grund-Installation verlief auf jedem der getesteten Betriebssysteme problemlos
ohne Abfragen (Quick-Install). Nach dem anschliessenden Neustart können Verbin-
NDIS-Schnittstelle
TransportProtokolle
Protokoll-Funktionen
Miniport-Funktionen
virtueller
Netzwerkadapter
Miniport-Funktionen
Datenpfad
NICTreiber
Netzwerkkarte
Abbildung 9.1: Virtueller Netzwerkadapter in der Windows-Netzwerkarchitektur
1
Bezeichnung: Efficient Networks P.P.P.o.E. Adapter (NTSP3)
48
9 Clients
dungen eingerichtet werden, was ebenfalls problemlos mit nur wenigen Abfragen gelingt.
Negativ fällt auf, dass die komplette Oberfläche in Englisch gehalten ist. Desweiteren
zeigt sich, dass die komplette Oberfläche der DFÜ-Verbindung nachempfunden ist,
aber offensichtlich nicht auf dieser basiert. Dies hat den Vorteil, dem Benutzer die
Bedienung zu erleichtern, dennoch erzeugt diese Vorgehensweise unnötigen Balast, wie
sich auch in der Installationsgröße von 7 MB zeigt.
Die Konfiguration ist vergleichbar zu den Clients, die auf dem DFÜ-Netzwerk basieren; so lassen sich z. B. dieselben TCP/IP-Einstellungen oder Timeout-Zeiten einstellen – dies zeigt einmal mehr die Anlehnung daran. Positiv zu vermerken ist
die Möglichkeit zum Packet Logging, welches den kompletten Ethernet-Verkehr mitschneidet. Damit lassen sich bestimmte Fehler ohne Zusatzprogramme leicht einkreisen.
9.2.3 Leistung
Die Downstream-Performance von Enternet läßt keine Schwächen erkennen – vor allem unter Windows NT und 2000 kann eine sehr gut mit der Paketgröße skalierende
Datenrate bei allerdings nur mittlerer CPU-Belastung beobachtet werden. Unter den
auf DOS basierenden Betriebssystemen stellt sich die Situation nicht wesentlich anders
dar: CPU-Belastung ist im Grunde nicht vorhanden und die Datenrate mit maximal
243 kByte/s hoch, lediglich unter Windows 98 lassen sich viele Belastungs-Peaks erkennen und die Datenrate bricht etwas ein. Letzteres läßt Kommunikationsprobleme mit
verschiedenen Komponenten vermuten, zeigt sich aber auch bei den anderen Testkandidaten, deshalb wird die Ursache wahrscheinlich beim Betriebssystem liegen. Beim
Upstream zeigt sich genau das gleiche Verhalten, was den Unterschied zwischen DOSund NT-basierten Versionen zeigt. Ebenso sind die Peaks bei Windows 98 zu erkennen.
Die Leistungsbetrachtung zeigt, dass Enternet wahrscheinlich auf die DOS-basierenden
Consumer-Betriebssysteme optimiert ist und deswegen unter Windows NT und 2000
der Kern weniger effektiv arbeitet. Dies ist dann vernünftig, wenn die Software zum
großen Teil unter diesen Betriebssystemen eingesetzt wird. Möglichweise fiel die Optimierung leichter, weil die DOS-basierten Windowsversionen weiter verbreitet sind und
daraus mehr Feedback resultiert.
9.2.4 Bewertung
Enternet hinterläßt ein durchweg positives Bild: Es zeigten sich keine Instabilitäten,
so daß der Client sauber programmiert zu sein scheint. Dies spiegelt ebenfalls die sehr
49
9 Clients
gute Performance wider, die keinerlei Schwächen offenbart. Offensichtlich wurde durch
den Hersteller viel Wert auf Optimierung gelegt.
Negativ bleibt Efficient Networks anzulasten, dass Enternet nur in Einzel- oder Tausenderlizenzen erhältlich ist – dies kommt kleinen Providern nicht zugute. Der Preis
für Einzellizenzen ist allerdings vergleichsweise günstig.
Sowohl Leistung, Funktionssicherheit als auch Installationsprozedur sprechen für diesen PPPoE-Client, der Trend zum Programm mit vergleichsweise hohem Speicherbedarf (7 MB) dagegen.
9.3 POETRI
Das PPPoverEthernet IP-Routing Interface“ greift bei der Einbindung in die
”
Netzwerkarchitektur wie Enternet auf das Prinzip des virtuellen Netzwerkadapters zurück. Die Beschreibung in Abschnitt 9.2.1 gilt dementsprechend ebenfalls
hier.
9.3.2 Installation
Die Installationsprozedur von POETRI ist in zwei Abschnitte unterteilt. Im ersten
wird das Programm installiert, allerdings besteht diese Prozedur lediglich aus dem
Kopieren der Dateien an den richtigen Ort und dem Anlegen einer Startmenügruppe.
Im zweiten Teil muss der virtuelle Netzwerkadapter von Hand installiert werden, bevor
nach einem Neustart das Programm verwendet werden kann – diese Vorgehensweise
wirkt etwas unkonventionell und erschwert die Installation für unerfahrene Benutzer
zusätzlich.
Nach der Installation kann eine Verbindung hergestellt werden, was nach dem Umschalten auf xDSL problemlos gelingt. Auffällig bei Installation und Verbindungseinrichtung sind die wenigen Einstellmöglichkeiten – dies begrenzt die Funktion des Clients nicht, ermöglicht aber kaum Fehlerbehebungen mit Bordmitteln. Trotz der wenigen Möglichkeiten überzeugt POETRI mit der einfachen Konfiguration der Standardfunktionalitäten wie Wahlwiederholung oder Start eines Programms bei Verbindungsaufbau. Positiv zu vermerken sind die deutsche Dokumentation und Benutzeroberfläche.
Neben PPPoE stellt POETRI einen Software-Router dar, mit dem über IP-Masquerading LANs an einem DSL-Anschluss genutzt werden können. Dies ist einfach gelöst, wird aber an dieser Stelle nicht weiter verfolgt, da diese Funktionalität ausdrücklich nicht gefordert war. Die erweiterten Möglichkeiten schlagen sich kaum im
50
9 Clients
Platzbedarf nieder, so benötigt POETRI etwa 3 MB Festplattenplatz nach der Installation. Dies ist vergleichweise wenig, wenn man es mit 7 MB bei Enternet vergleicht.
9.3.3 Leistung
Die Leistung im Downstream stellt sich gemischt dar: Bei den DOS-basierten WindowsVersionen und Windows NT liegt die durchschnittliche Datenrate immer unter den
besten Clients, teilweise bis zu 8 %. Die CPU wird mit durchschnittlich 1 % unter
Windows 95/98, 4 % bei Windows ME und 2.5. . .3 % unter Windows NT belastet –
während ersteres vernachlässigtbar ist, ist vor allem unter Windows ME eine recht
hohe Belastung zu konstatieren. Unter Windows 2000 erreicht POETRI die gleichen
Datenraten wie die besten Clients (RASPPPOE, Enternet), allerdings mit einer hohen
CPU-Belastung von 5 %.
Im Upstream werden von POETRI bei durchgängig niedriger CPU-Belastung nur
bei Paketgrößen von 4 oder 8 KByte akzeptable Datenraten von über 110 Kilobyte/s erreicht, bei anderen Paketgrößen konnten nur niedrige Datenraten von um die
65 KByte/s gemessen werden. Unter Windows 2000 brachen die Datenraten teilweise auf 10 KByte/s ein, was bei einem Maximum von 250 KByte/s inakzeptabel
ist.
9.3.4 Bewertung
POETRI kann bei keiner der Testkriterien überzeugen, so ist die Installation unnötig kompliziert und die Performance nur im Download überzeugend. Zugute halten
muss man POETRI die deutsche Anleitung und die flexiblen Möglichkeiten bei der
Lizensierung. Letzteres kann bei kleinen benötigten Lizenzzahlen für einen Carrier entscheidend sein, allerdings liegt der Preis durch die Routerfunktionalität tendenziell
höher als bei reinen Zugangslösungen.
9.4 RASPPPOE
RASPPPOE ist, im Gegensatz zu allen anderen PPPoE-Clients, als NDIS Intermediate
Driver (IM) realisiert. Dies bedeutet, dass RASPPPOE zwischen dem Protokolltreiber und dem Netzwerkkartentreiber als Vermittler“ fungiert und dem Benutzer die
”
Kontrolle gibt, entsprechende Bindungen anzulegen. Abbildung 4.3 auf Seite 29 zeigt
die Stellung des IM in der Netzwerkarchitektur.
51
9 Clients
TransportProtokolle
Protokoll-Funktionen -- Medium X
NDIS-Schnittstelle
Miniport-Funktionen -- Medium X
Intermediate Driver
Protokoll-Funktionen -- Medium Y
Miniport-Funktionen -- Medium Y
NICTreiber
Netzwerkkarte
Abbildung 9.2: NDIS Intermediate Driver zwischen Protokoll- und NIC-Treiber (modifiziert nach [7])
Um die PPPoE-Funktionalität zu realisieren, stellt ein Intermediate Driver nach unten
Protokoll-Einsprungpunkte bzw. Protokollfunktionen bereit, die vom NDIS bei Anfragen der weiter unten liegenden Miniports aufgerufen werden – einem Miniport-Treiber
stellt er sich wie ein normaler“ Protokolltreiber dar. Damit Kommunikation nach oben
”
möglich ist, stellt ein IM Miniport-Funktionen bereit, die vom NDIS bei Anfragen
der obenliegenden Protokolltreiber aufgerufen werden und erscheint von oben gesehen
als Miniport-Treiber. Abbildung 9.2 illustriert die Bereitstellung der Einsprungpunkte.
Obwohl sich der Intermediate Driver wie ein Miniport den obenliegenden Protokolltreibern darstellt, kommuniziert er jedoch nicht direkt mit der Hardware. Um dennoch
Bindungen anlegen zu können, stellt der IM zu diesem Zwecke ein oder mehrere virtuelle Adapter bereit. Wenn entsprechend der Bindung ein Protokolltreiber Anfragen
oder Pakete an den virtuellen Adapter sendet, werden diese an den untenliegenden
Miniport weitergeleitet – in umgekehrter Richtung werden vom Miniport stammende Anfragen und Pakete an den Protokolltreiber weitergeleitet, der an den virtuellen
Adapter gebunden ist. Auf diese Weise wird über das Konzept der Bindungen und
virtuellen Adapter der Datenfluss gesteuert.
Das Konzept des IM erscheint bei RASPPPOE glücklich gewählt, da es auf systemkonforme Art und Weise die Einbindung eines neuen Protokolls ermöglicht. Es kann
auf die Benutzung von z. T. undokumentierten Schnittstellen verzichtet werden, was
der Stabilität eher zugute kommen sollte. Daneben wird die Steuerung durch den
Benutzer über Bindungen ermöglicht. Der Preis für dieses Konzept ist die Inkompatibilität zu Windows 95, da dort das Konzept der Intermediate Driver noch nicht
52
9 Clients
implementiert ist – bei einem für Privatkunden kostenlosen Treiber mag dies verschmerzbar sein, für Anbieter kommerzieller Zugangssoftware scheint dieser Weg nicht
gangbar, da Windows 95 derzeit noch eine entsprechend hohe Marktdurchdringung
besitzt.
9.4.2 Installation
Die Installation gestaltet sich bei RASPPPOE für unerfahrene Benutzer eher schwierig, da kein Installationsprogramm existiert und damit entsprechend viele Aktionen notwendig werden – nebenbei ist die Bedienoberfläche ebenso wie die Installationsanleitung in Englisch gehalten und stellt damit ein zusätzliches Hindernis
dar.
Neben des Hinzufügen eines Protokolls mit Pfadangabe in der Netzwerkumgebung
muss das RASPPPOE-Dienstprogramm aufgerufen und ein Server ausgewählt werden.
Nach Abschluss ist die Bedienung einfach, da auf die Mechanismen von Windows wie
z. B. die DFÜ-Verbindung zurückgegriffen und damit dem Benutzer eine vertraute
Umgebung geboten wird. Bei den Verbindungsoptionen kommen lediglich die Einstellungen für DFÜ-Verbindungen zum Einsatz. Dies stellt keinen Nachteil dar, da wegen sinnvoller Voreinstellungen Veränderungen bei der Konfiguration nicht notwendig
sind – unnötige Protokolle sind ebenso wie die Netzwerkanmeldung abgestellt. Die
Installation bietet in der Hinsicht vernünftige Einstellungen an, die bei den meisten
DSL-Providern einen schnellen Verbindungsaufbau ermöglicht.
Die Nutzung der Standard-Mechanismen bietet den weiteren Vorteil, die Windowseigene Protokollfunktion nutzen zu können.
Neben der einfachen Installation benötigt RASPPPOE neben dem Linux-Client den
kleinsten Platzbedarf – dies zeigt ebenfalls die Überlegenheit des Konzepts, die Funktionalität über die Windows-Mechanismen zu erreichen.
Neben den Parametern für die DFÜ-Verbindung, die im Allgemeinen für eine schnelle DSL-Verbindung nicht verändert werden müssen, stellt PPPoE zwei Parameter
zu Vermeidung von Verbindungsproblemen bereit: ’Limit MSS’ und ’Override Maximum Transfer Unit’. Erstere limitiert die maximale Größe der Nutzdaten bei TCP/IPPaketen und umgeht so Performance-Einbußen bei Netzwerkverbindungen, bei denen
die MTU unüblich eingeschränkt ist. Die zweite Option ermöglicht die Umgehung der
MTU für alle DFÜ-Verbindungen. Beide Optionen stellen eine sinnvolle Erweiterung
dar, wurden im Testszenario aber nicht benötigt.
9.4.3 Leistung
RASPPPOE bietet im Downstream ausnahmslos die besten Übertragungsraten bei
sehr niedriger CPU-Belastung, unabhängig vom Betriebssystem. Dies gilt vor allem
53
9 Clients
bei einer Blockgrösse von 32k, bei der sich die Übertragungsrate mit 240 bis 249 kB/s
nahe dem theoretischen Maximum bewegt. Die geringe CPU-Belastung läßt eine gute
Kombination aus dem richtigen Treiberkonzept und sorgfältiger Programmierung bzw.
Optimierung erkennen. Im Upstream lassen sich unter Windows NT, 95 sowie 98 leichte
Schwächen ausmachen, so ist bei Windows 95 und 98 die Upstream-Datenrate bei einer
Paketgröße von 32 Kilobyte sehr niedrig, während bei kleinen Paketgrößen keinerlei
Einbruch bemerkbar ist. Unter NT fällt der generelle Einbruch der Übertragungsraten
auf, der vergleichbar mit CFos sowie POETRI ist – dies liegt sehr wahrscheinlich an der
fehlenden Optimierung des Herstellers, da dies die erste Version mit NT-Unterstützung
ist. Für kommende Versionen ist hier eine Änderung zu erwarten.
9.4.4 Bewertung
Zusammenfassend läßt sich RASPPPOE eine hohe Leistung attestieren. Der Client
stellt beim Preis-Leistungs-Verhältnis für den Privatkunden die erste Wahl dar, allerdings erfordert die Installationsprozedur erhöhten Aufwand.
9.5 WinPOET
WinPOET wird genauso wie Enternet als virtueller Netzwerkadapter in die WindowsNetzwerkarchitektur eingebunden. Die Beschreibung in Abschnitt 9.2.1 gilt dementsprechend ebenfalls hier.
9.5.2 Installation
Die Installation gelingt leicht – zur Grundinstallation sind keine Angaben erforderlich,
die Verbindung lässt sich durch Eingabe des Benutzernamen und des Kennwortes ohne
Probleme herstellen. Die Einstellungen, die WinPOET ermöglcht, entsprechen denen
der DFÜ-Verbindung.
Die Deinstallation ist unglücklich realisiert – bei der Installation wird ein Schnappschuß
der Netzwerkkonfiguration erstellt, der bei Deinstallation wieder hergestellt wird. Dies
dabei löscht jede nach der Installation vorgenommene Änderung der Netzwerkkonfiguration.
54
9 Clients
9.5.3 Leistung
Im Downstream erreicht WinPOET sehr gute Werte bis auf Windows 98 – hier ist ein
leichter auf 162 KByte/s bei Paketgröße 32 Kilobyte zu verzeichnen. Um Upstream
ist die Leistung unter Windows 2000 und 98 akzeptabel; unter Windows 95 ist ein
Einbruch bei einer Paketgröße von 16 bzw. 32 Kilobyte zu verzeichnen. Unter Windows ME fällt die Datenrate bei 16kB-Paketen stark auf 32 kB ab – dies ist bei einer
symmetrischen Verbindung nicht akzeptabel.
Bei Windows NT war keine Messung möglich, da NetIO bei einer durch WinPOET
hergestellten Verbindung nicht korrekt funktionierte. Da dies die Ausnahme im gesamten Testfeld darstellt, lässt dies auf eine gewisse Inkompatibilität seitens WinPOET
schließen.
9.5.4 Bewertung
WinPOET kann in keine der Kategorien überzeugen – die Deinstallation ist ebenso
inakzeptabel wie die auftretende Inkompatibilität sowie die teilweise geringen Datenraten.
9.6 Windows XP nativ
Der Test des in Windows XP integrierten Clients dient der Überprüfung, inwiefern die
Integration durch Microsoft gelungen ist. Testaufbau und -software wurden gegenüber
den anderen Tests nicht geändert.
Die Installation fällt durch den Assistenten bemerkenswert leicht, da lediglich zwei
Entscheidungen zu treffen sowie die üblichen Angaben nötig sind. Die komplette Oberfläche ist in Deutsch gehalten, was die Installation zusätzlich erleichtert. Der Client
wurde komplett in das DFÜ-Netzwerk integriert und bietet damit die üblichen Konfigurationsmöglichkeiten.
Die Leistungsfähigkeit ist im Downstream bei geringer CPU-Belastung und hoher Datenraten um 238. . .240 KByte/s bei einer Paketgröße von 32 Kilobyte vergleichbar mit
RASPPPOE. Im Upstream relativiert sich dies, da hier nur 80. . .118 KByte/s erreicht
werden bei weiterhin geringer CPU-Belastung um 1 %.
Zusammenfassend läßt sich bemerken, dass die Integration geglückt ist. Die Leistung
im Upstream lässt den Client für Einsatz bei einem Anbieter symmetrischer BreitbandZugänge nicht sinnvoll erscheinen.
55
9 Clients
9.7 Roaring Penguin
Als Testkandidat auf SuSE-Linux 7.1 wurde Client Roaring Penguin (RP) getestet, der
für eine leichte Einrichtung bekannt ist. Die Installation ist tatsächlich sehr einfach, da
nach Installation des RPMs über den SuSE-Paketmanager lediglich ein Script für die
Verbindungseinrichtung aufzurufen ist. Dieses fragt die Einstellungen ab, wobei nur die
Wahl der Netzwerkkarte auf Grund einer ungewöhnlichen Voreinstellung etwas schwieriger erscheint, und schreibt die Konfigurationsdatei. Letztere ist auch manuell editierbar, dies ist wegen des guten Scripts aber nicht notwendig. RP stellt zusätzlich IPMasquerading sowie eine fertig konfigurierte Firewall bereit und bietet damit eine erweiterte Funktionalität an. Die Installationsgröße des Clients fällt mit 200 Kilobyte deutlich geringer als bei den Windows-Versionen aus. Dies zeigt, wieviel Overhead durch
den Verzicht auf grafische Oberflächen eingespart werden kann.
Der Leistungstest bescheinigt dem Client bei beiden Datenrichtungen hervorragende
Übertragungsraten. Die Spitzenwerte werden zwar von den Windows-Clients teilweise
übertroffen, die Zuverlässigkeit der Verbindung zeigt sich in der geringen Abweichung
der Maximal- von den Minimalwerten.
Die CPU-Belastung2 fällt durch die Tatsache, dass der Client nur im Usermode läuft,
wie erwartet mit durchschnittlich etwa 2.5 % (Upstream) bzw. 5 % (Downstream) für
eine Linux-Netzwerkverbindung recht hoch aus, mit einem im Kernelmode laufenden
Treiber ließe sich in der Hinsicht die Verbindung noch optimieren.
Die Verbindungseinrichtung war im Grunde einfach und die Leistung ist hervorragend.
Für einen Linux-Nutzer bedeutet die Einrichtung einer DSL-Verbindung im Vergleich
zu Windows keinen größeren Aufwand, allerdings ist für den regulären Betrieb keine
grafische Benutzeroberfläche vorhanden. Für Statusmeldungen muss ein entsprechendes Script bemüht werden. Die sehr gute Upstream-Leistung bestätigt die Tauglichkeit
des gewählten Messaufbaus.
2
Mit top“ wurde die CPU-Belastung, welche durch den PPPoE-Prozess entstand, gemessen und
”
fällt durch diese Beschränkung etwas niedriger als bei den CPU-Cool-Messungen aus – direkte
Vergleichbarkeit ist damit nicht gewährleistet.
56
Teil V
Diskussion
57
Bewertung der Testergebnisse
Nach dem Test der PPPoE-Clients wird deutlich, dass Software eine Philosphie-Frage
ist. Es stellen sich zwei Konzepte heraus:
1. Der Typ des schlanken und schnellen Programms, das durch weitgehende Optimierung die Ressourcen optimal zu nutzen weiss, keinerlei Einschränkungen bei
den Optionen aufweist, aber eher schwierig zu installieren ist. Zu diesem Typ
können Roaring Penguin oder RASPPPOE gezählt werden.
2. Das Programm mit einfacher Installation, aufwendiger Benutzeroberfläche, umfangreicher Funktionalität sowie hohem Platzbedarf. Zu diesem Typ zählen Enternet oder cFos.
Bei diesen Konzepten stellt sich anschließend die Frage, welches dieser zwei Konzepte
für einen Netzbetreiber am interessantesten ist. Dazu müssen die Computerkenntnisse
der Kunden sowie deren Hardwareausstattung eingeschätzt – kurz: eine Zielgruppenanalyse durchgeführt werden. Ein Großteil der potentiellen Kunden werden den Computer eher als Arbeitsgerät mit einem gewissen Pragmatismus denn aus Begeisterung
benutzen. Damit ergeben sich gewisse Vorteile für die einfach zu installierenden Clients, die aber alle vergleichsweise großen Ressourcenbedarf aufweisen. Da die Rechner
über längere Zeiträume genutzt werden und dementsprechend teilweise veraltet sind
(siehe Abschnitt 5), sollten die Ressourcen sparsam benutzt werden – diese Kiterien
erfüllen eher die schwerer zu installierenden.
Die Entscheidung läuft dementsprechend auf einen Kompromiss hinaus. Dieser kann
gefunden werden, indem alle Kriterien gewichtet werden und mit einer Punktwertung
versucht wird, den besten Kompromiss zu finden. Folgende Entscheidungskriterien erscheinen sinnvoll: Preis und Lizensierungsmodell, einfache Installation und Bedienungsfreundlichkeit sowie Performance im Upstream / Downstream.
Preis und Lizensierungsmodell Envia.tel hat einen Bedarf von nur wenigen
PPPoE-Clients. Der Preis der jeweiligen Clients für etwa 100 Stück ergeben sich
wie folgt:
• CFos: 3323 EUR
• Enternet: 2940 EUR
• POETRI: 3700 EUR
• RASPPPOE: 995 EUR
• WinPOET: 3950 EUR
RASPPPOE stellt bei Abnahme von 100 Lizenzen mit unter 1000 EUR den
preiswertesten Client dar. Enternet bleibt als zweitbilligster Client unter 3000
EUR, alle anderen liegen z. T. deutlich darüber.
58
Flexible Lizensierungsmodelle sind bei cFos, POETRI und RASPPPOE möglich,
allerdings weisen die ersten beiden Clients einen hohen Grundpreis auf. Alle
anderen Clients ermöglichen lediglich eine Lizenzabnahme von einem oder 1000
Stück.
einfache Installation / Bedienungsfreundlichkeit Einfach zu installieren sind
Enternet, WinPOET und cFos – diese Clients erfordern lediglich wenige Angaben
oder Aktionen. cFos erleichtert durch seine deutsche Oberfläche die Installation
zusätzlich, von WinPOET ist wegen seiner unglücklich realisierten Deinstallationsprozedur abzuraten.
RASPPPOE sowie POETRI weisen eine mehrteilige Installation auf, die für Computerlaien schwieriger selbst durchzuführen ist. Nebenbei erhöht die schwierigere
Installation die Supportkosten, die durch den Netzbetreiber zu finanzieren sind.
RASPPPOE ist zudem für Windows 95 nicht geeignet.
Performance Upstream / Downstream Im Downstream unterscheiden sich die
Leistungen aller Clients nur marginal – bis auf WinPOET, dessen Datenrate bei
Windows 98 einbricht.
Im Upstream zeigt lediglich Enternet sowie, mit Abstrichen bei Windows NT,
RASPPPOE akzeptable Leistungen. cFOS erreicht bei Windows 95 und 98 Datenraten von lediglich 43 kByte/s sowie bei Windows ME und NT um 100 kByte/s und nutzt damit den 2,3 MBit-Anschluss nicht annähernd aus. POETRI
zeigt durchgehend schlechte Leistungen, die zudem sehr stark schwanken – dies
spricht nicht für einen verlässlichen Betrieb; WinPOET zeigt ebenfalls Schwankungen bei Windows ME und 95.
Bei Zusammenfassung der vorliegenden Ergebnisse ergibt sich folgendes Bild: Prinzipiell geeignet erscheint lediglich Enternet. Alle anderen Clients zeigen deutliche Schwächen in mindestens einem der Kriterien – besonders in der Leistungsbewertung zeigt
sich, dass die restlichen Clients für einen symmetrischen DSL-Anschluss nicht geeignet
sind. Bei WinPOET spricht zusätzlich die unbrauchbare Deinstallation sowie die aufgetretene Inkompatibilität gegen einen Einsatz, bei POETRI die Installation. Nachteilig
für RASPPPOE gestaltet sich die Tatsache, dass er nicht für Windows 95 tauglich ist
und damit für Kunden mit diesem Betriebssystem ein weiterer Client gefunden werden
müsste. Bei Berücksichtigung aller Kriterien stellt Enternet den besten Kompromiss
dar.
Problematisch ist dabei allerdings, wie bei jeder starren Bewertung, dass nur technische Kriterien bewertet werden können – für eine Firma spielen bei der Entscheidung
allerdings auch solche Aspekte eine Rolle, die ausserhalb jedes technischen Testspektrums liegen.
Ein weiches“ Entscheidungskriterium kann z. B. die Frage der Lizensierung sein. So
”
ist es für einen Netzbetreiber mit vergleichsweise kleinem potentiellen Kundenstamm
nicht akzeptabel, wenn eine Firma ihre Software lediglich in Tausenderlizenzen mit
59
Preisnachlass verkauft und dabei Geschäftsbedingungen stellt, die auf Offenbarung
der Kundendaten seitens envia.tel hinauslaufen. Genau das Gegenteil stellt die kleine
Software-Firma dar, die, über jede verkaufte Lizenz froh, auch bei kleinen Lizenzzahlen Preisnachlass gewährt und flexibel eine Nachlizensierung bietet. Letzteres erspart
dem Netzbetreiber, vorher viele Lizenzen zu ordern und nicht alle verkaufen zu können.
Alternative
Es stellt sich die Frage nach den Alternativen für PPPoE-Clients, die nach Testabschluss einen gewissen Risikofaktor für einen Netzbetreiber erkennen lassen. Ziel sollte
es sein, den SHDSL-Zugang möglichst effektiv auszunutzen und dem Kunden die Installation so einfach wie möglich machen zu können – am günstigsten wäre ein vom Betriebssystem und Rechnerkonfiguration unabhängiger Anschluss.
Zusätzlich bleibt das Problem, wie der Netzbetreiber den Anschluss eines LANs an den
DSL-Zugang handhaben kann – da die Zielstellung bei der Entwicklung von PPPoE die
Möglichkeit war, Authentifizierung und Abrechnung für einzelne Rechner durchzuführen, erfordert ein LAN einen Software-Router, auf dem der PPPoE-Client installiert
ist und mit dem alle Rechner eines LANs an das WAN angeschlossen werden können; vor allem mit einer Flatrate ist dies interessant. Diese Lösung wird sicherlich
häufig genutzt, was PPPoE-Software mit integrierter Routingfunktionalität beweist,
die Nachteile dieser Lösung liegen aber auf der Hand: Ein Rechner muss ständig angeschaltet sein sowie unter Windows laufen, da die Konfiguration eines Linuxrechners
den wenigsten Kunden zugemutet werden kann.
Da ein Softwarerouter aus vorgenannten Gründen ebenfalls keine Lösung ist, muss
die Zugangskontrolle eine Ebene weiter unten angesiedelt und damit dem IAD übertragen werden, der als Router die Rechner eines LANs an der Netzwerkverbindung
teilhaben lässt. Diese Lösung ist bei den verwendeten IADs von Siemens (Attane i210)
bereits in Form von PPPoA realisert. Diese Lösung hat für den Provider bestechende
Vorteile:
• kein PPPoE-Client nötig
• unabhängig von Rechnerkonfiguration und Betriebssystem
• keine Software-Installation nötig
• Wegfall der Lizensierungsproblematik
Aus diesen Überlegungen resultiert, dass PPPoA für mehrere Rechner eines LANs eine günstige Möglichkeit darstellt und die Entscheidung für einen PPPoE-Client nicht
getroffen werden muss. Müssen mehrere Rechner an einem Anschluss dennoch authentifiziert und abgerechnet werden, ist PPPoA keine Alternative und es muss auf
PPPoE-Clients zurückgegriffen werden.
60
Für diesen Zweck scheint der bereits dargestellte, beste Kompromiss Enternet von Efficient Networks zu sein. Der in der Einleitung angesprochenen weiteren Verbreitung der
breitbandigen Internet-Zugänge stellt dieser PPPoE-Client den wenigsten Widerstand
entgegen.
61
Teil VI
Anhang
62
A Grafiken
Name des getesteten PPPoE-Clients
Datenflussrichtung
Betriebssystem
J. Brenner, 2002/07/09
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
0
450
400
Zeit / s
CPU-Belastung (
)
Datenrate (
Abbildung A.1: Legende
63
)
Datenrate / kB/s
CPU-Belastung / %
cFos 4.13 / Downstream / Windows 2000
A Grafiken
J. Brenner, 2002/07/04
J. Brenner, 2002/07/04
Enternet 300 v1.5c SP2 / Downstream / Windows 95
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
CPU-Belastung / %
300
0
400
0
0
50
100
150
Zeit / s
200
250
300
350
J. Brenner, 2002/07/04
POETRI 1.9.11 / Downstream / Windows 95
RASPPPOE 0.98 / Downstream / Windows 95
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
50
100
150
200
250
300
350
CPU-Belastung / %
300
0
400
0
Zeit / s
0
50
100
150
200
250
300
350
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
0
400
Zeit / s
J. Brenner, 2002/07/04
0
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
0
400
Zeit / s
J. Brenner, 2002/07/04
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
Datenrate / kB/s
CPU-Belastung / %
WinPoET 2.51 / Downstream / Windows 95
0
400
Zeit / s
Abbildung A.2: Datenrate und CPU-Belastung / Downstream / Windows 95
64
A Grafiken
J. Brenner, 2002/07/05
J. Brenner, 2002/07/05
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/07/05
J. Brenner, 2002/07/05
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
J. Brenner, 2002/07/05
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
65
A Grafiken
J. Brenner, 2002/07/09
J. Brenner, 2002/07/09
Enternet 300 v1.5c SP2 / Downstream / Windows ME
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
J. Brenner, 2002/07/09
POETRI 1.9.11 / Downstream / Windows ME
RASPPPOE 0.98 / Downstream / Windows ME
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
0
400
350
Zeit / s
J. Brenner, 2002/07/09
0
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
cFos 4.13 / Downstream / Windows ME
0
450
Zeit / s
J. Brenner, 2002/07/09
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
WinPoET 2.51 / Downstream / Windows ME
0
450
Zeit / s
Abbildung A.4: Datenrate und CPU-Belastung / Downstream / Windows ME
66
A Grafiken
J. Brenner, 2002/07/08
J. Brenner, 2002/07/08
Enternet 300 v1.5c SP2 / Downstream / Windows NT 4.0
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/07/08
J. Brenner, 2002/07/08
POETRI 1.9.11 / Downstream / Windows NT 4.0
RASPPPOE 0.98 / Downstream / Windows NT 4.0
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
cFos 4.13 / Downstream / Windows NT 4.0
0
450
Zeit / s
J. Brenner, 2002/07/08
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
WinPoET 2.51 / Downstream / Windows NT 4.0
0
450
Zeit / s
Abbildung A.5: Datenrate und CPU-Belastung / Downstream / Windows NT
67
A Grafiken
J. Brenner, 2002/07/09
J. Brenner, 2002/07/09
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
250
Zeit / s
300
350
400
0
500
Zeit / s
J. Brenner, 2002/07/09
J. Brenner, 2002/07/09
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
450
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
J. Brenner, 2002/07/09
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
68
A Grafiken
J. Brenner, 2002/07/04
J. Brenner, 2002/07/04
Enternet 300 v1.5c SP2 / Upstream / Windows 95
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/07/04
J. Brenner, 2002/07/04
POETRI 1.9.11 / Upstream / Windows 95
RASPPPOE 0.98 / Upstream / Windows 95
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
cFos 4.13 / Upstream / Windows 95
0
450
Zeit / s
J. Brenner, 2002/07/04
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
WinPoET 2.51 / Upstream / Windows 95
0
450
Zeit / s
Abbildung A.7: Datenrate und CPU-Belastung / Upstream / Windows 95
69
A Grafiken
J. Brenner, 2002/07/05
J. Brenner, 2002/07/05
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/07/05
J. Brenner, 2002/07/05
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
J. Brenner, 2002/07/05
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
70
A Grafiken
J. Brenner, 2002/07/09
J. Brenner, 2002/07/09
Enternet 300 v1.5c SP2 / Upstream / Windows ME
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/07/09
J. Brenner, 2002/07/09
POETRI 1.9.11 / Upstream / Windows ME
RASPPPOE 0.98 / Upstream / Windows ME
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
cFos 4.13 / Upstream / Windows ME
0
450
Zeit / s
J. Brenner, 2002/07/09
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
WinPoET 2.51 / Upstream / Windows ME
0
450
Zeit / s
Abbildung A.9: Datenrate und CPU-Belastung / Upstream / Windows ME
71
A Grafiken
J. Brenner, 2002/07/08
J. Brenner, 2002/07/08
Enternet 300 v1.5c SP2 / Upstream / Windows NT 4.0
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/07/08
J. Brenner, 2002/07/08
POETRI 1.9.11 / Upstream / Windows NT 4.0
RASPPPOE 0.98 / Upstream / Windows NT 4.0
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
cFos 4.13 / Upstream / Windows NT 4.0
0
450
Zeit / s
Abbildung A.10: Datenrate und CPU-Belastung / Upstream / Windows NT
72
A Grafiken
J. Brenner, 2002/07/09
J. Brenner, 2002/07/09
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/07/09
J. Brenner, 2002/07/09
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
J. Brenner, 2002/07/09
30
300
25
250
20
200
15
150
10
100
5
50
0
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
CPU-Belastung / %
0
450
Zeit / s
73
A Grafiken
J. Brenner, 2002/08/07
J. Brenner, 2002/08/07
Windows XP nativ / Downstream / Windows XP
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
0
50
100
150
200
Zeit / s
250
300
350
0
450
Zeit / s
J. Brenner, 2002/08/07
J. Brenner, 2002/08/07
Roaring Penguin / Upstream / SuSE Linux 7.1
Roaring Penguin / Downstream / SuSE Linux 7.1
30
300
25
250
25
250
20
200
20
200
15
150
15
150
10
100
10
100
5
50
5
50
0
0
50
100
150
200
250
300
350
400
CPU-Belastung / %
300
0
450
0
Zeit / s
0
50
100
150
200
250
300
350
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
400
Datenrate / kB/s
30
Datenrate / kB/s
CPU-Belastung / %
Windows XP nativ / Upstream / Windows XP
0
450
Zeit / s
Abbildung A.12: Datenrate und CPU-Belastung / Upstream u. Downstream / Windows XP und SuSE-Linux 7.1
74
B Testprotokoll
75
B Testprotokoll
PPPoE-Clients
cFOS DSL OEM
allg. Angaben
Version
Hersteller
Bezugsquelle
unterstützte Betriebssysteme
Enternet 300 Win
4.13 (Build 2361)
cFos Software
www.cfos.de
POETRI
1.5c SP2
Efficient Networks
www.efficient.com/products/enternet.html
1.9.11 deutsch
Hanewinkel Softwareentwicklung
www.hanewin.de
j/j/j
j/j/j
n
j/j/j
j /j/j
n
56,75 EUR
33,23 EUR
28,02 EUR
-
29,4 EUR
9 EUR
59 EUR
37 EUR
31 EUR
25 EUR
19 EUR
n
n
n
Skins, Zeitsynchronisation
j /deutsch
n
n
n
j /englisch
n
j
j
DNS-Umlenkung
j /deutsch
z.T.
InstallShield, Enternet
deutsch (InstallShield), englisch (Enternet)
j
Inno Setup
deutsch
95 / 98(SE) / ME j / j / j
NT 4.0 / 2000 / XP j / j / j
Linux n
Preis
Einzellizenz
100 Lizenzen
250 Lizenzen
500 Lizenzen
1000 Lizenzen
Zusatzfunktionen, -optionen
AC-Serverdienst
Firewall
Routing/IP-Masquerading
weiteres
Dokumentation / Sprache
Installer
vorhanden j
Typ cFOS
Sprache deutsch
LAN-Emulation n
Protokoll n
Modem-Emulation j
j
n
n
Anzahl 0
Bezeichnung der Aktionen -
1
Wahl zw. Quick-Install u. Step-by-Step (Quick)
1
manuelle Einrichtung PPPoE-Adapter
Benutzername/Kennwort j (n/a) / j (n/a)
n
Name DFÜ-Verbindung j (n/a)
n
Zielverzeichnis n
n
Startmenügruppe n
n
Name Dienstanbieter n
n
Neustarts Installation / Deinstallation
Installation 0, 1 (NT)
1
Deinstallation 0
1
5
7
Bemerkungen
Frontend
Typ cFOS
Enternet
Sprache deutsch
englisch
Benutzername/Kennwort j / j
j/j
Name (DFÜ-)Verbindung j
j (nicht DFÜ)
Auswahl Netzwerkkarte n
j
weiteres weiteres weiteres Verbindungsoptionen
TCP/IP-Konfiguration 1) j
j
Idle Timeout 0min...23h n
j
Netzwerkanmeldung j
j
Protokollaufzeichnung aktivieren (NDISLOG) j
n
Auswahl Netzwerkkarte n
j
Wahl Verschlüsselung j (Kennwort/Daten)
j
Auswahl Server / Service n
j
PPP-Konfiguration 2) n
n
Route bei Verbindung nicht verändern n
j
TCP/IP-Konfiguration 1) n
n
Verbindungsprotokoll verwenden n
n
Netzwerkanmeldung n
n
MSS begrenzen n
n
MTU ändern n
n
regulärer Betrieb
Interface
Typ cFOS, Standard-DFÜ-Verbindung
Enternet
Sprache deutsch/englisch, deutsch
englisch
Konfiguration Verbindungsverhalten
selbständige Verbindungsaufnahme bei BS-Start j
j
selbständige Verbindungsaufnahme bei Programmstart n
j
Dial-on-Demand j
n
selbständige Leerlauftrennung / einstellbar j / j
j / j (5min-23h)
Wiederwahl bei Verbindungsabbruch n
j
Sound / Browser-Start bei Verbindungsaufbau n
j
Wahlwiederholung j
n
Daten- und Gebührenbudget pro Monat j
n
Begrenzung Upstreamgeschwindigkeit n
n
protokollierte Standard-Informationen
Datenvolumen / Zeitintervall j / Monat, Verbindung
j / Verbindung
Online-Zeit / Zeitintervall j / Monat, Verbindung
j / Verbindung
Gebühren / Zeitintervall j (Generierung von Gebührenimpulsen) / Verbindung
n
Logfile
möglich? j
j
Zeit Verbindungsaufbau/-abbruch j
j
Session-Statistik: read/write bytes j
n
Ethernet-Frames n
j
AT-Befehle j
n
1) IP-Adresse, DNS-Adressen, IP-Headerkomprimierung, Standard-Gateway benutzen
2) LCP-Erweiterungen aktivieren, Softwarekomprimierung aktivieren, Mehrfachverbindungen für Einzelverbindungen aushandeln
j
n
j (c:\programme\poetri)
j ((PPPoE IP Routing Interface)
n
1 (95/98/ME/NT), 0 (2k)
0
3
Win 2k: ohne Neustart wird NIC nicht gefunden
POETRI
deutsch
j/j
n
n
Ändern Verbindungstyp auf DSL
n
j
n
n
j
j
n
n
j
n
n
n
j (automatisch)
n
POETRI
deutsch/englisch
j
j
j
j /j
n
j
j
j
j
j / Verbindung, gesamt
j / Verbindung
j / Verbindung, Monat
j
n
n
n
n
Abbildung B.1: Testprotokoll – Allgemeiner Teil I
76
B Testprotokoll
PPPoE-Clients
RASPPPOE
allg. Angaben
Version
Hersteller
Bezugsquelle
unterstützte Betriebssysteme
0.98
Monzoon Networks AG
http://user.cs.tu-berlin.de/~normanb/
WinPOET
Roaring Penguin
Windows XP nativ
2.51
Finepoint Technologies
www.finepoint.com
Roaring Penguin Software
www.roaringpenguin.com/pppoe/
Microsoft
-
j/j/j
j/j/n
n
n/n/n
n/n/n
j
n/n/n
n/n/j
n
23,95
9,95
6,95
2,5
39,5 EUR
8.5 EUR
7.13 EUR
0
0
0
0
0
-
j
n
n
j / englisch
n
n
n
j / englisch
j
j
j
j / englisch
n
j
j
j / deutsch
j
InstallShield
englisch
j
SuSE-Kontrollzentrum
deutsch
j
Internet-Verbindungs-Assistent
deutsch
j
n
n
n
j
n
WAN-Miniport
n
n
1
Modem hinzufügen (NT)
1
Paketinstallation über YaST
2
Internet-Assistent aufrufen
Wahl Breitbandverbindung
95 / 98(SE) / ME n / j / j
NT 4.0 / 2000 / XP j / j / j
Linux n
Preis
Einzellizenz
100 Lizenzen
250 Lizenzen
500 Lizenzen
1000 Lizenzen
Zusatzfunktionen, -optionen
AC-Serverdienst
Firewall
Routing/IP-Masquerading
weiteres
Dokumentation / Sprache
Installer
vorhanden z.T.
Typ RASPPPOE
Sprache englisch
LAN-Emulation n
Protokoll j
Modem-Emulation n
Anzahl 3
Bezeichnung der Aktionen PPPoE-Protokoll installieren,
Auswahl AC
Erstellung DFÜ-Verbindung
Benutzername/Kennwort j
n
n
Name DFÜ-Verbindung n
n
n
Zielverzeichnis n
j (/programme/ivasion/winpoet)
n
Startmenügruppe n
n
n
Name Dienstanbieter n
n
n
Neustarts Installation / Deinstallation
Installation 1
1 (95(98/ME/NT), 0 (2k)
0
Deinstallation 1
1
0
2,5
6
0.2
Bemerkungen
benötigt MS DUN 1.3 unter Win95
Frontend
Typ RASPPPOE-Frontend
WinPOET
PPPoE-Script
Sprache englisch
englisch
englisch
Benutzername/Kennwort j / j
n
j ([email protected]/na) / j
Name (DFÜ-)Verbindung n
n
n
Auswahl Netzwerkkarte j
n
j (Ethernet-Interface eth1)
weiteres Auswahl AC
Zielverzeichnis (programme/ivasion/winpoet)
Firewall wählen
weiteres Verbindungsverhalten
weiteres DNS-Adressen (vom Server holen)
Verbindungsoptionen
n
n
Idle Timeout 0min...23h Netzwerkanmeldung
n
n
Netzwerkanmeldung j
n
n
Protokollaufzeichnung aktivieren (NDISLOG) j
n
n
Auswahl Netzwerkkarte j
n
n
Wahl Verschlüsselung j (Kennwort/Daten)
n
n
Auswahl Server / Service n
n
n
PPP-Konfiguration 2) n
n
n
Route bei Verbindung nicht verändern n
n
n
n
n
Verbindungsprotokoll verwenden j
n
n
Netzwerkanmeldung j
n
n
MSS begrenzen j
n
n
MTU ändern j
n
n
regulärer Betrieb
Interface
Typ RASPPPOE, Standard-DFÜ-Verbindung WinPOET, Standard-DFÜ-Verbindung
Sprache englisch / deutsch
englisch / deutsch
Konfiguration Verbindungsverhalten
selbständige Verbindungsaufnahme bei BS-Start j
j
j
selbständige Verbindungsaufnahme bei Programmstart n
n
n
Dial-on-Demand j
j
j
selbständige Leerlauftrennung / einstellbar j / j
j/j
j / j (frei in Sekunden)
Wiederwahl bei Verbindungsabbruch j
j
n
Sound / Browser-Start bei Verbindungsaufbau n
n
n
Wahlwiederholung j
j
n
Daten- und Gebührenbudget pro Monat n
n
n
Begrenzung Upstreamgeschwindigkeit n
n
n
protokollierte Standard-Informationen
Datenvolumen / Zeitintervall j / Verbindung
j / Verbindung
n
Online-Zeit / Zeitintervall j / Verbindung
j / Verbindung
n
Gebühren / Zeitintervall n
n
n
Logfile
möglich? j
j
n
Zeit Verbindungsaufbau/-abbruch j
j
n
Session-Statistik: read/write bytes j
j
n
Ethernet-Frames n
n
n
AT-Befehle n
n
n
1) IP-Adresse, DNS-Adressen, IP-Headerkomprimierung, Standard-Gateway
benutzen
1) IP-Adresse, DNS-Adressen,
IP-Headerkomprimierung, Standard-Gateway benutzen
2) LCP-Erweiterungen aktivieren, Softwarekomprimierung aktivieren,
Mehrfachverbindungen
Einzelverbindungen aushandeln
2) LCP-Erweiterungen
aktivieren,fürSoftwarekomprimierung
aktivieren, Mehrfachverbindungen für Einzelverbindungen aushandeln
Abbildung B.2: Testprotokoll – Allgemeiner Teil II
77
j/j
n
n
n
j
0
0
-
j/j
j
n
j
j
n
n
n
j (PAP, CHAP, SPAP, MS-CHAP)
n
j
n
n
n
n
n
n
Windows XP
deutsch
j
n
j
j (1min-24h)
j
n
n
n
n
j / Verbindung
j / Verbindung
n
n
n
n
n
n
PPPoE-Clients
Performance Downstream
1k
231
229
229
227
231
min 227
max 231
avg 229
78
Linux Datendurchsatz / kB/s
Abbildung B.3: Testprotokoll – Performance Downstream
min
max
avg
Paketgrösse
min
max
avg
Windows XP Datendurchsatz / kB/s
Paketgrösse
1k
-
1k
-
1k
231
231
208
231
230
min 208
max 231
avg 226
Windows 2000 Datendurchsatz / kB/s
Paketgrösse
1k
189
164
181
159
148
min 148
max 189
avg 168
Windows NT4.0 Datendurchsatz / kB/s
Paketgrösse
1k
236
236
236
236
236
min 236
max 236
avg 236
Windows ME Datendurchsatz / kB/s
Paketgrösse
1k
231
231
230
231
231
min 230
max 231
avg 231
Paketgrösse
Paketgrösse
2k
-
2k
-
2k
231
231
231
231
228
228
231
230
2k
230
209
228
226
231
209
231
225
2k
236
236
236
236
236
236
236
236
2k
231
231
230
231
231
230
231
231
2k
231
231
231
230
231
230
231
231
4k
-
4k
-
4k
242
242
239
239
240
239
242
240
4k
227
233
229
233
226
226
233
230
4k
237
237
236
237
237
236
237
237
4k
240
240
240
239
240
239
240
240
4k
240
239
239
238
239
238
240
239
8k
-
8k
-
8k
243
243
240
240
240
240
243
241
8k
231
231
234
237
237
231
237
234
8k
239
243
238
240
239
238
243
240
8k
242
242
242
240
242
240
242
242
8k
243
240
240
240
238
238
243
240
16k
-
16k
-
16k
245
245
242
242
242
242
245
243
16k
238
239
238
238
233
233
239
237
16k
243
244
239
244
244
239
244
243
16k
244
244
244
242
244
242
244
244
16k
245
242
242
242
240
240
245
242
cFOS DSL OEM
32k
-
32k
-
32k
249
249
244
244
244
244
249
246
32k
241
229
230
226
241
226
241
233
32k
245
249
241
247
247
241
249
246
32k
247
247
247
244
247
244
247
246
32k
249
244
244
244
242
242
249
245
1k
-
1k
-
1k
231
231
231
231
231
231
231
231
1k
231
231
229
228
231
228
231
230
1k
231
231
231
231
231
231
231
231
1k
231
231
231
231
231
231
231
231
1k
231
231
231
231
231
231
231
231
2k
-
2k
-
2k
231
231
231
231
231
231
231
231
2k
231
231
231
231
230
230
231
231
2k
231
231
231
231
231
231
231
231
2k
231
231
231
231
231
231
231
231
2k
231
231
231
231
231
231
231
231
4k
-
4k
-
4k
235
235
236
235
235
235
236
235
4k
234
235
235
233
235
233
235
234
4k
235
235
235
235
235
235
235
235
4k
235
235
235
235
222
222
235
232
4k
234
234
235
233
235
233
235
234
8k
-
8k
-
8k
237
236
236
237
237
236
237
237
8k
233
236
236
235
236
233
236
235
8k
236
236
236
236
236
236
236
236
8k
236
236
236
236
235
235
236
236
8k
235
235
236
235
236
235
236
235
16k
-
16k
-
16k
238
238
239
238
238
238
239
238
16k
235
238
238
236
237
235
238
237
16k
237
238
238
238
238
237
238
238
16k
238
238
238
238
236
236
238
238
16k
236
236
238
236
239
236
239
237
Enternet 300 Win
32k
-
32k
-
32k
243
243
242
243
243
242
243
243
32k
237
241
241
237
239
237
241
239
32k
241
241
241
243
241
241
243
241
32k
241
241
242
241
237
237
242
240
32k
238
237
241
237
242
237
242
239
1k
-
1k
-
1k
228
185
185
185
185
185
228
194
1k
164
168
147
157
182
147
182
164
1k
161
161
186
145
123
123
186
155
1k
153
137
125
123
112
112
153
130
1k
171
164
170
155
177
155
177
167
2k
-
2k
-
2k
231
231
231
231
231
231
231
231
2k
219
212
228
227
196
196
228
216
2k
161
221
213
209
223
161
223
205
2k
217
214
220
224
212
212
224
217
2k
229
229
229
225
226
225
229
228
4k
-
4k
-
4k
238
238
237
238
238
237
238
238
4k
223
227
228
229
229
223
229
227
4k
205
227
203
219
224
203
227
216
4k
226
222
218
224
223
218
226
223
4k
233
235
230
229
234
229
235
232
8k
-
8k
-
8k
240
236
239
240
239
236
240
239
8k
216
227
232
228
223
216
232
225
8k
232
227
227
232
230
227
232
230
8k
229
216
232
234
233
216
234
229
8k
235
236
234
233
233
233
236
234
POETRI
16k
-
16k
-
16k
241
238
240
241
242
238
242
240
16k
231
234
236
225
236
225
236
232
16k
234
234
235
234
233
233
235
234
16k
233
221
230
224
222
221
233
226
16k
234
237
235
235
236
234
237
235
32k
-
32k
-
32k
246
239
244
246
246
239
246
244
32k
228
234
236
239
235
228
239
234
32k
237
238
237
239
238
237
239
238
32k
229
235
231
228
226
226
235
230
32k
239
239
238
238
238
238
239
238
1k
-
1k
-
1k
231
215
231
232
231
215
232
228
1k
170
160
122
159
147
122
170
152
1k
236
221
236
236
236
221
236
233
1k
231
231
231
231
231
231
231
231
1k
-
2k
-
2k
-
2k
231
225
231
230
231
225
231
230
2k
227
226
224
226
227
224
227
226
2k
236
236
236
236
236
236
236
236
2k
231
231
231
231
231
231
231
231
2k
-
4k
-
4k
-
4k
242
237
242
240
242
237
242
241
4k
235
237
234
236
219
219
237
232
4k
241
241
237
241
238
237
241
240
4k
240
239
240
240
240
239
240
240
4k
-
8k
-
8k
-
8k
242
240
243
242
243
240
243
242
8k
236
239
236
235
237
235
239
237
8k
243
243
242
243
242
242
243
243
8k
243
242
243
243
243
242
243
243
8k
-
16k
-
16k
-
16k
244
242
245
244
245
242
245
244
16k
239
238
235
238
239
235
239
238
16k
245
245
243
245
244
243
245
244
16k
245
244
245
245
245
244
245
245
16k
-
RASPPPOE
32k
-
32k
-
32k
247
244
249
247
249
244
249
247
32k
241
237
242
241
239
237
242
240
32k
249
249
245
249
247
245
249
248
32k
249
247
249
249
249
247
249
249
32k
-
1k
-
1k
-
1k
231
231
231
231
231
231
231
231
1k
163
167
139
171
151
139
171
158
1k
231
231
231
231
231
231
231
231
1k
214
212
216
212
182
182
216
207
1k
231
221
231
231
232
221
232
229
2k
-
2k
-
2k
231
231
231
231
231
231
231
231
2k
228
216
227
225
229
216
229
225
2k
231
231
231
231
231
231
231
231
2k
220
231
231
231
208
208
231
224
2k
231
231
231
231
231
231
231
231
4k
-
4k
-
4k
236
236
236
236
236
236
236
236
4k
234
236
228
237
237
228
237
234
4k
230
229
229
229
230
229
230
229
4k
222
222
234
224
234
222
234
227
4k
237
237
237
237
237
237
237
237
8k
-
8k
-
8k
238
237
238
238
238
237
238
238
8k
238
235
233
234
235
233
238
235
8k
236
231
231
232
225
225
236
231
8k
234
209
234
234
234
209
234
229
8k
238
237
236
238
238
236
238
237
WinPoET
16k
-
16k
-
16k
239
239
240
239
239
239
240
239
16k
238
238
226
239
237
226
239
236
16k
238
234
234
235
234
234
238
235
16k
196
194
199
190
183
183
199
192
16k
240
239
238
240
240
238
240
239
32k
-
32k
-
32k
243
242
243
243
243
242
243
243
32k
242
225
240
239
233
225
242
236
32k
242
235
235
237
235
235
242
237
32k
164
154
166
153
171
153
171
162
32k
244
242
241
244
244
241
244
243
1k
-
1k
216
166
217
187
230
166
230
203
1k
-
1k
-
1k
-
1k
-
1k
-
2k
-
2k
230
227
224
224
228
224
230
227
2k
-
2k
-
2k
-
2k
-
2k
-
4k
-
4k
233
235
221
233
228
221
235
230
4k
-
4k
-
4k
-
4k
-
4k
-
8k
-
8k
236
231
235
226
234
226
236
232
8k
-
8k
-
8k
-
8k
-
8k
-
16k
-
16k
238
239
238
234
235
234
239
237
16k
-
16k
-
16k
-
16k
-
16k
-
Windows XP nativ
32k
-
32k
240
240
237
238
238
237
240
239
32k
-
32k
-
32k
-
32k
-
32k
-
1k
224
221
220
212
210
210
224
217
1k
-
1k
-
1k
-
1k
-
1k
-
1k
-
2k
229
231
230
230
230
229
231
230
2k
-
2k
-
2k
-
2k
-
2k
-
2k
-
4k
233
234
234
234
234
233
234
234
4k
-
4k
-
4k
-
4k
-
4k
-
4k
-
8k
233
232
233
233
233
232
233
233
8k
-
8k
-
8k
-
8k
-
8k
-
8k
-
16k
235
234
234
234
235
234
235
234
16k
-
16k
-
16k
-
16k
-
16k
-
16k
-
Roaring Penguin
32k
235
236
236
236
235
235
236
236
32k
-
32k
-
32k
-
32k
-
32k
-
32k
-
B Testprotokoll
PPPoE-Clients
Performance Upstream
1k
43,4
44
43,3
43,2
43,7
min 43,2
max 44
avg 43,5
79
Linux Datendurchsatz / kB/s
Abbildung B.4: Testprotokoll – Performance Upstream
min
max
avg
Paketgrösse
min
max
avg
Windows XP Datendurchsatz / kB/s
Paketgrösse
1k
-
1k
-
1k
112
90,8
94,1
92,2
90,4
min 90,4
max 112
avg 95,9
Paketgrösse
1k
83,4
90,2
74,8
79,9
79,8
min 74,8
max 90,2
avg 81,6
Windows NT4.0 Datendurchsatz / kB/s
Paketgrösse
1k
17,2
17,1
17,5
16,5
19,1
min 16,5
max 19,1
avg 17,5
Windows ME Datendurchsatz / kB/s
Paketgrösse
1k
45
44,3
43,4
44,7
44,4
min 43,4
max 45
avg 44,4
Paketgrösse
Paketgrösse
2k
-
2k
-
2k
217
229
186
191
205
186
229
206
2k
105
95
91,6
68
90,2
68
105
89,9
2k
17,2
29,7
28,1
28,5
29,1
17,2
29,7
26,6
2k
42
42,8
43
42,9
42,4
42
43
42,6
2k
43,3
42,7
42,7
41,8
43
41,8
43,3
42,7
4k
-
4k
-
4k
238
238
239
238
238
238
239
238
4k
121
107
96,7
105
94,6
94,6
121
105
4k
56,1
51,9
55,2
52
51,8
51,8
56,1
53,4
4k
41,6
42,8
43,2
42,3
43,2
41,6
43,2
42,6
4k
42,7
43
43,4
41,9
43
41,9
43,4
42,8
8k
-
8k
-
8k
239
240
240
238
239
238
240
239
8k
108
110
129
123
125
108
129
119
8k
78,3
67,7
68,6
68,3
65,9
65,9
78,3
69,8
8k
43,1
42,9
42,4
42,1
43,1
42,1
43,1
42,7
8k
43
42,5
43,4
42,8
42,5
42,5
43,4
42,8
16k
-
16k
-
16k
240
237
243
239
240
237
243
240
16k
138
130
130
121
132
121
138
130
16k
102
104
105
101
99
99
105
102
16k
41,7
42,9
43
43,6
42,9
41,7
43,6
42,8
16k
44,1
43,6
40,6
43,1
43,7
40,6
44,1
43
cFOS DSL OEM
32k
-
32k
-
32k
242
243
228
242
242
228
243
239
32k
121
129
130
130
133
121
133
129
32k
104
104
104
105
109
104
109
105
32k
35,7
37,9
37,5
37,2
37,4
35,7
37,9
37,1
32k
36,4
37,7
36,7
37
36,9
36,4
37,7
37
1k
-
1k
-
1k
176
198
177
182
117
117
198
170
1k
179
155
213
162
180
155
213
178
1k
169
156
164
140
164
140
169
159
1k
183
145
211
209
169
145
211
183
1k
221
206
198
208
210
198
221
209
2k
-
2k
-
2k
232
213
232
209
150
150
232
207
2k
231
230
231
226
213
213
231
226
2k
169
229
231
232
231
169
232
218
2k
190
184
216
216
210
184
216
203
2k
220
213
191
204
220
191
220
210
4k
-
4k
-
4k
234
234
219
234
163
163
234
217
4k
234
234
234
206
234
206
234
228
4k
233
234
234
233
233
233
234
233
4k
233
220
210
234
233
210
234
226
4k
234
223
220
234
234
220
234
229
8k
-
8k
-
8k
235
201
218
211
234
201
235
220
8k
218
235
235
235
235
218
235
232
8k
234
234
234
234
234
234
234
234
8k
222
205
234
233
185
185
234
216
8k
213
234
234
207
234
207
234
224
16k
-
16k
-
16k
238
219
215
233
220
215
238
225
16k
226
238
238
224
238
224
238
233
16k
177
180
178
183
183
177
183
180
16k
201
156
199
199
196
156
201
190
16k
189
178
210
196
197
178
210
194
Enternet 300 Win
32k
-
32k
-
32k
241
236
195
236
236
195
241
229
32k
236
241
241
236
241
236
241
239
32k
217
217
216
212
217
212
217
216
32k
221
175
213
212
221
175
221
208
32k
221
221
221
221
208
208
221
218
1k
-
1k
-
1k
15
13,5
8,57
9,62
12,4
8,57
15
11,8
1k
66,7
48,3
64,5
53,9
60
48,3
66,7
58,7
1k
68,8
57,1
56,4
70,9
69,3
56,4
70,9
64,5
1k
64,3
53,7
63,5
55,8
60,8
53,7
64,3
59,6
1k
64,3
57,8
55,9
69,2
69,4
55,9
69,4
63,3
2k
-
2k
-
2k
12,1
12,1
9,79
9,47
11,2
9,47
12,1
10,9
2k
88
72,4
63,7
64,3
60,8
60,8
88
69,9
2k
68,8
54,9
68,9
63,7
72,7
54,9
72,7
65,8
2k
64
73
64,3
71,5
76,6
64
76,6
69,9
2k
67,1
75,5
71,6
78,6
59,3
59,3
78,6
70,4
4k
-
4k
-
4k
13,2
12,2
10,4
11,4
12
10,4
13,2
11,8
4k
94,1
132
93,6
82,6
138
82,6
138
108
4k
111
108
147
156
162
108
162
137
4k
100
98,6
141
137
142
98,6
142
124
4k
146
140
142
146
130
130
146
141
8k
-
8k
-
8k
15,1
10,5
10,3
13,6
12,8
10,3
15,1
12,5
8k
124
147
145
150
154
124
154
144
8k
152
163
141
163
132
132
163
150
8k
90,9
90,9
145
157
81,6
81,6
157
113
8k
146
146
146
146
80,2
80,2
146
133
POETRI
16k
-
16k
-
16k
15,3
89,5
12,6
87,9
14,4
12,6
89,5
43,9
16k
88,4
94
102
100
109
88,4
109
98,7
16k
148
66,3
65,3
145
147
65,3
148
114
16k
52,9
120
55,9
50,4
57,1
50,4
120
67,3
16k
136
136
132
49
48
48
136
100
32k
-
32k
-
32k
16,4
241
13,5
244
16,1
13,5
244
106
32k
94,6
113
114
114
112
94,6
114
110
32k
77,3
68,9
76,9
67,6
80,6
67,6
80,6
74,3
32k
63,8
61,3
73,7
69,1
73,2
61,3
73,7
68,2
32k
63,4
76
65,3
68
73,2
63,4
76
69,2
1k
-
1k
-
1k
114
120
98,3
103
116
98,3
120
110
1k
73,1
81,3
82,5
74,8
70,5
70,5
82,5
76,4
1k
220
236
177
236
236
177
236
221
1k
138
116
115
140
120
115
140
126
1k
120
98
131
103
97,8
97,8
131
110
2k
-
2k
-
2k
225
231
232
225
232
225
232
229
2k
77,7
88,7
92,4
83,2
84,3
77,7
92,4
85,3
2k
220
236
236
236
236
220
236
233
2k
231
232
231
232
224
224
232
230
2k
231
224
231
231
230
224
231
229
4k
-
4k
-
4k
239
239
239
239
239
239
239
239
4k
147
148
154
150
148
147
154
149
4k
236
236
236
236
236
236
236
236
4k
239
239
239
239
239
239
239
239
4k
239
239
239
239
239
239
239
239
8k
-
8k
-
8k
240
240
240
240
240
240
240
240
8k
140
149
141
149
149
140
149
146
8k
238
237
238
238
238
237
238
238
8k
239
239
239
239
239
239
239
239
8k
239
239
239
239
239
239
239
239
16k
-
16k
-
16k
244
244
244
244
244
244
244
244
16k
149
151
149
154
158
149
158
152
16k
211
202
211
198
210
198
211
206
16k
204
202
214
194
204
194
214
204
16k
202
203
203
205
205
202
205
204
RASPPPOE
32k
-
32k
-
32k
247
247
247
247
247
247
247
247
32k
154
155
154
156
153
153
156
154
32k
224
213
224
224
224
213
224
222
32k
97
97
94,6
98
95,8
94,6
98
96,5
32k
98
98
97
99
97
97
99
97,8
1k
-
1k
-
1k
167
158
168
170
149
149
170
162
1k
-
1k
231
219
231
231
231
219
231
229
1k
231
231
231
231
232
231
232
231
1k
133
184
185
177
201
133
201
176
2k
-
2k
-
2k
217
231
231
231
206
206
231
223
2k
-
2k
231
231
231
231
231
231
231
231
2k
231
231
231
231
231
231
231
231
2k
201
191
231
231
231
191
231
217
4k
-
4k
-
4k
237
237
237
235
235
235
237
236
4k
-
4k
229
229
229
229
229
229
229
229
4k
235
235
234
235
234
234
235
235
4k
212
214
236
236
236
212
236
227
8k
-
8k
-
8k
237
237
237
235
234
234
237
236
8k
-
8k
231
231
231
231
231
231
231
231
8k
236
236
235
236
235
235
236
236
8k
192
235
235
235
235
192
235
226
WinPoET
16k
-
16k
-
16k
239
239
239
222
235
222
239
235
16k
-
16k
32,3
31,6
31,3
30,6
31,9
30,6
32,3
31,5
16k
238
238
236
238
237
236
238
237
16k
183
163
207
197
197
163
207
189
32k
-
32k
-
32k
221
242
242
226
236
221
242
233
32k
-
32k
111
111
111
113
113
111
113
112
32k
241
243
237
241
239
237
243
240
32k
171
160
169
166
168
160
171
167
1k
-
1k
216
62,6
42,1
54,5
67,3
42,1
216
88,5
1k
-
1k
-
1k
-
1k
-
1k
-
2k
-
2k
51
65,7
71,7
54,6
69,5
51
71,7
62,5
2k
-
2k
-
2k
-
2k
-
2k
-
4k
-
4k
99,3
71,8
103
89,3
87,3
71,8
103
90,1
4k
-
4k
-
4k
-
4k
-
4k
-
8k
-
8k
83,9
102
71,2
85,1
71,2
71,2
102
82,7
8k
-
8k
-
8k
-
8k
-
8k
-
16k
-
16k
66,5
70,3
68,3
71,7
61,5
61,5
71,7
67,6
16k
-
16k
-
16k
-
16k
-
16k
-
Windows XP nativ
32k
-
32k
118
95
85
80,6
95,4
80,6
118
94,8
32k
-
32k
-
32k
-
32k
-
32k
-
1k
239
239
239
239
239
239
239
239
1k
-
1k
-
1k
-
1k
-
1k
-
1k
-
2k
234
234
234
234
234
234
234
234
2k
-
2k
-
2k
-
2k
-
2k
-
2k
-
4k
234
234
234
234
234
234
234
234
4k
-
4k
-
4k
-
4k
-
4k
-
4k
-
8k
234
225
234
234
234
225
234
232
8k
-
8k
-
8k
-
8k
-
8k
-
8k
-
16k
235
235
235
235
235
235
235
235
16k
-
16k
-
16k
-
16k
-
16k
-
16k
-
Roaring Penguin
32k
237
237
237
237
237
237
237
237
32k
-
32k
-
32k
-
32k
-
32k
-
32k
-
B Testprotokoll
Client-PC
Hardware
System
Systemhersteller
Hewlett-Packard
Systemmodell
HP Vectra
Systemtyp
X86-basierter PC
Prozessor
x86 Family 6 Model 8 Stepping 3 GenuineIntel 6̃51 MHz
BIOS-Version
Award Modular BIOS v6.00PG
System-BIOS-Datum
10/19/99
Gesamter phys. Speicher
130420 KB
Grafikkarte
Video-BIOS
VGA/VBE BIOS, Version V1.7 Revision: 0.16
Video BIOS-Datum
12/23/98
Grafikkartentyp
Matrox Graphics G200 AGP
Grafikkartestring
Matrox G200 AGP
Grafikkartenchip-Typ
MGA-G200 B8
Grafikkarten-DAC-Typ
Integrated, 250 MHz
Netzwerk-Adapter
Name
3Com EtherLink XL 10/100 PCI für vollständige PCVerwaltung-NIC (3C905C-TX)
80
Typ
Ethernet 802.3
Produktname
3Com EtherLink XL 10/100 PCI für vollständige PCVerwaltung-NIC (3C905C-TX)
Betriebssystem-Versionen
1. Microsoft Windows NT Workstation
Version 4.0 (Build 1381: Service Pack 6)
2. Microsoft Windows 2000 Professional
Version 5.0.2195 Build 2195
3. Microsoft Windows 95
Version 4.0
4. Microsoft Windows 98
Version 4.10.1998
5. Microsoft Windows ME
Version 4.90.3000 Build 3000
Server-PC
Produkttyp:
Microsoft (R) Windows NT (TM) Workstation
Version:
Version 4.0 (Build 1381: Service Pack 6)
Plattform:
x86 Uniprocessor Free
System-BIOS:
Satellite Pro490CDT v7.40 TOS
System-BIOS-Datum:
08/04/98
CPU 1:
GenuineIntel x86 Family 6 Model 5 Stepping 0 233 Mhz
Gesamter phys. Speicher:
64884 KB
Auslagerungsdateigröße:
135400 KB
Auslagerungsdateinutzung: 12
Video-BIOS:
Rev 1.1
Video BIOS-Datum:
02/26/98
Grafikkartentyp:
S3 Incorporated Display Driver v3.27.07
81
Grafikkartenchip-Typ:
S3 ViRGE/MX
Grafikkartenspeicher:
2 MB
Netzwerk-Adapter
Xircom 16-bit Ethernet 10/100
82
Teil VII
Installationsanleitung EnterNet
83
Literaturverzeichnis
[1] The Internet Assigned Numbers Authority (Hrsg.). Directory of General
Assigned Numbers. URL http://www.iana.org/numbers.html. 2000
[2] ETSI Technical Committee Transmission and Multiplexing (TM):
ETSI TS 101 524 V1.1.2: Transmission and Multiplexing (TM); Access transmission system on metallic access cables; Symmetrical single pair high bitrate Digital
Subscriber Line (SDSL). 650 Route des Lucioles, F-06921 Sophia Antipolis Cedex
- FRANCE: European Telecommunications Standards Institute (ETSI), August
2001
[3] Lindecke, Sascha. Infineon Technologies POTSWIRE T M SHDSL Technology.
URL http://www.shdsl.org/shdsl white paper.pdf. März 2000
[4] Mamakos, L. [u. a.]. A Method For Transmitting PPP Over Ethernet (PPPoE)
: RFC 2516. URL http://www.ietf.org/rfc/rfc2516.txt. Februar 1999
[5] Microsoft. Windows NT Server Networking Guide : Chapter 1 - Windows NT
Networking Architecture. URL http://www.microsoft.com/technet/prodtechnol/
winntas/reskit/net/chptr1.asp
[6] Microsoft Corporation (Hrsg.): Appendix B – Windows 2000 Network Architecture. siehe [9]. – siehe auch URL http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/tcpip/part4/tcpappb.asp. – ISBN 1–5723–
1805–8
[7] Microsoft Corporation ; Microsoft Corporation (Hrsg.).
crosoft Windows 2000 DDK Network Driver Documentation.
http://www.microsoft.com/ddk/W2kDDK.asp. Juli 2000
MiURL
[8] Microsoft Corporation (Hrsg.): Microsoft Windows 2000 Server Resource
Kit. Microsoft Press Corporation, Januar 2000 (IT Professional). – 7296 S. – 7
Bde. mit CD-ROM. – ISBN 1–5723–1805–8
[9] Microsoft Corporation (Hrsg.): TCP/IP Core Networking Guide. Microsoft
Press Corporation, Januar 2000 siehe [8]. – 7296 S. – 7 Bde. mit CD-ROM. –
ISBN 1–5723–1805–8
xii
Literaturverzeichnis
[10] Simpson, William A. (Hrsg.). The Point-to-Point-Protocol (PPP) : RFC 1661,
STD 51. URL http://www.ietf.org/rfc/rfc1661.txt. Juli 1994
[11] The Navas Group. Navas Cable Modem/DSL Tuning Guide: Why tweaking
”
TTL won’t increase speed“. URL http://cable-dsl.home.att.net/index.htm. 2001
[12] Tischer, Michael ; Jennrich, Bruno: INTERNET intern : Technik & Programmierung. 1. Auflage. Düsseldorf : DATA BECKER, 1997. – 1301 S. – ISBN
3–8158–1160–0
[13] Zehnder, Carl A.: Informationssysteme und Datenbanken. Teubner Verlag, 1998.
– 335 S. – ISBN 3519324806
xiii
Selbständigkeitserklärung
Hiermit versichere ich, die vorliegende Diplomarbeit selbständig und ausschließlich
unter Verwendung der angegebenen Quellen erstellt zu haben.
Leipzig, den 26. August 2002
Jörg Brenner

Kopie

Transcription

Similar documents

GSM-2110/4110 RTU und Störmelder mit binären und analogen E/A

Die digitale Transformation der Industrie

Geschäftsbericht ansehen (PDF-Datei)

sidekick pc benutzerhandbuch

DEC3000-s - Hauppauge

Constrained RESTful Environments - Chair of Network Architectures

4. GI/ITG KuVS Fachgespräch "Drahtlose Sensornetze"

Grafikkarten unter eComStation und OS/2

RechnernetzeScriptum.. - Institut für Informatik