WEBVTT 00:00.880 --> 00:05.160 dieses Kapitels 6, wo es um die physikalischen Grundlagen geht. 00:05.680 --> 00:10.320 Wir haben die verschiedenen Modulationsverfahren behandelt, unter 00:10.320 --> 00:12.460 anderem Amplituden- und Frequenzmodulationen. 00:12.520 --> 00:17.080 Und jetzt ist die letzte Form der Modulation die Phasenmodulation, die 00:17.080 --> 00:17.700 wir hier sehen. 00:18.420 --> 00:23.840 Wir sehen wieder hier unser Primärsignal, das eben digital ist. 00:24.700 --> 00:30.880 Und durch die Modulation führen wir das über in ein analoges Signal. 00:31.320 --> 00:34.460 Das ist das Ein-Ausgabesignal, das wir bezeichnet haben. 00:35.120 --> 00:40.260 Und wir modulieren das digitale Signal, die digitalen Informationen, 00:41.420 --> 00:42.980 auf eine Trägerfrequenz. 00:43.720 --> 00:50.520 Und die digitalen Signale manipulieren sozusagen die Trägerfrequenz. 00:50.740 --> 00:55.160 Sie können die Amplitude manipulieren oder die Frequenz an sich. 00:55.160 --> 00:56.700 Dann bräuchten Sie zwei Oszillatoren. 00:57.120 --> 01:00.740 Oder eben wie hier angedeutet, die Phase. 01:01.580 --> 01:08.980 Und was wir hier sehen ist, dass wir diesen Bitstrom sozusagen 01:08.980 --> 01:12.180 aufmodulieren auf diese Trägerfrequenz. 01:12.840 --> 01:17.280 Und bei der Phasenmodulation gibt es zum Beispiel die CCITT 01:17.280 --> 01:24.620 -Empfehlung, die jetzt gar nicht mehr die Abkürzung ITU trägt. 01:24.620 --> 01:30.020 Die sagt, diese Empfehlung V1, V steht immer für analoge Standards, 01:30.740 --> 01:37.260 eine Null soll codiert werden oder soll dargestellt werden durch eine 01:37.260 --> 01:39.280 Phasendrehung um 180 Grad. 01:39.940 --> 01:42.780 Das können wir hier an diesem Beispiel recht schön sehen. 01:43.460 --> 01:48.240 Wir müssen immer an diesen Punkten letztendlich schauen, was passiert, 01:48.380 --> 01:49.520 gedreht oder gedreht wird. 01:49.980 --> 01:52.880 Das sind hier jetzt diese drei Punkte, an denen wir uns das anschauen 01:52.880 --> 01:53.180 können. 01:53.180 --> 01:59.560 Und hier sehen wir, wenn Sie sich das genauer betrachten, eine 30 Grad 01:59.560 --> 01:59.940 haben. 02:00.680 --> 02:02.840 Wir befinden uns also gerade hier bei 90 Grad. 02:03.560 --> 02:09.080 Und wir gehen jetzt nicht, wie es normalerweise der Ablauf wäre oder 02:09.080 --> 02:12.480 der Verlauf wäre, weiter nach unten, sondern wir drehen die Phase um 02:12.480 --> 02:17.900 180 Grad, von 90 auf 270 Grad und erhalten hier entsprechend dann 02:17.900 --> 02:19.180 diese... 02:19.180 --> 02:23.820 Und dadurch wird genau diese Null hier codiert oder festgelegt. 02:24.260 --> 02:28.400 Entsprechend sehen wir an dieser Stelle, die 1 wird dadurch eben 02:28.400 --> 02:32.240 ausgedrückt, dass wir keine Phasendrehung haben. 02:32.500 --> 02:35.960 Entsprechend hier wieder an dieser Stelle wird wieder eine Null 02:35.960 --> 02:45.120 codiert und an der Stelle wird eben von 270 Grad auf 90 Grad gedreht. 02:45.120 --> 02:49.290 So ist also das Vorgehen bei der Phasenmodulation. 02:50.080 --> 02:52.580 Deswegen kommt diese Art von Verlauf heraus. 02:52.960 --> 02:55.800 Das können Sie sich nochmal eben klar machen, wenn Sie sich diesen 02:55.800 --> 03:00.480 Kreis anschauen und eben die Sinus-Schwingung betrachten, dann können 03:00.480 --> 03:04.000 Sie ja die Winkel hier antragen und entsprechend die Gradzahlen 03:04.000 --> 03:06.420 antragen und dann kommen Sie eben genau auf diesen Verlauf. 03:07.340 --> 03:09.660 Phasenmodulation ist das beste, aber auch aufwendigste Verfahren. 03:09.960 --> 03:13.280 Kann man hier schon dran sich vorstellen, dass man eben so ein 03:13.280 --> 03:17.240 Verzögerungselement braucht, dass eben genau diese Phasendrehung, 03:17.620 --> 03:19.900 diese Phasenverzögerung durchführt. 03:20.400 --> 03:25.060 So, das wäre also zu den physikalischen Grundlagen. 03:25.180 --> 03:28.480 Wir kommen jetzt zu der Sicherungsschicht. 03:29.560 --> 03:35.580 Also wir gehen von der Schicht 1, die wir jetzt behandelt haben, das 03:35.580 --> 03:39.220 kann man hier fast nicht sehen, das ist grau unterlegt, in die Schicht 03:39.220 --> 03:39.600 2. 03:39.600 --> 03:45.260 Wir haben also die Signalebene überwunden, sind auf der Bit 03:45.260 --> 03:51.240 -Übertragungsebene angekommen und jetzt entstehen einige interessante 03:51.240 --> 03:55.880 Funktionen, einige interessante Aufgaben, die wir hier weiter unten 03:55.880 --> 03:56.740 betrachten werden. 03:57.240 --> 04:01.680 Das sind also die ersten Protokollfunktionen, die wir uns anschauen 04:01.680 --> 04:04.220 werden in dieser Schicht 2. 04:04.980 --> 04:08.600 Die Strukturierung der Datenübertragung ist eigentlich die Grundlage, 04:08.720 --> 04:11.080 um überhaupt Protokollfunktionen realisieren zu können. 04:11.500 --> 04:14.520 Sie können sich das vorstellen, wenn Sie auf der Bit-Ebene bleiben, 04:15.220 --> 04:17.600 können Sie eigentlich keine vernünftigen Protokollverfahren 04:17.600 --> 04:18.200 realisieren. 04:18.300 --> 04:20.700 Das haben wir beim Alternating-Grid-Protokoll eigentlich auch schon 04:20.700 --> 04:28.320 assoziiert oder zugrunde gelegt, dass wir solche PDUs hier einbauen 04:28.320 --> 04:31.980 müssen und einführen müssen, Protokolldateneinheiten einführen müssen. 04:31.980 --> 04:35.640 Das ist die Voraussetzung eigentlich, um hier solche 04:35.640 --> 04:38.660 Fehlerursachenbehandlungen machen zu können, Fehlerursachen zu 04:38.660 --> 04:41.600 erkennen, zu beheben oder auch Flusssteuerung machen zu können. 04:44.960 --> 04:48.140 Bei Medienzugriff ist nochmal eine andere Geschichte. 04:48.920 --> 04:55.640 Das ist einer der wenigen Verfahren in der Telematik, wo wir keine 04:55.640 --> 04:57.720 PDUs zugrunde legen müssen. 04:57.840 --> 05:01.100 Das hat noch sehr viel mit Nachrichtentechnik zu tun, hat aber schon 05:01.100 --> 05:02.420 auch was mit Algorithmen zu tun. 05:02.580 --> 05:04.260 Also das ist eigentlich ein interessanter Bereich. 05:04.760 --> 05:12.600 Das ist die Schicht 2a, die dadurch entsteht, dass wir eben gemeinsam 05:12.600 --> 05:13.580 genutzte Medien haben. 05:13.680 --> 05:16.120 Da werde ich heute intensiver noch drauf eingehen. 05:16.880 --> 05:20.820 Und dann kommt sozusagen diese PDU-Strukturierung und die ganzen 05:20.820 --> 05:24.480 Protokollfunktionen, die wir in den verschiedenen Schichten zu 05:24.480 --> 05:25.340 behandeln haben. 05:28.000 --> 05:32.040 So, schauen wir uns die Aufgaben der Sicherungsschicht nochmal an. 05:32.120 --> 05:35.640 Das haben wir an verschiedenen Stellen eigentlich schon im Überblick 05:35.640 --> 05:36.260 behandelt. 05:36.700 --> 05:40.500 Hier ist das nochmal eine weitere Überblicksfolie, die ins Gedächtnis 05:40.500 --> 05:41.900 rufen soll, wo wir uns befinden. 05:42.440 --> 05:46.780 Wir gehen eben hier aus von einem sogenannten nachrichtentechnischen 05:46.780 --> 05:47.260 Kanal. 05:47.940 --> 05:50.800 Es ist die Schicht 1-Verbindung, wenn Sie so wollen. 05:50.800 --> 05:56.940 Das ist ein Kanal, der vollständig durch das Medium vorgegeben ist. 05:57.260 --> 06:00.900 Da versuchen Sie tatsächlich nur auf die Bittebene zu kommen, 06:00.980 --> 06:03.200 Bittströme zu übertragen und die sind ungesichert. 06:03.560 --> 06:08.080 Das, was das Medium an der Stelle liefert, das steht Ihnen hier an 06:08.080 --> 06:11.040 diesem Dienstzugangspunkt, an diesem Service Access Point zur 06:11.040 --> 06:11.440 Verfügung. 06:12.300 --> 06:15.960 Und in der Sicherungsschicht versuchen wir, von dem 06:15.960 --> 06:19.840 nachrichtentechnischen Kanal zu einem gesicherten Kanal zu gelangen. 06:19.840 --> 06:25.380 Wir erhöhen also die Zuverlässigkeit, die Stabilität, die 06:25.380 --> 06:27.380 Fehlerwahrscheinlichkeit wird gedrückt. 06:28.120 --> 06:31.520 Und was noch hinzukommt, das ist eben jetzt diese erste Funktion, die 06:31.520 --> 06:32.300 ich Ihnen genannt habe. 06:32.380 --> 06:34.880 Verfälschung und Verlustsicherung soll hier realisiert werden. 06:35.260 --> 06:40.300 Und wir haben eben noch als zweite Grundfunktion, die insbesondere 06:40.300 --> 06:42.980 oder nur in lokalen Netzen auftritt, diesen Medienzugang. 06:42.980 --> 06:48.100 Also eigentlich zwei Funktionen, die traditionelle Funktion, die 06:48.100 --> 06:52.980 Absicherung des nachrichtentechnischen Kanals und den Medienzugang, um 06:52.980 --> 06:55.520 gemeinsam genutzte Medien aufteilen zu können. 06:55.860 --> 06:59.160 Die Strukturierung des Datenstroms, wie gesagt, ist eine 06:59.160 --> 07:03.620 Grundvoraussetzung, um diese erste Hauptfunktion realisieren zu 07:03.620 --> 07:03.820 können. 07:04.120 --> 07:06.340 Aber natürlich entsprechend auch sehr wichtig. 07:07.440 --> 07:11.400 Und vielleicht sollte ich nochmal zu der vorhergehenden hier 07:11.400 --> 07:12.440 übergehen. 07:13.020 --> 07:17.780 Diese Medienzugangskontrolle bei geteilten Medien, die führt uns genau 07:17.780 --> 07:19.760 in den Lokalnetzbereich. 07:19.960 --> 07:22.960 Oder andersrum gesagt, aus dem Lokalnetzbereich kommt genau diese 07:22.960 --> 07:24.640 Problematik des Medienzugangs. 07:25.140 --> 07:29.460 Und das ist jetzt der Übergang auch zu der nächsten Folie, die zeigt, 07:29.840 --> 07:34.960 wie sieht denn die Situation im LAN, im Lokalnetzbereich aus. 07:34.960 --> 07:40.300 Aufgabenteilung der Lokalnetzschichten, der Schichten in Lokalnetzen. 07:40.900 --> 07:45.920 Und hier sehen Sie das erste Mal explizit gemacht diese Schicht 2a. 07:46.420 --> 07:49.840 Das ist das eigentlich Interessante hier in diesem Modell. 07:50.340 --> 07:51.980 Wir haben eine Teilschichtenbildung. 07:53.080 --> 07:58.580 Die kommt daher, dass die ISO-Schichtung zuvor diesen Aspekt nicht 07:58.580 --> 07:59.320 behandelt hat. 08:00.000 --> 08:03.220 Also diese Aufteilung von gemeinsam genutzten Medien. 08:03.220 --> 08:09.280 Wir mussten zu dem Zeitpunkt, zu dem diese Problematik auftrat, 08:09.960 --> 08:16.120 irgendwie diese Funktion in die bestehende Schichtung einbauen. 08:17.000 --> 08:19.740 Und das ist so eine beliebte Prüfungsfrage auch in der 08:19.740 --> 08:21.920 Vertiefungsfachtelematik, die ich stelle. 08:22.960 --> 08:28.160 Sie haben hier Entscheidungsfreiheitsgrade, diese Funktion in ein 08:28.160 --> 08:29.880 bestehendes Referenzmodell einzubauen. 08:30.580 --> 08:33.620 Diskutieren Sie mal, ob es überhaupt ein Freiheitsgrad ist. 08:35.100 --> 08:38.620 Das werden Sie vielleicht jetzt im Moment noch nicht ganz umreißen 08:38.620 --> 08:39.800 können, die Problematik. 08:40.040 --> 08:41.240 Es ist aber eine sehr grundsätzliche. 08:41.300 --> 08:45.360 Man hat im Zusammenhang mit der ISO noch gar nicht an gemeinsam 08:45.360 --> 08:46.420 genutzten Medien gedacht. 08:46.520 --> 08:51.080 Man ist eigentlich davon ausgegangen, dass man so teilvermaschte Netze 08:51.080 --> 08:51.220 hat. 08:51.320 --> 08:53.940 Das waren die öffentlichen Netze, das waren diese Vermittlungsknoten. 08:53.940 --> 08:57.260 Und man hat gedacht, naja, ich muss halt diese Links, das sind ja 08:57.260 --> 09:00.960 diese Schicht 2 Verbindungen, die muss ich erstmal absichern und in 09:00.960 --> 09:03.320 der Schicht 3 versuche ich die Wege aufzubauen. 09:03.540 --> 09:07.420 Man ist eigentlich bei der Konstruktion von dem Referenzmodell davon 09:07.420 --> 09:10.400 ausgegangen, ich habe keine gemeinsam genutzten Medien. 09:10.540 --> 09:14.580 Ich habe diese Verbindungen, die zwei Knoten miteinander in Verbindung 09:14.580 --> 09:16.180 bringen und die muss ich absichern. 09:16.560 --> 09:20.680 Und die ganze Sache hat sich dramatisch geändert, als man mit solchen 09:20.680 --> 09:23.540 Strukturen angefangen hat, mit solchen Busstrukturen angefangen hat. 09:23.600 --> 09:26.700 Und die sind ja diejenigen, die sich heute auch letztendlich im 09:26.700 --> 09:28.420 Lokalnetzbereich durchgesetzt haben. 09:28.900 --> 09:30.880 Da hat man eine ganz neue Aufgabe gehabt. 09:31.360 --> 09:34.520 Dieser eine Strich, das ist ja eigentlich das, was man hier 09:34.520 --> 09:37.760 vergleichen könnte, nämlich das ist letztendlich die Strippe, sage ich 09:37.760 --> 09:38.000 mal. 09:38.480 --> 09:44.320 Diese beiden Striche haben eine ganz unterschiedliche Positionierung. 09:44.720 --> 09:48.020 Im einen Fall haben wir sowas wie Punkt-zu-Punkt-Verbindung, 09:48.140 --> 09:49.620 dedizierte Leitung, wie wir sagen. 09:49.620 --> 09:53.120 Und im unteren Fall haben wir jetzt auf einmal sowas, was wir aus 09:53.120 --> 09:56.360 Betriebssystemen heraus kennen, eine gemeinsam genutzte Ressource. 09:56.860 --> 09:59.860 Nämlich das ist genau das gleiche, ob das jetzt Speicher ist oder ob 09:59.860 --> 10:03.080 das eine CPU ist, ist halt jetzt eine Strippe, ist jetzt ein Medium 10:03.080 --> 10:05.480 und da greifen mehrere gleichzeitig drauf zu. 10:05.980 --> 10:09.880 So, das muss ich irgendwie auflösen, dieses Problem, bevor ich mich 10:09.880 --> 10:13.080 wieder an die ganz normalen Protokollfunktionen machen kann. 10:13.080 --> 10:18.400 Und die Frage ist jetzt, wir haben diese bestehende Schichtung, gibt 10:18.400 --> 10:19.800 es irgendwelche Alternativen? 10:19.920 --> 10:24.800 Könnte man sich sozusagen überlegen, ob man diese Schicht 2a nicht 10:24.800 --> 10:28.060 noch weiter nach oben bringt, ob man die weiter nach unten bringt oder 10:28.060 --> 10:29.140 muss die genau da liegen? 10:29.380 --> 10:32.840 Das ist eine interessante Diskussion, möchte ich hier an der Stelle 10:32.840 --> 10:33.800 nicht vertiefen. 10:34.900 --> 10:36.940 Es gibt aber sehr geringe Freiheitsgrade. 10:36.940 --> 10:41.880 Also man muss irgendwie unten wohl die Medien behandeln und oben muss 10:41.880 --> 10:43.540 man dann die Absicherung durchführen. 10:43.820 --> 10:46.540 Die Absicherung kann ich eigentlich nur, dieses Logical Link Control, 10:46.680 --> 10:50.460 das ist genau die Schicht 2, das wäre die klassische Schicht 2 im ISO 10:50.460 --> 10:54.960 -Kontext, kann ich eigentlich nur richtig behandeln, wenn ich mal 10:54.960 --> 10:56.620 weiß, ja welche zwei sind es denn? 10:56.700 --> 10:59.500 Also die zwei greife ich dann raus, durch die Schicht 2a wird 10:59.500 --> 11:03.500 sozusagen gesagt, diese beiden bekommen das Medium und dann kann ich 11:03.500 --> 11:07.120 eigentlich erst diese ganz normalen Protokollfunktionen darauf 11:07.120 --> 11:09.500 anwenden, weil ich dann nämlich erst sozusagen die Verbindung 11:09.500 --> 11:14.960 identifiziert habe, die ich absichern möchte, wo ich ein Multiplexing 11:14.960 --> 11:17.720 drauf durchführen möchte, Qualitäten festlegen möchte und so weiter. 11:18.440 --> 11:22.380 Und in dieser Schicht 2a, werden wir eben heute auch noch sehen, haben 11:22.380 --> 11:26.100 wir grundsätzlich zwei verschiedene Möglichkeiten, das Medium 11:26.100 --> 11:26.920 zuzuteilen. 11:26.920 --> 11:32.060 Die eine Möglichkeit ist, dass ich sage, ich habe einen Algorithmus, 11:32.480 --> 11:38.480 der vorab genau festlegt, wer von diesen teilnehmenden Stationen das 11:38.480 --> 11:46.460 Medium erhält und diese steuernde Instanz legt genau diese beiden zu 11:46.460 --> 11:49.680 jedem Zeitpunkt fest, dann kann nichts passieren, dann müssen sie das 11:49.680 --> 11:51.820 Medium abgeben und die nächsten sind dran. 11:51.820 --> 11:56.140 Das ist der kontrollierte Zugriff, also der gesteuerte kontrollierte 11:56.140 --> 11:57.260 Zugriff. 11:57.860 --> 12:02.320 Und da können sie sich schon dran überlegen, das könnte aufwendig 12:02.320 --> 12:04.080 werden, das könnte ineffizient werden. 12:05.620 --> 12:09.140 Warum lässt man nicht auch eine Möglichkeit zu, dass die konkurrierend 12:09.140 --> 12:11.860 darauf zugreifen, die verschiedenen Teilnehmer und wenn dann was 12:11.860 --> 12:13.620 schief geht, dann löse ich das halt irgendwie auf. 12:13.620 --> 12:20.600 Und es ist erstaunlich, aufgrund von verschiedenen Phänomenen, hat 12:20.600 --> 12:26.100 sich dieser konkurrierende Zugriff extrem durchgesetzt gegenüber dem 12:26.100 --> 12:27.480 kontrollierten Zugriff. 12:27.900 --> 12:30.960 Das eine ist eben das Ethernet-Verfahren, das wir jetzt auch mit dem 12:30.960 --> 12:34.520 Fast Ethernet weiterhin in der Zukunft haben werden und das andere 12:34.520 --> 12:41.400 kontrollierte Zugriff steht für Token Ring, der immer hinterher, also 12:41.400 --> 12:44.840 immer großer Abstand zwischen Ethernet und Token Ring war, trotz der 12:44.840 --> 12:48.300 ganzen Überlegungen, die IBM damit eingebracht hat, hat sich das 12:48.300 --> 12:49.900 eigentlich weniger durchgesetzt. 12:50.080 --> 12:53.640 Es sind aber einige, wie gesagt, einige Phänomene da enthalten in 12:53.640 --> 12:57.700 diesem CSMACD-Verfahren, das hinter dem konkurrierenden Zugriff 12:57.700 --> 13:02.800 steckt, die, sage ich mal, glücklicherweise zusammengekommen sind, 13:02.800 --> 13:06.300 dass dieser konkurrierende Zugriff wirklich effizient ist, extrem 13:06.300 --> 13:09.240 effizient ist und deswegen haben wir zum Beispiel jetzt das Fast 13:09.240 --> 13:09.640 Ethernet. 13:09.800 --> 13:13.720 Wenn dem nicht so wäre, würden auch andere Produkte existieren. 13:14.140 --> 13:16.840 So, die Medien, das haben wir auch schon behandelt, hier sehen Sie 13:16.840 --> 13:20.780 nochmal die drei wichtigsten, die wir in den heutigen lokalen Netzen 13:20.780 --> 13:23.840 verarbeiten, also auf der untersten Ebene. 13:24.300 --> 13:28.600 Die sind die Glasfasern sicherlich als wichtigstes Medium, heute 13:28.600 --> 13:30.620 eingesetztes Medium zu nennen. 13:30.620 --> 13:36.720 Was erstaunlich ist, also das sollten Sie sich einfach mal näher 13:36.720 --> 13:41.720 betrachten, wir kommen, was Übertragungskapazität angeht, in den 13:41.720 --> 13:43.300 Terabit pro Sekunde-Bereich. 13:44.020 --> 13:49.460 Wenn Sie sich mal einen Terabyte angeschaut haben als Datenablage, da 13:49.460 --> 13:53.280 können Sie also sehr viel an Informationen reinbuttern, um sowas zu 13:53.280 --> 13:53.800 realisieren. 13:53.800 --> 13:59.260 Wir kommen dazu, dass wir innerhalb von Sekunden Terabytes schleifen 13:59.260 --> 14:00.880 können über die Netze. 14:03.020 --> 14:07.560 Eigentlich haben wir heute die Situation, in spezialisierten 14:07.560 --> 14:13.780 Bereichen, dass wir viel mehr Übertragungskapazität anbieten können, 14:13.900 --> 14:16.580 als wir tatsächlich Anwendungen haben. 14:16.780 --> 14:20.860 Das gilt nicht für den großflächigen Bereich, jetzt World Wide Web, 14:21.320 --> 14:26.140 mit den Problemen der Wartezeiten, da nicht, aber in lokal 14:26.140 --> 14:31.620 abgegrenzten Szenarien, in Laborbereichen, haben wir sehr viel mehr 14:31.620 --> 14:36.200 Kapazität, Übertragungskapazität, als die Systeme an 14:36.200 --> 14:38.420 Verarbeitungsleistung liefern. 14:38.600 --> 14:42.080 Das ist auch ein Fehler, der häufig gemacht wird oder nicht gesehen 14:42.080 --> 14:46.240 wird, dass man meint, die Netze sind immer eigentlich der Engpass und 14:46.240 --> 14:49.100 die Systeme sind so schnell und die Systeme sind so leistungsfähig. 14:49.100 --> 14:54.220 Das gilt wirklich nur für die flächendeckenden Netze, für die 14:54.220 --> 14:55.270 flächendeckende Übertragung. 14:56.060 --> 15:00.840 Das gilt nicht für Applikationen oder Anwendungsumfelder, die sie sich 15:00.840 --> 15:04.200 in einem abgegrenzten Szenario zusammenbauen. 15:04.340 --> 15:08.340 Es ist tatsächlich so, dass wir heute Übertragungskapazitäten anbieten 15:08.340 --> 15:10.560 können und wir wissen gar nicht, wozu wir die verwenden sollen. 15:11.080 --> 15:11.960 Das war schon immer so. 15:12.280 --> 15:15.700 Das war schon, als ich 1980 mein Diplom gemacht habe. 15:15.700 --> 15:21.640 Am Leibniz Rechenzentrum war ich mit der Ersten, der an dem Ethernet 15:21.640 --> 15:22.700 mitgearbeitet hat. 15:23.780 --> 15:27.100 10 Megabit pro Sekunde, das war schon zu dem Zeitpunkt 10 Megabit pro 15:27.100 --> 15:27.360 Sekunde. 15:27.460 --> 15:31.180 Ich habe da so einen Protokollanalysator in C geschrieben und wir 15:31.180 --> 15:33.620 wussten gar nicht, was wir eigentlich mit den 10 Megabit pro Sekunde 15:33.620 --> 15:34.200 machen sollen. 15:34.580 --> 15:38.740 Also die Systeme haben da so ganz leicht ihre Daten auf das Netz 15:38.740 --> 15:41.720 gelegt und heute ist das nicht mehr das Thema. 15:41.840 --> 15:45.920 10 Megabit pro Sekunde haben sie ganz schnell besetzt. 15:46.540 --> 15:49.480 Wir sind jetzt bei 100 Megabit pro Sekunde, aber eigentlich sind wir 15:49.480 --> 15:50.600 schon im Terabit pro Sekunde. 15:50.700 --> 15:53.080 Eigentlich sind wir schon im Gigabit und Terabit pro Sekunde Bereich 15:53.080 --> 15:56.740 und wir sind tatsächlich in der Forschung überlegen, was sind 15:56.740 --> 16:00.920 Applikationen, die tatsächlich solche Übertragungsdaten, Datenmengen 16:00.920 --> 16:01.360 benötigen. 16:01.600 --> 16:05.520 Sehr interessant, sozusagen nochmal diese Entwicklung von Systemen auf 16:05.520 --> 16:07.920 der einen Seite und Netzen auf der anderen Seite zu verfolgen. 16:07.920 --> 16:08.520 Hier ist eine Frage. 16:13.840 --> 16:14.940 Das stimmt nicht. 16:15.340 --> 16:20.100 Also hier steht drin, es ist noch genannt, also die Frage war, warum 16:20.100 --> 16:24.540 kann ich über verdrillte Kupferadern so viel mehr übertragen als über 16:24.540 --> 16:25.340 Koaxialkabel. 16:25.640 --> 16:28.420 Wichtig ist, theoretisch mehr doch nicht genutzt. 16:28.620 --> 16:31.940 Das Thema ist, das Koaxialkabel hat sich ausgelebt. 16:32.320 --> 16:35.840 Wir haben mit dem Twisted Pair eine Möglichkeit, heute relativ 16:35.840 --> 16:38.240 akzeptable Datenmengen zu übertragen. 16:38.240 --> 16:43.260 Mit dem Koaxialkabel, da kämen Sie sicherlich nochmal um den Faktor 10 16:43.260 --> 16:47.700 bis 100 problemlos besser voran, als mit einem verdrillten 16:47.700 --> 16:48.240 Kupferkabel. 16:49.340 --> 16:53.520 Nur das Problem ist, das Koaxialkabel ist viel zu teuer und Sie kommen 16:53.520 --> 16:56.300 nicht an die Dimension ran, die Ihnen Glasfasern bietet. 16:56.420 --> 16:58.260 Das heißt, es ist schlichtweg uninteressant geworden. 16:58.600 --> 17:02.300 Diese Abschirmung, die ich früher gemacht habe, um zu besseren 17:02.300 --> 17:05.380 Übertragungskapazitäten zu kommen, habe ich mit dem verdrillten 17:05.380 --> 17:06.940 Kupferadern jetzt in den Griff bekommen. 17:06.940 --> 17:11.020 Und um wirklich auf Dimensionen wie Terabit pro Sekunde zu kommen, 17:11.500 --> 17:13.560 führt der Weg an Glasfaser nicht vorbei. 17:13.740 --> 17:20.160 Der Grund ist schlichtweg, das Koaxialkabel hat keine wirklichen 17:20.160 --> 17:20.800 Vorteile mehr. 17:21.200 --> 17:23.660 Wir können mit verdrillten Kupferadern und Glasfaser arbeiten. 17:23.980 --> 17:27.160 Was auch noch ein Thema ist, was hier nicht aufgeführt ist, müsste 17:27.160 --> 17:30.000 aber im lokalen Netzumfeld durchaus erwähnt werden. 17:30.480 --> 17:34.240 Das ist die ganze Mobilfunktechnologie. 17:34.240 --> 17:38.840 Das ist auch eines der heißen Themen, auch in der Telematik, wie man 17:38.840 --> 17:41.920 hier zu vernünftigen Übertragungskapazitäten kommt. 17:42.540 --> 17:46.420 Aber Sie wissen ja auch selber, die ganze Diskussion mit Elektrosmog 17:46.420 --> 17:49.420 und dergleichen ist tatsächlich ein Thema, wenn Sie zu hohen 17:49.420 --> 17:52.780 Frequenzbereichen kommen und zu hohen Übertragungskapazitäten kommen, 17:53.480 --> 17:56.440 kommt da sozusagen nochmal ein ganz neues Thema dazu, das wir ja hier 17:56.440 --> 17:57.520 an dieser Stelle nicht haben. 17:58.640 --> 18:01.860 Vielleicht noch eine Story dazu, was auch ganz witzig war. 18:01.860 --> 18:09.600 Wo das erste Mal im größeren Umfeld so eine Verkabelung von 10 Megabit 18:09.600 --> 18:13.060 bis zu 100 Megabit pro Sekunde durchgeführt worden ist, da gab es 18:13.060 --> 18:16.480 tatsächlich Studien, die sich erstmal Gedanken gemacht haben, ob nicht 18:16.480 --> 18:21.200 durch irgendwelche physikalischen Phänomene die Brandgefahr erhöht 18:21.200 --> 18:23.020 wird, durch die höheren Frequenzbereiche. 18:23.180 --> 18:26.480 Da gab es tatsächlich Vermutungen, dass man hier ein großes 18:26.480 --> 18:29.100 Gefahrenpotential sich ins Haus holt. 18:29.460 --> 18:30.840 Das hat sich dann nicht bewahrheitet. 18:30.840 --> 18:34.340 Also ich möchte nicht sagen, dass jetzt diese Diskussion mit den 18:34.340 --> 18:38.060 Funknetzen diese Kategorie einnimmt. 18:38.620 --> 18:43.120 Wir müssen schauen, wie wir wirklich mit Situationen umgehen, wo wir 18:43.120 --> 18:47.460 überall um uns herum Funknetze aufgebaut haben. 18:47.560 --> 18:50.780 Da weiß heute tatsächlich noch kein Mensch, was das tatsächlich heißt 18:50.780 --> 18:53.360 für die Organismen und für die Umwelt. 18:54.100 --> 18:58.760 Es sind aber Themen, die massiv bearbeitet werden, auch von Industrie 18:58.760 --> 19:02.440 sehr interessiert beobachtet werden und bearbeitet werden, weil es 19:02.440 --> 19:04.340 bringt ja nichts in die Technologie zu investieren. 19:04.420 --> 19:08.000 Dann stellt sich nach 5 Jahren raus, eine riesen Krebsgefahr oder 19:08.000 --> 19:09.180 sowas kommt auf. 19:09.820 --> 19:12.540 Das ist also ein großes Risiko, was man da eingehen würde. 19:13.800 --> 19:20.000 Gut, das waren also jetzt die Lokalnetz-Aspekte auf der Stich 2. 19:20.000 --> 19:23.280 Wir kommen jetzt zum Medienzugriff. 19:24.420 --> 19:26.940 Das ist schon noch zu früh, zum Medienzugriff. 19:27.300 --> 19:30.140 Und wir sehen jetzt mal diese ganzen Topologien auf der ersten Folie. 19:31.140 --> 19:37.260 Das sind also die Netztopologien, die wir heute unterscheiden. 19:37.580 --> 19:41.320 Wir können die so ein bisschen gruppieren, in der Form, dass wir 19:41.320 --> 19:45.940 sagen, na diese Art von Netze, vollvermascht ist eigentlich ein 19:45.940 --> 19:49.420 absoluter Spezialfall, aber dieses teilvermaschte Netz, das finden wir 19:49.420 --> 19:51.480 im WAN-Bereich, Wide Area Network-Bereich. 19:51.600 --> 19:54.820 Also das IP-Netz ist ein teilvermaschtes Netz, da können Sie sich eben 19:54.820 --> 20:02.180 vorstellen, diese Knoten hier, das sind eben die IP-Router, die IP 20:02.180 --> 20:07.140 -Vermittlungsknoten, die die IP-Pakete über dieses teilvermaschte Netz 20:07.140 --> 20:07.840 transportieren. 20:09.040 --> 20:11.240 Interessant ist durchaus der Stern. 20:11.860 --> 20:13.860 Da können wir die beiden hier eigentlich verknüpfen. 20:14.320 --> 20:17.600 Aus dem Stern geht die hierarchische Anordnung hervor. 20:17.740 --> 20:20.300 Das sind sozusagen Sterne mit Satelliten dran. 20:21.880 --> 20:27.000 Insofern hat das eine große Bedeutung erreicht, als dass wir die 20:27.000 --> 20:31.520 Busstruktur im Rahmen vom Ethernet darauf abbilden können. 20:32.120 --> 20:34.360 Das will man auch zunächst nicht glauben. 20:34.360 --> 20:39.980 Dass das sozusagen abbildbar ist, diese beiden Strukturen, wird genau 20:39.980 --> 20:44.100 gemacht, wenn ich von einem 10-Base-5, das ist von einem normalen 20:44.100 --> 20:48.880 gelben Kabel-Ethernet-Bus strukturiert, auf ein Twisted-Pair, ein 10 20:48.880 --> 20:53.180 -Base -T gehe, dann wird nämlich dieser Bus, der jetzt ursprünglich 20:53.180 --> 20:56.700 das Medium war, oder in diesem Fall das Medium ist, wird zu einer 20:56.700 --> 21:00.580 Komponente, das nennt man den Hub, wie sicherlich schon mal gehört, 21:00.660 --> 21:01.480 oder Sternkoppler. 21:01.480 --> 21:07.880 Da wird sozusagen das Medium und die ganze Anschlusstechnik wird 21:07.880 --> 21:10.140 sozusagen in eine Komponente gebündelt. 21:10.900 --> 21:15.860 Und insofern ist der Stern, und auch diese hierarchische Anordnung, 21:16.520 --> 21:20.600 ist heute die häufigste Form der Netztopologie, die Sie im 21:20.600 --> 21:21.740 Lokalnetzbereich finden. 21:21.940 --> 21:23.200 Weniger die Bustechnologie. 21:24.460 --> 21:27.060 Und der Ring ist insofern interessant, dass wir eben noch den 21:27.060 --> 21:29.880 Tokenring an der Stelle als Implementierung haben. 21:29.880 --> 21:33.140 Also insofern kann man eigentlich hier so ein bisschen eine Grenze 21:33.140 --> 21:34.320 ziehen zwischen diesen beiden. 21:34.860 --> 21:38.160 Hier sind wir eher im Lokalnetzbereich, diese Strukturen, und wenn wir 21:38.160 --> 21:43.980 dann in die höhere Ebene gehen, ab Schicht 3, finden wir immer solche 21:43.980 --> 21:47.640 teilvermaschten Topologien vor. 21:53.820 --> 22:02.180 IEEE war massiv und ist massiv beteiligt an den Schichten 1 und 2 im 22:02.180 --> 22:06.040 Lokalnetzumfeld und im Metropolitan Area Network Umfeld. 22:06.600 --> 22:11.720 Und hier sehen Sie die wichtigsten Standardisierungsdokumente. 22:12.960 --> 22:18.340 Die sind alle in dieser 802.x vereinigt. 22:19.180 --> 22:23.160 Also 802.x, da x steht eben für eine laufende Nummer, und da haben wir 22:23.160 --> 22:27.720 heute schon eine zweistellige Anzahl von wichtigsten Dokumenten. 22:27.720 --> 22:31.220 Also die ganzen Dokumente, die hier aufgeführt sind, das sind die 22:31.220 --> 22:35.540 wichtigsten Standardisierungsdokumente im Lokalnetz und im 22:35.540 --> 22:37.380 Metropolitan Area Network Bereich. 22:38.100 --> 22:43.200 Und Sie sehen, dass man also hier diese Dokumente in der Form anordnen 22:43.200 --> 22:43.540 kann. 22:44.280 --> 22:45.920 Fangen wir mal kurz durch. 22:46.040 --> 22:53.220 Diese 802.1 liefert die Gesamtarchitektur dieses LAN-Modells. 22:53.220 --> 22:58.740 Man redet auch von einem Implementierungsreferenzmodell in dem 22:58.740 --> 23:03.880 Zusammenhang von IEEE, weil das Referenzmodell von IEEE sehr viel 23:03.880 --> 23:06.320 weiter geht als das ISO-Modell, auch sehr viel weiter geht als das 23:06.320 --> 23:07.140 Internet -Modell. 23:07.760 --> 23:10.640 Da steckt eigentlich in den Standards drin, wie Sie ein Internet 23:10.640 --> 23:13.860 aufbauen, wie die Komponenten aussehen, welche mechanischen 23:13.860 --> 23:15.460 Eigenschaften diese Komponenten haben. 23:15.580 --> 23:19.120 Also es ist nicht nur irgendwie ein hübsches Paperwork, sondern das 23:19.120 --> 23:26.420 liest sich eher wie eine Technikspezifikation eines Netzes. 23:26.600 --> 23:30.640 Und insofern redet man hier von Implementierungsreferenzmodellen, weil 23:30.640 --> 23:34.600 es sozusagen wirklich dazu dient, so ein Netz aufzubauen und die 23:34.600 --> 23:36.060 Komponenten zu spezifizieren. 23:36.220 --> 23:40.080 Nicht nur logisch, sondern auch physisch und deren physischen 23:40.080 --> 23:40.780 Eigenschaften. 23:41.440 --> 23:43.960 So, und das ist also die Gesamtarchitektur. 23:44.100 --> 23:45.860 Es wird auch über das Management ein bisschen was gesagt. 23:45.860 --> 23:49.260 Ein ganz wichtiges Thema, es geht nicht nur darum bei Netzen, wie baue 23:49.260 --> 23:52.380 ich die auf, sondern wie betreibe ich die, wie überwache ich die, wie 23:52.380 --> 23:54.740 stelle ich sicher, dass die funktionieren, diese Netze. 23:54.820 --> 23:55.540 Das ist das Management. 23:56.580 --> 24:00.360 Dann haben wir hier auch in dem 802.1 so eine übergelagerte 24:00.360 --> 24:06.860 Fragestellung, wie führe ich ein Bridging, eine Brückenbildung, eine 24:06.860 --> 24:11.060 Überbrückung von verschiedenen Technologien durch, auf der MEC-Ebene, 24:11.200 --> 24:13.940 auf der Stich 2a, auf der Medium Access Control. 24:15.220 --> 24:20.460 Darunter finden wir dann die verschiedenen Ansätze, wie ich die 24:20.460 --> 24:23.420 Schichten 1 und 2a gestalten kann. 24:24.340 --> 24:27.840 Ich kann ein CSMACD-Verfahren realisieren, das heißt, ich realisiere 24:27.840 --> 24:29.000 das Ethernet an der Stelle. 24:30.060 --> 24:31.260 Das ist genau das Ethernet. 24:31.740 --> 24:34.000 Ich kann ein Tokenbus, ich kann ein Tokenring realisieren. 24:35.280 --> 24:39.220 Und das Schöne ist, an diesem Modell, ich kann das Ganze wieder 24:39.220 --> 24:39.960 zusammenführen. 24:39.960 --> 24:45.460 Das heißt, ich habe da nicht isolierte Welten, Inseln, sondern durch 24:45.460 --> 24:49.160 das Bridging wird sozusagen wieder das gesamte Netz zusammengefügt. 24:49.440 --> 24:53.800 Und Sie müssen sich eben obendrüber eigentlich immer das IP denken und 24:53.800 --> 24:54.680 das Internet denken. 24:56.080 --> 24:59.560 Das ist dann sozusagen, was oben ab der Stich 3 weitergeht. 25:00.120 --> 25:04.500 Und dazwischen haben Sie noch diese Aufgabe der Sicherung, der 25:04.500 --> 25:09.100 eigentlichen traditionellen Absicherung des Links, also der Stich 2 25:09.100 --> 25:09.680 Verbindung. 25:10.220 --> 25:13.280 Und das ist dann die Stich 2b, nennen wir sie, weil wir ja schon die 25:13.280 --> 25:16.280 Stich 2a, den MacLayer hier eingeführt haben. 25:16.740 --> 25:21.920 Und das heißt, wir haben eigentlich auf zwei Ebenen eine Kopplung im 25:21.920 --> 25:22.480 Netzbereich. 25:23.060 --> 25:26.240 Mindestens auf zwei Ebenen im Transportsystem. 25:27.100 --> 25:31.940 Unten, was die eigentlichen LAN-Technologien angeht, die also 25:31.940 --> 25:37.440 sozusagen die physikalischen Netzstrukturen einbringen, das wird dann 25:37.440 --> 25:43.520 auf der Stich 2b, na es ist 2a noch, dieses Mac-Bridging, deswegen 25:43.520 --> 25:47.080 heißt es Mac, Stich 2a gemacht, es gibt auch auf der Stich 2b 25:47.080 --> 25:48.520 Möglichkeiten der Kopplung. 25:48.520 --> 25:54.880 Und dann noch eine Ebene drüber, wenn ich diese einzelnen Teilnetze 25:54.880 --> 25:58.200 verbunden habe, und dann gehe ich eigentlich eher schon aus den 25:58.200 --> 26:02.800 Unternehmensdomänen raus, möchte eine weltweite Kopplung realisieren, 26:03.140 --> 26:04.520 und das mache ich auf der Stich 3. 26:04.880 --> 26:08.060 Das heißt, Sie haben eigentlich, wenn Sie sich mal ein 26:08.060 --> 26:10.880 Unternehmensnetz anschauen, ich sage mal UN steht für ein 26:10.880 --> 26:15.100 Unternehmensnetz, dann sieht das so aus, dass Sie hier einzelne Netze 26:15.100 --> 26:15.300 haben. 26:15.300 --> 26:19.740 Sie haben ein Ethernet, Sie haben ein Token Ring, Sie haben ein Token 26:19.740 --> 26:23.200 Bus, Sie haben irgendein anderes Netz, das Sie irgendwie anbinden 26:23.200 --> 26:27.740 müssen, und diese Anbindung, also dieses Verknüpfen zu einem 26:27.740 --> 26:31.400 sogenannten Corporate Network, das passiert im Wesentlichen hier auf 26:31.400 --> 26:35.760 dieser, oder kann auf dieser Stich 2 passieren, und dann haben Sie 26:35.760 --> 26:38.460 sozusagen auf der Stich 2 sein Unternehmensnetz, und wenn Sie jetzt 26:38.460 --> 26:42.040 wirklich noch weitere Unternehmensnetze koppeln wollen, also Sie gehen 26:42.040 --> 26:45.880 sozusagen in die Welt raus, das machen Sie über das Internet. 26:48.160 --> 26:51.860 Das ist das Internet, das ist hier diese Wolke, und darüber wird das 26:51.860 --> 26:52.300 gekoppelt. 26:52.880 --> 26:57.060 Was in der Tat passiert, das war also diese Kopplung auf der Stich 2, 26:57.600 --> 27:00.160 das war Thema, als man damit angefangen hat. 27:00.880 --> 27:03.600 Sie haben gemerkt, ich habe ein bisschen gezögert, weil nämlich in der 27:03.600 --> 27:07.760 Tat ist es jetzt so, dass man gar nicht mehr auf der Stich 2 heute 27:07.760 --> 27:11.640 koppeln möchte, aus verschiedenen Gründen, sondern man zieht sich 27:11.640 --> 27:15.700 eigentlich das Internet, das IP, zieht man sich in dieses 27:15.700 --> 27:20.020 Unternehmensnetz rein und koppelt sozusagen über ein 27:20.020 --> 27:24.740 unternehmensinternes Internet die Netze, deswegen reden wir von einem 27:24.740 --> 27:28.500 Intranet, das ist genau das Thema, der Begriff Intranet, dass ich 27:28.500 --> 27:34.320 innerhalb einer Unternehmensdomäne die Internettechnologie nutze, um 27:34.320 --> 27:36.680 Netze, verschiedene Netze zu koppeln. 27:36.680 --> 27:39.880 Und da ist genau die grundsätzliche Frage, die dahinter steckt, 27:40.660 --> 27:46.820 koppelt ich Netze auf der Stich 2, im Sinne eines Bridgings, oder 27:46.820 --> 27:50.360 kopple ich Netze auf der Stich 3, im Sinne eines Routings. 27:51.340 --> 27:56.320 Das ist also eine grundsätzliche Frage gewesen, lange Zeit hat man auf 27:56.320 --> 28:00.320 dieser Stich 2 ein Bridging durchgeführt, aus verschiedensten Gründen, 28:00.480 --> 28:04.500 ein Grund ist, dass das Internet sozusagen außerhalb auch in die 28:04.500 --> 28:07.660 Unternehmensnetze reingewachsen ist, macht das Sinn, dass man eben gar 28:07.660 --> 28:10.960 nicht mehr auf der Stich 2 koppelt, sondern auf der Stich 3, dass man 28:10.960 --> 28:15.300 sozusagen fast eine homogene Struktur hat mit Intranetz, mit dem 28:15.300 --> 28:18.760 Internet, das außerhalb die ganzen anderen Intranetz verbindet, und 28:18.760 --> 28:24.400 gegebenenfalls auch Extranetz, die sozusagen Netze außerhalb sind, die 28:24.400 --> 28:27.020 abgegrenzte Domänen darstellen. 28:29.320 --> 28:32.280 Diese unteren Technologien werden wir uns dann gleich noch anschauen. 28:32.280 --> 28:36.760 Hier sehen wir vielleicht noch als zum Abschluss, dass auch Security 28:36.760 --> 28:39.220 ein großes Thema in diesem Modell ist. 28:39.600 --> 28:43.120 Es gibt einen eigenen Standard, der sich mit Security 28:43.120 --> 28:47.200 -Sicherheitsinfrastrukturen für 802.X-Protokolle beschäftigt. 28:47.700 --> 28:52.540 Also Sie sehen, das Thema wird auch in dem Standard gewürdigt. 28:53.020 --> 28:56.320 So, schauen wir uns die Zugriffsverfahren mal im Überblick an. 28:57.100 --> 29:01.540 Die ersten zwei Klassen haben wir eigentlich schon behandelt. 29:01.540 --> 29:03.820 Zeiten-Multiplex, Frequenz-Multiplex. 29:03.880 --> 29:07.300 Erstmal muss man vielleicht noch verdeutlichen, dass Medien zuteilen 29:07.300 --> 29:08.740 nichts anderes als Multiplexing. 29:09.500 --> 29:09.740 Warum? 29:10.800 --> 29:15.240 Weil ich ein Medium habe, eine Verbindung habe, eine physische 29:15.240 --> 29:19.240 Verbindung habe, und die teile ich mehreren Teilnehmern zu, und das 29:19.240 --> 29:20.420 ist genau Multiplexing. 29:21.080 --> 29:25.200 Und wir können Zeit-Multiplexing oder Frequenz-Multiplexing 29:25.200 --> 29:25.600 durchführen. 29:25.680 --> 29:29.200 Sie sehen schon an der Grafik hier, das ist das Interessante. 29:29.200 --> 29:33.200 Damit beschäftigen sich auch die Lahn-Technologien im Wesentlichen. 29:34.080 --> 29:36.540 Was nicht heißt, dass es kein Frequenz-Multiplexing gibt, aber das ist 29:36.540 --> 29:38.360 nachrichtentechnische Geschichte. 29:39.080 --> 29:40.980 Das ist bei Basisband und Breitband. 29:41.700 --> 29:45.820 Bei diesen Begriffen sehen Sie, Breitband ist eben im Frequenz 29:45.820 --> 29:47.620 -Multiplexen, liegt dem zugrunde. 29:48.100 --> 29:50.700 Zeit-Multiplex ist interessant vom Algorithmus her, deswegen 29:50.700 --> 29:51.740 interessiert uns das auch mehr. 29:52.120 --> 29:53.340 Es ist eine Protokollfrage. 29:53.720 --> 29:56.520 Frequenz-Multiplex ist eine Nachrichtentechnik-Frage. 29:56.520 --> 29:59.580 Zeit-Multiplex ist eine Protokollfrage, eine Algorithmenfrage. 30:00.300 --> 30:04.000 Und hier unterscheiden wir zwischen synchronen Zeit-Multiplex 30:04.000 --> 30:06.960 -Verfahren und asynchronen Zeit-Multiplex-Verfahren. 30:07.540 --> 30:11.960 Synchron ist auch wieder sehr einfach, aber ineffizient. 30:12.540 --> 30:15.600 Synchron heißt, Sie haben N Teilnehmer. 30:16.820 --> 30:21.000 Und diese N Teilnehmer bekommen immer in der gleichen Reihenfolge die 30:21.000 --> 30:22.600 gleichen Zeitschlitze zugeteilt. 30:23.880 --> 30:28.220 Und das Verhalten ist dann eben ein synchrones, in der Form, dass 30:28.220 --> 30:30.900 jeder Teilnehmer weiß, ich muss so und so lange warten, dann bekomme 30:30.900 --> 30:32.680 ich wieder genau diese Zeitscheibe zugeteilt. 30:33.060 --> 30:35.020 Das ist das synchrone Verfahren. 30:35.580 --> 30:38.840 Und Sie können sich vorstellen, dass man sowas aufbrechen möchte, weil 30:38.840 --> 30:42.560 zum Beispiel der Teilnehmer oder viele Teilnehmer gar nichts zu senden 30:42.560 --> 30:42.780 haben. 30:42.840 --> 30:44.760 Die kriegen trotzdem die Zeitscheibe. 30:45.020 --> 30:47.700 Oder sie brauchen gar nicht so lange, bekommen trotzdem die 30:47.700 --> 30:48.100 Zeitscheibe. 30:48.100 --> 30:51.100 Das heißt, sie haben da eine Zuordnung von dem Medium, von dem 30:51.100 --> 30:53.960 wertvollen Medium und das wird nicht genutzt. 30:54.040 --> 30:57.660 Das ist ja genau das Ziel, dass man das möglichst effizient, möglichst 30:57.660 --> 30:59.280 umfassend nutzen möchte. 30:59.800 --> 31:03.860 Und das führt dann genau zu den asynchronen Zeit-Multiplex-Verfahren. 31:04.400 --> 31:08.080 Und hier unterscheiden wir zwischen diesem konkurrierenden Zugriff und 31:08.080 --> 31:09.600 kontrollierten Zugriff. 31:09.940 --> 31:14.560 Und wir werden gleich die vier hier behandelten Beispiele, die werden 31:14.560 --> 31:15.520 wir uns mal kurz anschauen. 31:15.520 --> 31:18.540 Wir fangen an mit dem ALOA, das ist also ein konkurrierender Zugriff. 31:18.720 --> 31:23.580 Und das ist so ungefähr nach dem Motto, viel einfacher und dümmer kann 31:23.580 --> 31:26.020 ich es nicht machen, im ALOA-Verfahren. 31:26.780 --> 31:31.200 Sie können an der Skizze sofort die wichtigsten Eigenschaften 31:31.200 --> 31:40.220 erkennen, die so aussehen, dass Sie N Sender haben, in dem Fall 5. 31:41.640 --> 31:45.700 Und jeder Sender, wenn er jetzt hier von der oberen Schicht... 31:45.700 --> 31:47.920 Sie müssen sich einmal vorstellen, wir sind in der Schicht 2. 31:48.620 --> 31:53.860 Und die Schicht 3, die Schicht 3-Instanz ist das hier, die sagt jetzt, 31:53.940 --> 31:59.260 ich möchte was auf dem Kanal senden, auf diesem gesicherten Kanal. 31:59.260 --> 32:03.320 Und gibt dem A die Information, gibt die Daten. 32:04.120 --> 32:10.580 Und die Station A fängt sofort an, hier einen Rahmen auf das Medium zu 32:10.580 --> 32:10.880 setzen. 32:11.360 --> 32:15.200 Hier ist es ein Medium, das ist kein Frequenzmultiplex, sondern dieses 32:15.200 --> 32:17.020 hier ist eigentlich ein Medium. 32:17.720 --> 32:21.120 Und die verwenden alle das gleiche Medium, also nicht irgendwelche 32:21.120 --> 32:24.700 Frequenzbänder, die da unterteilt sind, sondern die senden auf dem 32:24.700 --> 32:26.620 gleichen Frequenzband, auf dem gleichen Medium. 32:26.620 --> 32:31.200 Und Sie sehen, das macht dann B auch an der Stelle, bekommt ein 32:31.200 --> 32:35.200 bisschen später, das ist hier die Zeit, die hier läuft, bekommt ein 32:35.200 --> 32:38.260 bisschen später den Sendewunsch von Ihrer Schicht 3-Instanz. 32:38.740 --> 32:43.040 Und was passiert, wenn was auf dem Medium ist, wenn auf dem Medium 32:43.040 --> 32:46.700 gesendet wird, dann gibt es eine sogenannte Kollision. 32:47.240 --> 32:51.700 Die Rahmen kollidieren, die Rahmen überlagern sich mit dem Ergebnis, 32:52.320 --> 32:56.640 dass sie den gesamten Rahmen, also das ist hier eine Kollision, dass 32:56.640 --> 33:00.600 sie den gesamten Rahmen nicht mehr verwenden können. 33:02.520 --> 33:09.640 Das passiert immer wieder, immer dann, wenn mindestens zwei Stationen 33:09.640 --> 33:14.400 gleichzeitig dieses Medium verwenden und nur, wenn Sie das Glück 33:14.400 --> 33:19.840 haben, wie jetzt bei C, dass zufällig eben in dieser Zeit, in der der 33:19.840 --> 33:26.960 Rahmen gesendet wird, keine andere Station das Medium verwendet, dann 33:26.960 --> 33:31.860 kommen Sie ohne Kollision aus und Sie können den Rahmen sicher 33:31.860 --> 33:32.560 übertragen. 33:33.340 --> 33:39.580 Und Sie sehen schon an diesem Beispiel, dass das also durchaus großes 33:39.580 --> 33:43.860 Gefahrenspotenzial besteht, dass Sie hier in Kollision geraten und das 33:43.860 --> 33:48.560 nächste, was Sie sich überlegen, ist dann eben die Frage, wie können 33:48.560 --> 33:54.300 Sie die Kollisionswahrscheinlichkeit verringern, gegebenenfalls sogar 33:54.300 --> 33:55.420 ganz vermeiden. 33:55.580 --> 33:58.820 Wir schauen uns jetzt die Verringerung an, also wir lassen immer noch 33:58.820 --> 34:02.880 Kollisionen dann zu, aber die Wahrscheinlichkeit wird geringer und das 34:02.880 --> 34:05.440 führt, also hier sollte man noch sagen, Sie kommen zu wirklich 34:05.440 --> 34:11.320 schlechten Kanalauslastungen durch dieses Verfahren und genau diese 34:11.320 --> 34:16.180 Idee des ALOA-Verfahrens, die hat letztendlich zum ISONET-Verfahren 34:16.180 --> 34:16.620 geführt. 34:16.920 --> 34:20.600 Genau die Defizite, die man daran erkannt hat, die haben dazu geführt, 34:20.700 --> 34:24.680 dass man eben zu diesem CSM-ACD-Verfahren gekommen ist. 34:25.200 --> 34:31.540 CSM-ACD steht für Carrier Sense Multiple Access with Collision 34:31.540 --> 34:32.080 Detection. 34:32.080 --> 34:36.240 Da steckt eigentlich genau drin, was das Verfahren oder stecken alle 34:36.240 --> 34:37.680 Eigenschaften des Verfahrens drin. 34:38.720 --> 34:43.620 Die Idee ist die sehr einfach, wenn ich Kollisionen verringern, die 34:43.620 --> 34:46.780 Wahrscheinlichkeit verringern möchte, muss ich mich irgendwie mal 34:46.780 --> 34:50.780 schlau machen, ob vielleicht schon auf dem Kanal jemand sendet. 34:51.360 --> 34:56.280 Wenn ich das nämlich erreiche, wenn ich die Information bekomme, da 34:56.280 --> 35:01.840 sendet schon jemand auf dem Kanal und ich dann nicht sofort anfange zu 35:01.840 --> 35:07.460 senden, habe ich schon mal eine große Gefahrenquelle verringert oder 35:07.460 --> 35:09.400 eine Gefahrenquelle beseitigt. 35:09.480 --> 35:13.540 Ich habe es nicht ganz beseitigt, aber ich habe eine sehr viel 35:13.540 --> 35:14.620 geringere Wahrscheinlichkeit. 35:14.720 --> 35:16.660 Deswegen gibt es genau dieses Carrier Sense. 35:17.000 --> 35:21.460 Multiple Access, das können Sie an der Stelle mal ignorieren, das ist 35:21.460 --> 35:25.760 die Grundvoraussetzung oder die Vorgabe, mehrere greifen darauf zu. 35:25.760 --> 35:30.640 Aber das Carrier Sense, also ich höre den Kanal ab, bevor ich anfange 35:30.640 --> 35:31.700 zu senden. 35:31.760 --> 35:35.780 Das ist also eine ganz wichtige zusätzliche Eigenschaft von diesem 35:35.780 --> 35:37.960 Verfahren gegenüber dem ALOA-Verfahren. 35:38.520 --> 35:43.760 Aber, das werden wir gleich sehen, ich bin noch nicht ganz am Ende mit 35:43.760 --> 35:52.300 dem Verfahren, das liefert mir leider doch nicht als endgültiges 35:52.300 --> 35:59.060 Resultat, dass ich keine Kollisionen erhalte, sondern es verringert 35:59.060 --> 35:59.700 nur die Gefahr. 36:00.000 --> 36:03.980 Und das werden wir an der nächsten Folie eben sehen, ich komme 36:03.980 --> 36:07.100 vielleicht nochmal zu dieser zurück, aber an der kann man das 36:07.100 --> 36:07.480 erkennen. 36:08.480 --> 36:17.700 Das Problem ist, dass trotz des Hörens auf dem Medium die Gefahr 36:17.700 --> 36:22.980 besteht, dass eine Kollision entsteht, weil sich die Signale eben mit 36:22.980 --> 36:24.360 einer gewissen Zeit ausbreiten. 36:24.360 --> 36:34.540 Das heißt, in dieser Situation denkt die Station B, der Kanal ist 36:34.540 --> 36:40.180 frei, das Medium ist frei, aber er ist in Wirklichkeit nicht frei, 36:40.640 --> 36:47.980 weil dieses Signal, das vorher auf das Medium gesetzt worden ist, noch 36:47.980 --> 36:51.440 nicht bis zur Station B vorgedrungen ist. 36:51.440 --> 36:55.580 Und hier spielt genau diese Signallaufzeit, die wir ja schon 36:55.580 --> 36:59.360 eingeführt haben, die wichtigste Rolle. 37:00.080 --> 37:04.660 Die Signallaufzeit, die abhängig ist von der Signalgeschwindigkeit, 37:04.840 --> 37:08.500 das ist annähernd Lichtgeschwindigkeit, und von der Distanz zwischen 37:08.500 --> 37:10.080 Station A und B. 37:10.600 --> 37:12.540 Und das ist genau das kritische Intervall. 37:12.540 --> 37:16.940 Trotz Carrier Sense, trotz Abhören des Mediums, besteht die Gefahr, 37:17.720 --> 37:22.960 dass zwei Stationen quasi simultan das Senden beginnen und dann muss 37:22.960 --> 37:25.540 sich die Kollision irgendwie behandeln. 37:26.460 --> 37:31.380 Aber das Intervall ist natürlich sehr, sehr viel stärker verringert im 37:31.380 --> 37:35.560 Vergleich zum ALOA-Protokoll, bei dem ja das Konfliktintervall 37:35.560 --> 37:40.460 sozusagen die gesamte Zeit ist, weil nicht auf das Medium gehört 37:40.460 --> 37:40.980 worden ist. 37:40.980 --> 37:47.060 So, und jetzt tritt hier eben an der Stelle, die Station B meint, das 37:47.060 --> 37:51.300 Medium ist frei, fängt auch an zu senden, und an der Stelle kommt es 37:51.300 --> 37:55.480 eben zu Kollisionen, zu einer Kollision, zu einer Überlagerung der 37:55.480 --> 37:58.660 beiden Übertragungen. 37:58.660 --> 38:01.820 Und diese Kollision wird erkannt. 38:01.980 --> 38:04.320 Das ist eine relativ einfache Angelegenheit. 38:04.840 --> 38:10.280 Eine Überlagerung wird dadurch erkennbar, dass Sie eben falsch 38:10.280 --> 38:13.680 verlaufende Signalverläufe haben oder speziell verlaufende 38:13.680 --> 38:14.800 Signalverläufe haben. 38:15.220 --> 38:19.420 Das ist eine sehr einfache physikalische Schaltung, die Sie da eben in 38:19.420 --> 38:23.260 dem Transceiver, in diesem Ethernet-Element haben, um das 38:23.260 --> 38:24.340 weiterzuleiten. 38:24.340 --> 38:28.060 Und Sie müssen jetzt entsprechend in der höheren Schicht, also 38:28.060 --> 38:35.180 oberhalb dieses CSMA, oberhalb dieser Kollisionserkennungsschicht, 38:35.460 --> 38:36.660 müssen Sie Maßnahmen ergreifen. 38:37.360 --> 38:40.800 Eine Maßnahme ist, dass man eben jetzt ein Jamming-Signal schickt. 38:40.960 --> 38:44.800 Das ist im Grundsatz nur dafür da, dass das ganze Verfahren etwas 38:44.800 --> 38:45.900 effizienter abläuft. 38:46.240 --> 38:49.020 Aber Sie müssen eben diese Kollision auflösen. 38:49.820 --> 38:54.420 Und die Frage ist an der Stelle, wie gehen Sie da vor, um die 38:54.420 --> 38:55.580 Kollision aufzulösen? 38:56.720 --> 38:59.340 Das Vorgehen ist das folgende. 38:59.740 --> 39:02.600 Sie müssen sich für die Stationen, Sie haben jetzt ja mindestens zwei 39:02.600 --> 39:08.100 Stationen, die sozusagen sendewillig sind, aber deren Übertragung 39:08.100 --> 39:09.020 nicht funktioniert hat. 39:09.400 --> 39:15.540 Sie müssen dafür sorgen, dass diese Stationen eine Zeit lang warten 39:15.540 --> 39:17.080 mit ihrem Senden. 39:17.080 --> 39:19.780 Sie müssen auf jeden Fall mal die beiden Stationen entzerren. 39:20.400 --> 39:22.640 Das Schlimmste, was passieren kann oder der größte Fehler, den Sie 39:22.640 --> 39:25.120 machen können in der Situation, ist, dass Sie beide wieder 39:25.120 --> 39:28.680 gleichzeitig zum Start schicken und beide fangen dann wieder an zu 39:28.680 --> 39:28.960 senden. 39:29.020 --> 39:30.920 Dann fangen Sie wieder quasi simultan an zu senden. 39:31.240 --> 39:34.880 Sie müssen also dafür sorgen, dass sozusagen eine Wartezeit für die 39:34.880 --> 39:39.020 Stationen gewählt wird, die insbesondere die Eigenschaft hat, dass sie 39:39.020 --> 39:39.840 unterschiedlich sind. 39:39.840 --> 39:44.260 Dass sie sozusagen beim nächsten Mal dafür garantieren können oder mit 39:44.260 --> 39:47.880 einer hohen Wahrscheinlichkeit garantieren können, dass diese Station 39:47.880 --> 39:50.620 nicht wieder quasi simultan beginnt zu senden. 39:52.080 --> 39:57.560 Das Verfahren, das hier im Ethernet realisiert wird, heißt Truncated 39:57.560 --> 39:59.180 Binary Backoff Algorithmus. 39:59.540 --> 40:02.780 Das ist also ein Algorithmus, der die Wartezeit bestimmt. 40:02.780 --> 40:06.720 Und in diesem Algorithmus ist eine ganz interessante, sehr einfache, 40:06.820 --> 40:11.600 aber ganz interessante Technik eingebaut. 40:12.200 --> 40:20.140 Nämlich, die Stationen zählen mit, wie häufig sie immer wieder in eine 40:20.140 --> 40:21.600 Kollision gekommen sind. 40:21.840 --> 40:24.980 Also nicht wie häufig sie absolut in eine Kollision gekommen sind, 40:25.100 --> 40:29.180 sondern mit diesem Datum, mit diesem Paket, das sie senden wollen. 40:29.180 --> 40:31.840 Wie viele wiederholte Kollisionen sind aufgetreten? 40:32.800 --> 40:38.840 Und je mehr Kollisionen wiederholt auftreten, umso länger warten sie. 40:39.920 --> 40:40.640 Zufällig. 40:41.760 --> 40:45.980 Nämlich, je mehr Kollisionen wiederholt auftreten, umso höher ist 40:45.980 --> 40:48.960 voraussichtlich die gesamte Netzlast. 40:48.960 --> 40:52.440 Und das Schlimmste, was sie tun können, wenn sie eh eine hohe Netzlast 40:52.440 --> 40:55.680 haben, ist, wenn alle Stationen, die in Kollision geraten sind, immer 40:55.680 --> 40:57.240 wieder das Netz belasten. 40:57.800 --> 40:59.080 Sie wollen das also entzerren. 40:59.680 --> 41:02.180 Das heißt, sie wollen einen Mechanismus einbauen, der dafür sorgt, 41:02.880 --> 41:04.060 jetzt haben wir eine hohe Netzlast. 41:04.640 --> 41:08.340 Und in diesem CSMACD-Verfahren, das fängt an, sich sozusagen 41:08.340 --> 41:11.820 zurückzuziehen, das Netz nicht vollkommen zuzumachen, sondern eben 41:11.820 --> 41:16.240 ganz im Gegenteil verzögert zu übertragen, beziehungsweise länger zu 41:16.240 --> 41:16.520 warten. 41:16.520 --> 41:20.860 Und das ist ein sehr, sehr einfacher Algorithmus, sehr, sehr einfach 41:20.860 --> 41:23.080 zu implementieren, kostet praktisch nichts. 41:23.760 --> 41:27.200 Da gehe ich jetzt nicht im Detail drauf ein, aber es ist fast 41:27.200 --> 41:28.380 geschenkt, dieser Algorithmus. 41:28.800 --> 41:33.860 Und der hat dazu geführt, dass das Ethernet an der Stelle stabil 41:33.860 --> 41:35.520 geblieben ist. 41:35.720 --> 41:40.580 Man hat nicht geglaubt, wo man mit dem Ethernet begonnen hat, sind 41:40.580 --> 41:43.920 Modelle gemacht worden, mathematische Modelle, Verkehrsmodelle gemacht 41:43.920 --> 41:44.200 worden. 41:44.200 --> 41:48.100 Man ist immer davon ausgegangen, bei einer Netzlast von sagen wir mal 41:48.100 --> 41:55.280 30%, also wenn 30% dieser 10 Megabit pro Sekunde angefordert werden 41:55.280 --> 41:57.880 von den Stationen, dann geht das Ethernet in die Knie. 41:58.340 --> 42:00.660 Das wird nicht funktionieren, das wird sehr schnell kollabieren. 42:02.680 --> 42:06.920 Faktum ist, dass Sie ein Ethernet mit 80 bis 90% fahren können, ohne 42:06.920 --> 42:09.740 dass es kollabiert, es bleibt also stabil. 42:09.740 --> 42:12.580 Genau dieser Truncated Binary Backoff-Algorithmus sorgt dafür. 42:13.180 --> 42:17.020 Das heißt, die Stationen werden immer wieder durch diese, wenn sie in 42:17.020 --> 42:19.980 zwei, drei Kollisionen nacheinander geraten, werden sie immer weiter 42:19.980 --> 42:22.640 zurückgezogen mit ihrem Senden. 42:23.100 --> 42:27.400 Das Netz erholt sich, das sind sehr, sehr schnelle Vorgänge und kann 42:27.400 --> 42:32.560 wieder sozusagen die Netzlast nach oben gehen. 42:32.560 --> 42:38.400 Das heißt, sie haben sozusagen so einen Zustand des Einschwingens und 42:38.400 --> 42:42.580 der Effekt ist, sie können bis zu 90% an Ethernet auslasten oder 80%. 42:42.580 --> 42:45.740 Hängt natürlich von Verkehrsprofilen ab, aber die Verkehrsprofile sind 42:45.740 --> 42:49.320 so in der Realität, dass sie also diesem Verfahren auch sehr stark 42:49.320 --> 42:50.240 entgegenkommen. 42:50.600 --> 42:54.140 Eine sehr interessante Angelegenheit, haben also vor 10 bis 15 Jahren 42:54.140 --> 42:57.160 viele Leute ihre Promotionen und wissenschaftliche Arbeiten darüber 42:57.160 --> 42:57.520 geschrieben. 42:57.520 --> 42:59.780 Ist ja sehr viel Mathematik auch dahinter, sehr viel 42:59.780 --> 43:04.300 Simulationsarbeit, die man sich vorstellen kann und die wurde auch 43:04.300 --> 43:04.880 ausgeführt. 43:05.140 --> 43:10.580 Fakt ist aber, dass dieses Verfahren sehr hohe, also sehr gute 43:10.580 --> 43:11.360 Ergebnisse liefert. 43:11.680 --> 43:12.820 Erstaunlich gute Ergebnisse. 43:13.740 --> 43:17.720 Und das führt dazu, dass wir heute im Bereich der lokalen Netze nicht 43:17.720 --> 43:21.020 nur diese 10 Megabit pro Sekunde Ethernet-Varianten haben, die hier 43:21.020 --> 43:22.600 nochmal aufgeführt sind. 43:22.600 --> 43:26.560 Ich habe schon die verschiedenen Varianten schon zumindest mal 43:26.560 --> 43:27.000 genannt. 43:27.540 --> 43:33.980 Hier haben wir den wichtigen Übergang von der Busstruktur zur 43:33.980 --> 43:34.780 Sternstruktur. 43:36.040 --> 43:39.080 Also hier haben wir jetzt genau dieses 10BaseT, das arbeitet eben mit 43:39.080 --> 43:43.040 Hubs, mit entweder Twisted Pair Hubs oder Glasfaser Hubs. 43:44.320 --> 43:47.940 Wir haben an der Stelle mit dem dicken Koaxialkabel begonnen. 43:49.080 --> 43:54.120 Da können wir uns Segmentlängen bis maximal 500 Meter leisten, bevor 43:54.120 --> 43:58.380 wir wieder einen Repeater dazuschalten müssen, der dann das Wieder 43:58.380 --> 43:59.920 -Auffrischen des Signals durchführt. 44:00.300 --> 44:03.020 Beim SYN Ethernet, da sparen wir ein bisschen an dem Kabel. 44:03.440 --> 44:07.620 Da müssen wir nach 200 Meter schon einen Repeater einsetzen, um das 44:07.620 --> 44:09.660 Kabel, um das Signal aufzufrischen. 44:09.660 --> 44:13.580 Und beim 10BaseT und 10BaseF habe ich eine ganz andere Struktur. 44:13.680 --> 44:17.440 Da habe ich, wie gesagt, diesen Hub in der Mitte und ich kann 44:17.440 --> 44:22.100 sternförmig diese Ethernet-Stationen daran verbinden. 44:23.160 --> 44:26.560 Das ist auch eine Ethernet-Station und so weiter. 44:27.420 --> 44:30.620 Und ich kann dann eben auch die Hubs verbinden, dass ich eben zu 44:30.620 --> 44:34.640 solchen, wie gerade gezeigten, hierarchischen Strukturen komme. 44:34.640 --> 44:38.480 Der Vorteil von der, man sollte jetzt irgendwie meinen, diese Hub 44:38.480 --> 44:41.080 -Struktur, das ist ja irgendwie äußerst aufwendig. 44:41.140 --> 44:43.800 Ich habe jetzt elektronische Komponenten auf einmal drin, ich habe 44:43.800 --> 44:47.460 Koppelelemente in meinem Netzaufbau mit enthalten, das ist richtig. 44:48.020 --> 44:54.880 Es ist auch durchaus eine nicht unbedingt billigere Technologie, nur 44:54.880 --> 44:58.340 Sie haben mit dieser Hub-Technologie einen riesen Vorteil des 44:58.340 --> 44:58.900 Managements. 44:58.900 --> 45:05.600 Sie haben zwei große Vorteile, Sie können die Netz-Topologie auf Ihre 45:05.600 --> 45:10.020 Unternehmensstruktur sehr viel besser abbilden, auf Ihre 45:10.020 --> 45:11.620 Gebäudestruktur insbesondere. 45:11.840 --> 45:15.840 Stellen Sie sich vor, Sie müssen ein endstöckiges Gebäude verkabeln, 45:16.500 --> 45:18.980 ist mit der Hub-Technologie wunderbar zu machen. 45:19.140 --> 45:24.120 Sie haben eben auf einer Etage, setzen Sie beispielsweise ein oder 45:24.120 --> 45:28.320 zwei Hub-Systeme an, also zwei Sterne oder einen Stern und können 45:28.320 --> 45:30.740 entsprechend dann die Stockwerke über diese Hubs dann auch 45:30.740 --> 45:32.000 entsprechend verkabeln. 45:32.480 --> 45:35.580 Das ist der eine große Vorteil, also Sie können sehr viel besser diese 45:35.580 --> 45:37.880 Struktur an die Gegebenheiten anpassen. 45:38.220 --> 45:41.400 Und der zweite, noch größere Vorteil ist, Sie erkennen sofort 45:41.400 --> 45:42.460 Ausfälle. 45:42.700 --> 45:44.740 Das Management ist ein großer Vorteil. 45:45.160 --> 45:49.400 Beim 10Base-5, 10Base-2-Isolator kann es Ihnen durchaus passieren und 45:49.400 --> 45:52.980 das ist jetzt nicht irgendwie theoretisch, sondern sehr praktisch. 45:52.980 --> 45:57.500 Eine Station hat einen Defekt, hat einen Schaden, führt dazu, dass 45:57.500 --> 46:01.560 gegebenenfalls das gesamte Isonet zum Ausfall kommt, dass Sie gar 46:01.560 --> 46:02.360 nichts mehr machen können. 46:03.800 --> 46:07.920 Das Fehlerverfolgen ist extrem aufwendig, ist extrem schwierig, das 46:07.920 --> 46:08.760 dann zu finden. 46:09.620 --> 46:12.540 Bei den Hubs haben Sie einen ganz großen Vorteil, das sind aktive 46:12.540 --> 46:17.100 Komponenten, in der Form, dass die eben an den entsprechenden Stellen 46:17.100 --> 46:19.240 Checks durchführen können. 46:19.240 --> 46:23.020 Also was macht hier die Isonet-Station an diesen Stellen und die 46:23.020 --> 46:25.340 können diese Isonet-Station automatisch abschalten. 46:26.480 --> 46:30.900 Das wird natürlich gemeldet, an der Stelle ist ein Netzausfall über 46:30.900 --> 46:34.580 eine entsprechende Netzmanagement-Plattform, aber Sie können dafür 46:34.580 --> 46:37.560 sorgen, dass Sie sozusagen diesen Fehler wirklich von dem gesamten 46:37.560 --> 46:39.020 Netz abkoppeln. 46:39.020 --> 46:43.920 Und das hat sich in der Praxis als einen riesen Vorteil erwiesen. 46:44.460 --> 46:47.940 Deswegen geht man eben heute zu diesen Strukturen über mit diesen 46:47.940 --> 46:48.540 Sternkopplern. 46:49.460 --> 46:52.400 Und da geht es dann weiter, ich habe Ihnen schon gesagt, dass wir eben 46:52.400 --> 46:56.580 jetzt hier, Sterntopologie ist sozusagen die grundlegende 46:56.580 --> 47:02.820 Netztopologie und wir haben durch verschiedene Tricks, da muss man 47:02.820 --> 47:06.300 auch ein bisschen was in den Verfahren durchführen, ich bin nicht auf 47:06.300 --> 47:07.740 Konfliktparameter eingegangen. 47:07.740 --> 47:10.920 Beim CSMA-CD muss man ein bisschen aufpassen. 47:11.520 --> 47:15.140 Aber Sie schaffen es, nicht nur von der Anschlusstechnologie und von 47:15.140 --> 47:17.880 der Medientechnologie, sondern eben auch von den Algorithmen her, von 47:17.880 --> 47:22.000 den Verfahren her, das auf 100 Megabit pro Sekunde zu betreiben. 47:22.460 --> 47:25.620 Und das ist jetzt, sagen wir mal, eine Ebene, mit der man noch einige 47:25.620 --> 47:27.280 Jahre ganz gut leben kann. 47:27.680 --> 47:33.140 Also 100 Megabit pro Sekunde ist eigentlich so die normale 47:33.140 --> 47:34.040 Anschlusstechnik. 47:35.600 --> 47:38.700 Weiter hinaus mache ich mal keine Aussagen, ob wir da wirklich dann 47:38.700 --> 47:42.660 das Ethernet auch noch im Gigabit-Bereich betreiben. 47:43.000 --> 47:45.700 Da kann heute eigentlich noch keiner genau was zu sagen. 47:45.820 --> 47:49.220 Da käme dann eher auch sowas wie FTDI oder solche Technologie wieder 47:49.220 --> 47:50.220 zum Forschen. 47:50.280 --> 47:54.540 Aber das ist für die nächsten Jahre, ist das das gängige Prinzip. 47:54.960 --> 47:59.180 Und diese Technologien, da verdienen sich die Firmen oder haben sich 47:59.180 --> 48:03.680 die Firmen zumindest ganz gut mitverdient, weil die sich wirklich 48:03.680 --> 48:05.000 durchgesetzt haben in der Praxis. 48:06.340 --> 48:12.000 So, kommen wir noch zu anderen Verfahren, die eher jetzt 48:12.000 --> 48:18.400 Zusatzinformationen liefern, die nicht mehr so stark gebraucht werden. 48:18.540 --> 48:23.060 Auch in Spezialkonfigurationen findet man beispielsweise diesen 48:23.060 --> 48:27.040 kontrollierten Zugriff mit Aufforderungsbetrieb, kann man relativ 48:27.040 --> 48:27.840 schnell abhandeln. 48:29.040 --> 48:32.460 Das Ethernet oder diese CSMA-CD-Struktur hat ja die Eigenschaft, 48:32.620 --> 48:33.980 vollständig dezentral zu sein. 48:34.080 --> 48:39.060 Sie haben keine einzige steuernde Station, keine Station, die mehr 48:39.060 --> 48:40.720 Rechte hat als eine andere Station. 48:40.840 --> 48:43.960 Also vollständig dezentral, das ist die wesentliche Eigenschaft. 48:44.460 --> 48:49.540 Und genau das Gegenteil findet hier statt mit dieser Leitstation, die 48:49.540 --> 48:53.440 sozusagen die volle Steuerung über das lokale Netz hat. 48:54.240 --> 48:55.940 Sie haben auch eine Busstruktur, wie Sie sehen. 48:55.940 --> 49:00.160 Aber wenn jetzt die Stationen den Bus in Anspruch nehmen wollen, 49:00.560 --> 49:03.300 müssen sie immer über die Leitstation gehen. 49:03.800 --> 49:05.300 Es sieht sogar genau andersrum aus. 49:05.400 --> 49:07.120 Die Leitstation hat so eine Polling-Tabelle. 49:08.120 --> 49:12.940 Also hat so eine Tabelle, in der sie reinschreibt, wer als nächstes 49:12.940 --> 49:14.480 den Bus in Anspruch nehmen darf. 49:14.940 --> 49:19.520 Und die ganzen Stationen, die hier angeschlossen sind, die werden 49:19.520 --> 49:21.000 gemäß dieser Tabelle gepollt. 49:21.080 --> 49:23.420 Das sehen Sie eben genau hier an diesen Pfeilen. 49:23.420 --> 49:30.180 Die erhalten sozusagen eine Aufforderung, den Bus in Anspruch zu 49:30.180 --> 49:30.380 nehmen. 49:30.560 --> 49:34.440 Die können gar nicht selber aktiv werden, sondern sie müssen sozusagen 49:34.440 --> 49:36.220 gemäß dieser Tabelle werden die gesteuert. 49:43.840 --> 49:46.660 Weil sie die Polling-Tabelle ändern können, deswegen. 49:47.100 --> 49:49.660 Weil da sozusagen eine Dynamik drin ist, das ist richtig. 49:49.800 --> 49:53.440 Also die Frage ist, warum das als asynchron bezeichnet wird. 49:53.440 --> 49:58.980 Das hängt damit zusammen, dass diese Polling-Tabelle geändert werden 49:58.980 --> 49:59.420 kann. 49:59.640 --> 50:00.620 Die ist also nicht stabil. 50:06.610 --> 50:07.890 Genau, da kommen wir gleich dazu. 50:08.230 --> 50:08.810 Beim Tokenring. 50:09.090 --> 50:10.390 Da sieht es nochmal ganz anders aus. 50:10.790 --> 50:12.230 Da haben wir auch ein asynchrones Verfahren. 50:13.690 --> 50:15.970 Und zwar, gut, kann ich gleich behandeln mit dem Tokenring. 50:16.750 --> 50:19.630 Wenn wir gleich sehen, das ist ein Token, das eben um den Ring 50:19.630 --> 50:20.250 wandert. 50:20.250 --> 50:25.770 Da haben wir die Asynchronität deswegen, weil im Regelfall die 50:25.770 --> 50:27.970 Stationen den Token einfach durchlaufen lassen. 50:28.270 --> 50:32.590 Und nur dann vom Netz nehmen, wenn sie wirklich einen Sendewunsch 50:32.590 --> 50:32.870 haben. 50:33.150 --> 50:35.050 Dann bekommen sie diese Asynchronität rein. 50:41.030 --> 50:42.490 Ja, das ist genau der Tokenring. 50:42.830 --> 50:45.270 Das ist genau das, was wir gerade schon angefangen haben. 50:45.550 --> 50:48.850 Ist auch ein IEEE-Norm, 802.5. 50:49.990 --> 50:54.310 Ein paar Aspekte, die wir hier vielleicht vertiefen könnten. 50:55.090 --> 50:57.550 Wir haben eben eine Punkt-zu-Punkt-Verbindung. 50:58.410 --> 51:00.690 Der Ring besteht aus Punkt-zu-Punkt-Verbindung. 51:01.390 --> 51:06.190 Es ist also nicht so, dass die so dran hängen, dass wir die eine 51:06.190 --> 51:08.410 Alternative, sondern es ist so. 51:09.310 --> 51:17.970 Also es sind wirklich aktiv, die Information läuft aktiv durch die 51:17.970 --> 51:18.410 Knoten. 51:18.750 --> 51:19.510 Das ist also der Unterschied. 51:19.810 --> 51:23.670 Wenn Sie so eine Situation hätten, müssten Sie sich überlegen, wie Sie 51:23.670 --> 51:26.610 die Auffrischung gegebenenfalls realisieren können. 51:27.130 --> 51:29.070 Oder müssen, von dem Signal. 51:29.490 --> 51:33.990 Wenn der Ring zu groß wird, dann müssen Sie da auch noch irgendeine 51:33.990 --> 51:36.650 aktive Komponente hier vorsehen. 51:36.650 --> 51:41.650 Die Information läuft durch die am Turkenring angeschlossenen 51:41.650 --> 51:42.270 Elemente. 51:42.270 --> 51:45.650 Hier haben wir auch eine Verzögerung von dem Datenfluss. 51:46.370 --> 51:49.950 Also wir haben eine Ein-Bit-Verzögerung, die wir mit einbeziehen 51:49.950 --> 51:50.250 müssen. 51:50.590 --> 51:55.170 Das heißt, nicht mit Lichtgeschwindigkeit wandert hier das Paket oder 51:55.170 --> 51:59.430 der Rahmen um diesen Ring herum, sondern mit entsprechenden 51:59.430 --> 52:01.730 Verzögerungszeiten, mit Verarbeitungszeiten. 52:03.950 --> 52:09.810 Wir unterscheiden jetzt grundsätzlich zwischen zwei Arten von Rahmen, 52:10.350 --> 52:12.590 die auf dem Ring laufen. 52:13.250 --> 52:17.450 Der eine Rahmen ist der Token, das ist ein sehr kurzer Rahmen, wie wir 52:17.450 --> 52:18.270 gleich sehen werden. 52:19.090 --> 52:20.670 Und das andere ist ein Datenrahmen. 52:20.670 --> 52:29.830 Und wenn ein Tokenrahmen auf dem Ring sich befindet und bei einer 52:29.830 --> 52:35.830 Station ankommt, die sendewillig ist, dann kann diese Station, dann 52:35.830 --> 52:40.070 wird diese Station den Token umwandeln in einen Datenrahmen. 52:41.850 --> 52:43.970 Das ist also der Aspekt. 52:44.810 --> 52:49.490 Immer wenn ein Tokenrahmen auf dem Ring sich befindet, ist der Ring 52:49.490 --> 52:50.410 sozusagen frei. 52:51.370 --> 52:54.650 Wenn sich ein Datenrahmen auf dem Ring befindet, ist der Ring besetzt. 52:56.470 --> 53:01.990 Und die Station, die jetzt den Rahmen erhält, wird sich als erstes 53:01.990 --> 53:05.170 fragen, ist das ein Tokenrahmen oder ist das ein Datenrahmen? 53:05.170 --> 53:08.370 Wenn es ein Tokenrahmen ist und ich habe etwas zu senden, dann mache 53:08.370 --> 53:09.530 ich daraus einen Datenrahmen. 53:09.670 --> 53:12.210 Dann benutze ich den Ring zum Senden. 53:13.010 --> 53:16.910 Ist es ein Datenrahmen, muss ich mir die Empfängeradresse anschauen 53:16.910 --> 53:21.530 und schauen, ob das gegebenenfalls Daten sind, die für mich bestimmt 53:21.530 --> 53:21.810 sind. 53:21.930 --> 53:23.850 Oder ist das vielleicht sogar eine Broadcast Message? 53:24.730 --> 53:30.890 Das wäre dann eben für alle Stationen am Ring, die diese Informationen 53:30.890 --> 53:31.350 bekommen. 53:31.350 --> 53:34.850 Das können wir uns gleich mal anschauen. 53:34.990 --> 53:40.770 Was hier ein Problem ist, sind die vielen, vielen Fehlerfälle, die 53:40.770 --> 53:41.610 auftreten können. 53:41.990 --> 53:46.690 Das wirkt jetzt im Moment nicht komplizierter als das CSMACD 53:46.690 --> 53:48.370 -Verfahren, ist es aber. 53:48.810 --> 53:51.870 Also in der Praxis hat sich das gezeigt, dass Sie viel mehr 53:51.870 --> 53:56.690 Fehlerfälle mit diesem Verfahren sich einfangen und behandeln müssen. 53:56.690 --> 54:02.350 Sie können, im Vergleich zu dieser Problematik, wie ich das beim 54:02.350 --> 54:05.170 Binary Backoff Algorithmus gesagt habe, Sie haben Probleme mit dieser 54:05.170 --> 54:09.630 Netzlast beim Ethernet gehabt und Sie haben ein ganz einfaches 54:09.630 --> 54:14.550 Minimalverfahren, um dieses Problem, dieses massive Problem in den 54:14.550 --> 54:15.230 Griff zu bekommen. 54:15.750 --> 54:17.410 Bei dem Tokenring ist es genau andersrum. 54:18.070 --> 54:21.070 Sie meinen, Sie haben so lauter kleine Probleme, die müssten doch 54:21.070 --> 54:24.630 eigentlich gelöst werden und die erweisen sich dann bezüglich der 54:24.630 --> 54:26.130 Realisierung als Riesenprobleme. 54:26.730 --> 54:33.210 Also man will ja nicht meinen, dass das Problem, zwei Tokens zu haben 54:33.210 --> 54:36.530 auf dem Ring, das wirkt auch so theoretisch, das wirkt so 54:36.530 --> 54:41.530 theorielastig, wenn dann zwei Tokens um den Ring herummarschieren. 54:42.050 --> 54:42.930 Das passiert. 54:43.390 --> 54:44.430 Oder der Token geht verloren. 54:45.070 --> 54:45.650 Das passiert. 54:46.450 --> 54:47.490 Und zwar gar nicht so selten. 54:48.590 --> 54:52.170 Und das Thema oder das Problem ist jetzt, wie kriege ich das in den 54:52.170 --> 54:52.410 Griff? 54:53.530 --> 54:55.890 Erstmal muss ich mir überlegen, welche Verfahren brauche ich? 54:55.970 --> 54:58.630 Also das ist das Tokenmanagement und wie realisiere ich das? 54:58.790 --> 55:02.650 Und was ganz interessant ist, was ich als ganz interessant empfunden 55:02.650 --> 55:07.010 habe, als ich das das erste Mal genauer mir betrachtet habe, jeder 55:07.010 --> 55:10.630 dieser Stationen hat das gesamte Tokenmanagement, kann sozusagen 55:10.630 --> 55:11.710 Tokenmanager spielen. 55:12.570 --> 55:14.490 Also dann die Frage, wer ist denn Tokenmanager? 55:14.490 --> 55:17.350 Sie können ja auch nicht mehrere Tokenmanager haben, die kommen ja 55:17.350 --> 55:18.110 dann auch in einen Konflikt. 55:18.630 --> 55:20.870 Sie müssen ja dann auch ein Verfahren haben, wer ist denn jetzt der 55:20.870 --> 55:21.790 nächste Tokenmanager? 55:22.210 --> 55:25.030 Also die Station, die das Tokenmanagement durchführt, haben sie wieder 55:25.030 --> 55:27.190 eine Verkomplizierung von dem ganzen Verfahren. 55:27.930 --> 55:31.550 Und zum Schluss endet man darin, dass jeder im Grundsatz Tokenmanager 55:31.550 --> 55:34.090 sein kann und sie müssen sich eben einen Algorithmus überlegen, ein 55:34.090 --> 55:38.070 Verfahren überlegen, wie sie dieses in einem bestimmten Fall, wenn 55:38.070 --> 55:40.730 dieser Fall auftritt, wem sie das Tokenmanagement übergeben. 55:40.730 --> 55:43.390 Das heißt, sie haben ziemlich viele Komplexitäten in diesem 55:43.390 --> 55:48.690 grundsätzlich einfachen Verfahren enthalten, die dazu führen, dass die 55:48.690 --> 55:52.230 ganze Geschichte eben relativ uninteressant ist. 55:54.790 --> 55:58.390 Der eigentliche Vorteil, den man mit dem Tokenring gesehen hat, war, 55:58.910 --> 56:02.390 dass man Realzeitanforderungen erfüllen kann. 56:02.490 --> 56:07.130 In der Form, man kann die maximale Wartezeit mit diesem Verfahren 56:07.130 --> 56:07.790 vorherbestimmen. 56:07.790 --> 56:08.950 Das ist im Grundsatz richtig. 56:09.830 --> 56:12.270 Modulo der Fehlerfälle, die da auftreten können. 56:12.430 --> 56:14.410 Also wenn irgendwie da was schiefläuft, dann können sie das auch nicht 56:14.410 --> 56:14.670 machen. 56:15.070 --> 56:16.910 Beim Isernet können sie eigentlich gar nichts vorhersagen. 56:17.110 --> 56:19.730 Da haben sie ein vollständig nicht deterministisches Verhalten. 56:20.670 --> 56:24.550 Hier können sie die maximalen Wartezeiten zumindest vorhersagen, aber 56:24.550 --> 56:27.010 das hat dann auch nicht so wahnsinnig viel gebracht. 56:27.290 --> 56:30.750 Also Fakt ist, dass heute Isernet in Realzeitumgebungen eingesetzt 56:30.750 --> 56:34.570 wird und man sozusagen dieses Restrisiko eingeht, das aber sehr gering 56:34.570 --> 56:34.790 ist. 56:34.790 --> 56:38.990 Gut, schauen wir uns mal kurz den Verlauf an von dem Tokenring. 56:39.770 --> 56:41.090 Hier sehen Sie das Freitoken. 56:41.470 --> 56:45.430 Hier sehen Sie also einen Rahmen, einen sehr kleinen Rahmen, wie wir 56:45.430 --> 56:47.830 dann gleich sehen werden, der eben hier auf dem Ring verläuft. 56:49.350 --> 56:51.770 Jetzt kommt das bei der Station A vorbei. 56:52.570 --> 56:55.330 A hat einen Sendewunsch, das heißt wieder, Sie können sich hier oben 56:55.330 --> 56:59.230 die IP-Schicht irgendwie überlegen, die möchte auf der Schicht 2 56:59.230 --> 57:00.350 datenlos werden. 57:00.350 --> 57:06.950 Und wir haben gesagt, sobald hier ein Freitoken, also dieses Token, 57:06.970 --> 57:12.790 vorbeikommt, kann die sendewillige Station dieses Token umwandeln in 57:12.790 --> 57:17.030 einen Belegtoken, das heißt es ist ein Datenrahmen, der jetzt auf dem 57:17.030 --> 57:18.230 Ring verläuft. 57:18.850 --> 57:24.330 Und entsprechend soll jetzt hier angedeutet werden, dass das für C 57:24.330 --> 57:28.390 bestimmt ist, dass also hier eine Kommunikation zwischen A und C 57:28.390 --> 57:30.330 durchgeführt wird. 57:30.330 --> 57:39.330 C erkennt das daran, dass es eben die Information in dem Belegtoken, 57:39.970 --> 57:44.290 also in dem Datenrahmen durchgeht und die Empfängeradresse erkennt und 57:44.290 --> 57:52.590 nimmt diese Information vom Netz und ergänzt hier eine Information, 57:53.370 --> 57:56.430 ich habe die Information vom Netz genommen, ich habe sie bekommen, 57:56.750 --> 58:00.130 also sozusagen eine Empfangsbestätigung, die hier enthalten ist. 58:01.130 --> 58:07.290 Das ist die Empfangsbestätigung von C, das ist genau diese sozusagen 58:07.290 --> 58:10.810 Quittungsnummer, wenn Sie so wollen, oder das Acknowledge, das eben 58:10.810 --> 58:15.590 hiermit enthalten ist und A erkennt eben diese Empfangsbestätigung und 58:15.590 --> 58:20.030 hat damit die Information, C hat die Information bekommen und es geht 58:20.030 --> 58:21.130 mit dem Freitoken weiter. 58:21.630 --> 58:24.850 Was hier jetzt nicht gut angedeutet ist, aber wir haben es ja gerade 58:24.850 --> 58:29.250 gesagt, das geht wirklich hier durch. 58:29.530 --> 58:32.310 Die sind aktiv am Netz angeschlossen, die Komponenten. 58:32.770 --> 58:34.690 Das ist also noch ein wichtiger Aspekt. 58:36.810 --> 58:42.910 Gut, das sind also die verschiedenen Übertragungsverfahren der 58:42.910 --> 58:48.150 Mehrfachnutzung und jetzt kommen wir zur Strukturierung der 58:48.150 --> 58:49.110 Datenübertragung. 58:49.210 --> 58:52.290 Jetzt kommt ein Abschnitt, wo Sie mal ein paar PDUs sehen. 58:54.370 --> 58:55.290 Einige Protokolldateneinheiten. 58:55.810 --> 58:59.630 Wir schauen uns jetzt eben die Schicht 2 PDUs von Ethernet, Tokenring 58:59.630 --> 59:04.630 und HDLC an und behandeln dann, gehen dann über in, wenn wir uns das 59:04.630 --> 59:06.790 HDLC betrachten, zur Codetransparenz. 59:06.910 --> 59:09.870 Das ist eigentlich die erste Protokollfunktion, die wir da betrachten. 59:10.350 --> 59:12.970 So, schauen wir uns mal das Paketformat vom Ethernet an. 59:13.910 --> 59:17.370 Dann werden wir einige Dinge wiedererkennen, die wir schon behandelt 59:17.370 --> 59:17.630 haben. 59:17.750 --> 59:22.430 Also diese Synchronisationszeichen am Anfang, zur Aufsynchronisation 59:22.430 --> 59:24.570 des Empfängers, sehen wir hier. 59:24.950 --> 59:27.930 Dann haben wir so einen Startdelimiter, der eben dadurch 59:27.930 --> 59:32.250 gekennzeichnet ist, dass er zwei aufeinanderfolgende Einsen am Ende 59:32.250 --> 59:33.370 aufweist. 59:33.950 --> 59:36.030 Das erinnert so ein bisschen an das Startbit. 59:36.970 --> 59:39.470 Hat auch so ungefähr diese Eigenschaft. 59:40.590 --> 59:45.250 Und das sind immerhin schon 64 Bit, die wir hier auf die Reise 59:45.250 --> 59:45.910 geschickt haben. 59:46.450 --> 59:52.830 Dann kommen die Adressen, die wir ja in jeder Schicht 2 benötigen, von 59:52.830 --> 59:55.530 wem kommt es, an wen wird es geschickt. 59:55.630 --> 59:57.150 Das sind eben die MAC-Adressen. 59:57.850 --> 01:00:01.690 Hier gibt es einen kleineren Adressraum und einen größeren Adressraum. 01:00:02.250 --> 01:00:08.770 Nämlich es gibt 16 Bit, also ein 2-Byte und 6-Byte-Formate, die wir 01:00:08.770 --> 01:00:13.770 vorsehen können, je nachdem, wie groß der Adressraum ist, den wir eben 01:00:13.770 --> 01:00:14.610 benötigen. 01:00:14.930 --> 01:00:16.530 Heutzutage brauchen wir eher größere. 01:00:16.530 --> 01:00:20.110 Deswegen haben wir diese 6-Byte-Ergänzung hier vorgenommen. 01:00:20.470 --> 01:00:22.710 Ursprünglich waren das 16 Bit nur, also nur 2 Byte. 01:00:23.670 --> 01:00:26.190 Aber es ist dann eben noch vergrößert worden. 01:00:26.590 --> 01:00:29.770 Dann sehen wir auch wieder einen Aspekt, den wir schon beim 01:00:29.770 --> 01:00:31.830 Alternating -Bit-Protokoll festgestellt haben. 01:00:32.150 --> 01:00:37.330 Wir müssen eine Länge angeben, damit die Empfangende Station weiß, 01:00:37.790 --> 01:00:39.310 wann hört denn das Datenfeld auf. 01:00:39.390 --> 01:00:44.530 Also hier wird die Anzahl der Byte im Datenfeld kodiert. 01:00:44.530 --> 01:00:46.730 Das sind maximal 12.000 Bit. 01:00:46.930 --> 01:00:52.610 Das heißt also, Sie haben bis zu 1500 Byte, die Sie übertragen können 01:00:52.610 --> 01:00:53.970 an dieser Stelle. 01:00:54.350 --> 01:00:57.530 Dann gibt es noch sogenannte Padding-Bits. 01:00:59.790 --> 01:01:02.270 Da bin ich jetzt gar nicht näher drauf eingegangen. 01:01:02.390 --> 01:01:04.490 Das ist aber auch ein wichtiger Aspekt. 01:01:04.690 --> 01:01:10.170 Sie müssen eine Mindestpaketlänge im Ethernet vorsehen. 01:01:11.430 --> 01:01:14.850 Die liegt bei 64 Byte. 01:01:15.770 --> 01:01:20.670 Jetzt können Sie aber natürlich nur sehr kurze Daten übertragen und 01:01:20.670 --> 01:01:25.010 Sie kommen mit den Steuerinformationen eben nicht auf diese 64 Byte. 01:01:25.830 --> 01:01:29.690 Das heißt, Sie müssen jetzt irgendwie in dem Fall, in dem Sie so kurze 01:01:29.690 --> 01:01:35.530 Daten übertragen, künstlich die Länge des Ethernet-Paketes erweitern. 01:01:36.150 --> 01:01:37.690 Der Grund ist der folgende. 01:01:38.350 --> 01:01:44.650 Dieses CSM-ACD-Verfahren funktioniert nur, wenn die sendende Station 01:01:44.650 --> 01:01:49.170 den Sendefunk noch nicht abgeschlossen hat, während sie die Kollision 01:01:49.170 --> 01:01:49.630 entdeckt. 01:01:49.930 --> 01:01:54.510 Das heißt, wenn die Kollision bei der sendenden Station ankommt, also 01:01:54.510 --> 01:01:58.270 diese Signalüberlagerung festgestellt wird, muss die Station noch 01:01:58.270 --> 01:01:58.850 senden. 01:01:59.310 --> 01:02:02.810 Das ist also eine Vorgabe, sonst funktioniert das Ganze nicht, weil 01:02:02.810 --> 01:02:06.330 Sie nämlich ansonsten nicht wissen, wer ist denn von der Kollision 01:02:06.330 --> 01:02:06.730 betroffen. 01:02:06.730 --> 01:02:10.070 Das ist auch nochmal ein Effizienzaspekt von dem Verfahren. 01:02:10.510 --> 01:02:12.750 Sie haben diese Eins-zu-eins-Zuordnung. 01:02:14.170 --> 01:02:23.310 Wenn eine Kollision auftritt, dann sind das meine gesendeten Daten, 01:02:23.410 --> 01:02:27.430 beziehungsweise andersrum, hier wird es noch klarer, wenn ich meine 01:02:27.430 --> 01:02:31.170 Informationen, meine Daten gesendet habe, und in der Zeit, in der ich 01:02:31.170 --> 01:02:34.990 gesendet habe, habe ich kein Kollisionssignal entdeckt, gehe ich davon 01:02:34.990 --> 01:02:37.410 aus, dass das geklappt hat, dass das funktioniert hat. 01:02:38.190 --> 01:02:44.910 Das heißt also, Sie müssen dafür sorgen, dass sozusagen zwischen dem 01:02:44.910 --> 01:02:49.150 Ausbreiten, wir nehmen mal die Station A und die Station B, wir haben 01:02:49.150 --> 01:02:54.950 hier das Medium, mal ganz salopp gesprochen, Sie müssen dafür sorgen, 01:02:55.090 --> 01:02:57.030 dass diese Station A, die jetzt hier sendet, 01:03:03.830 --> 01:03:08.490 Sie haben hier die Station A, Sie haben hier die Station B, Sie 01:03:08.490 --> 01:03:12.030 brauchen eine Zeit, bis sich die Kollision ausbreitet. 01:03:12.730 --> 01:03:17.130 Sie brauchen hier, Sie müssen sich sozusagen dahin ausbreiten, dann 01:03:17.130 --> 01:03:21.970 vergeht Zeit, bis die Station B auch irgendwas aufs Netz gebracht hat. 01:03:22.330 --> 01:03:25.490 Sie haben also hier irgendwie Signallaufzeiten, und dann muss das 01:03:25.490 --> 01:03:28.050 Kollisionssignal, das ja hier jetzt irgendwo entstanden ist, muss auch 01:03:28.050 --> 01:03:28.730 wieder zurückgehen. 01:03:29.030 --> 01:03:34.330 Das heißt, Sie müssen die Roundtrip-Delayzeit, die Zeit, die die 01:03:34.330 --> 01:03:39.090 Signale brauchen, bis sie einmal vom Empfänger und zurückgekommen 01:03:39.090 --> 01:03:40.230 sind, müssen Sie einbeziehen. 01:03:40.850 --> 01:03:45.810 Und das ist die eine Zeitkomponente, und die müssen Sie vergleichen 01:03:45.810 --> 01:03:50.410 mit der Zeit, die diese Station A braucht, um das Paket loszuwerden, 01:03:50.490 --> 01:03:51.910 oder die Daten loszuwerden. 01:03:52.130 --> 01:03:59.230 Das war ja die Übertragungszeit, oder hängt massiv ab von der 01:03:59.230 --> 01:04:00.810 Übertragungskapazität. 01:04:01.690 --> 01:04:07.130 Und je länger die Daten sind, die Sie hier übertragen müssen, durch 01:04:07.130 --> 01:04:12.870 das A, umso länger braucht die Station A auch, um die Daten 01:04:12.870 --> 01:04:13.830 loszuwerden. 01:04:14.510 --> 01:04:21.350 Und wenn Sie jetzt die Paketlänge, wenn Sie wissen, das Paket hat eine 01:04:21.350 --> 01:04:26.150 Mindestlänge, dann können Sie diese Zeit auch festlegen. 01:04:26.330 --> 01:04:29.070 Wenn Sie nicht wissen, wie lang das Paket ist, wenn es beliebig kurz 01:04:29.070 --> 01:04:33.450 sein kann, ist die Zeit, die die Station A für Senden braucht, auch 01:04:33.450 --> 01:04:37.070 nicht vorhersagbar, nicht mit einkalkulierbar. 01:04:37.730 --> 01:04:40.190 Und dementsprechend können Sie dann eben keine Aussage mehr treffen, 01:04:40.510 --> 01:04:43.470 ist denn die Station A wirklich noch am Senden, während hier dieses 01:04:43.470 --> 01:04:47.210 Kollisionssignal, wenn das Kollisionssignal ankommt. 01:04:47.590 --> 01:04:51.170 Das heißt, diese Zeit, die die Station A braucht, um das Paket 01:04:51.170 --> 01:04:55.350 loszuwerden, müssen Sie gegebenenfalls künstlich verlängern. 01:04:55.930 --> 01:05:01.990 Und das passiert genau dann, wenn Sie zu kurze Pakete haben, zu wenig 01:05:01.990 --> 01:05:05.430 Daten, zu wenig Nutzdaten übertragen, dann müssen Sie eben diese 01:05:05.430 --> 01:05:10.550 Padding -Daten hinzufügen, um diese Mindestlänge von 64 Byte zu 01:05:10.550 --> 01:05:11.990 erreichen in dem Ethernet-Paket. 01:05:12.410 --> 01:05:14.230 Das ist also der Grund für das Padding. 01:05:14.750 --> 01:05:17.130 Dann kommen wir noch zu dem Frame-Check-Sequence. 01:05:17.630 --> 01:05:20.690 Dahinter steckt jetzt das CRC-Verfahren, das Cyclic Redundancy Check 01:05:20.690 --> 01:05:27.570 -Verfahren, eine Polynom-Division, die Sie über diese Daten legen, 01:05:28.490 --> 01:05:32.230 hier eine Zusatzinformation angeben, mit der Sie eben dann 01:05:32.230 --> 01:05:35.170 Verfälschungen beim Empfänger identifizieren können. 01:05:35.490 --> 01:05:41.450 Das ist also die eigentliche Erkennung von Bit-Fehlern. 01:05:42.330 --> 01:05:45.170 Dann das Paketformat vom Tokenring. 01:05:46.290 --> 01:05:47.610 Eigentlich ist das ein bisschen unglücklich. 01:05:47.610 --> 01:05:52.970 Wir reden immer von Ethernet-Paketen und von Tokenring-Paketen. 01:05:53.890 --> 01:05:58.830 Eigentlich ist das unglücklich, weil es sind immer Schicht-2-PDUs, die 01:05:58.830 --> 01:05:59.610 wir hier betrachten. 01:06:00.330 --> 01:06:04.770 Schicht-2-PDUs, also Protokoll-Daten-Einheiten der Schicht-2. 01:06:05.550 --> 01:06:10.630 Und eigentlich sind Pakete, das ist so der Begriff für Schicht-3-PDUs 01:06:10.630 --> 01:06:15.950 und Schicht-2-PDUs, da redet man eher über Frames oder Rahmen. 01:06:20.910 --> 01:06:25.070 Da sind natürlich die Pakete als Nutzdaten drin von der Schicht-3, das 01:06:25.070 --> 01:06:25.450 ist klar. 01:06:25.950 --> 01:06:30.550 Aber eigentlich müsste man über Rahmenformat von Tokenring an der 01:06:30.550 --> 01:06:32.590 Stelle eher reden als von Paketen. 01:06:33.170 --> 01:06:38.250 So, und hier haben wir zwei grundsätzlich unterschiedliche Formate, 01:06:39.270 --> 01:06:40.530 nämlich das Tokenformat. 01:06:40.530 --> 01:06:45.210 Das ist das Format, was wir brauchen, die PDU, die wir benötigen, um 01:06:45.210 --> 01:06:51.890 sozusagen die Situation zu behandeln, wenn der Ring frei ist. 01:06:52.250 --> 01:06:56.950 Also wenn das Tokenformat über dem Ring läuft, dann heißt das, der 01:06:56.950 --> 01:06:57.650 Ring ist frei. 01:06:58.390 --> 01:07:03.690 Und das Datenrahmenformat, das wir dann benötigen, wenn wir über den 01:07:03.690 --> 01:07:05.830 Ring Daten übertragen wollen. 01:07:06.190 --> 01:07:11.430 Und das Vorgehen, das wir gerade auf der Folie gesehen haben, grafisch 01:07:11.430 --> 01:07:14.950 angezeigt gesehen haben, läuft folgendermaßen ab. 01:07:15.630 --> 01:07:21.390 Wenn eine Station dieses Tokenformat erhält, dann erkennt es in diesem 01:07:21.390 --> 01:07:26.490 AC an einem Bit in dem Access Control, das AC steht für Access 01:07:26.490 --> 01:07:36.970 Control, erkennt es, es handelt sich um ein Token, um ein Token, das 01:07:36.970 --> 01:07:40.810 eben charakterisiert, dass der Ring frei ist. 01:07:41.590 --> 01:07:45.650 Und diese Station, wenn die Sendewillig ist, macht die nichts anderes, 01:07:45.790 --> 01:07:49.050 als dass sie in diesem Access Control, dieses Bit im Access Control, 01:07:49.690 --> 01:07:57.250 verändert, also von 0 auf 1 setzt und entsprechend dann dieses 01:07:57.250 --> 01:08:00.150 Tokenformat ergänzt. 01:08:00.610 --> 01:08:04.370 Das heißt, diese Antelimiter, das ist also eigentlich nur ein Start- 01:08:04.370 --> 01:08:08.350 und Antelimiter, der wird sozusagen nach hinten geschoben und es 01:08:08.350 --> 01:08:14.030 werden die Informationen eingefügt, die benötigt werden, um Daten zu 01:08:14.030 --> 01:08:14.550 übertragen. 01:08:14.790 --> 01:08:18.770 Das sind im Wesentlichen gewisse Steuerinformationen zur 01:08:18.770 --> 01:08:23.470 Rahmensteuerung, können Sequenznummern beispielsweise sein, das ist 01:08:23.470 --> 01:08:27.350 insbesondere die Adressierung, die wir hier brauchen, also von wem, 01:08:28.010 --> 01:08:31.570 wer sendet, an wen soll es gesendet werden, die Daten, ganz wichtig, 01:08:31.570 --> 01:08:38.710 und wieder die Framecheck-Sequenz, mit denen man Bitfehler erkennen 01:08:38.710 --> 01:08:39.430 kann. 01:08:39.870 --> 01:08:43.470 Und entsprechend kommt dann hier der Antelimiter und nochmal ein 01:08:43.470 --> 01:08:44.530 Rahmenstatus. 01:08:45.070 --> 01:08:51.870 Also letztendlich wird dieses Token ergänzt um die Daten und wenn dann 01:08:51.870 --> 01:08:57.390 entsprechend die Daten erfolgreich übertragen worden sind, wird 01:08:57.390 --> 01:09:00.150 sozusagen das wieder zurückgenommen und man hat wieder das 01:09:00.150 --> 01:09:00.750 Tokenformat. 01:09:00.750 --> 01:09:04.650 Also da hat man sich auch schon wieder einiges überlegt, dass man sehr 01:09:04.650 --> 01:09:08.290 effizient dieses Umwandeln von Tokenformat in Datenrahmenformat und 01:09:08.290 --> 01:09:08.910 zurück machen kann. 01:09:09.010 --> 01:09:13.550 Das ist ja genau das, was sozusagen immer passiert im Tokenring, wenn 01:09:13.550 --> 01:09:16.810 der Token freigegeben wird, wieder besetzt wird, freigegeben wird, das 01:09:16.810 --> 01:09:21.670 ist ja das häufigste Vorgehen, was man eben hier im Tokenring 01:09:21.670 --> 01:09:22.350 vornehmen muss. 01:09:24.870 --> 01:09:29.470 HDLC ist jetzt das dritte Paketformat. 01:09:30.790 --> 01:09:36.950 Das sieht so aus, dass wir hier eine Sicherung durchführen können mit 01:09:36.950 --> 01:09:37.530 diesem Paketformat. 01:09:38.270 --> 01:09:41.750 Also im HDLC haben wir keine gemeinsam genutzten, kein gemeinsam 01:09:41.750 --> 01:09:45.590 genutztes Medium, sondern das ist das klassische Schicht 2 Protokoll 01:09:45.590 --> 01:09:51.930 gemäß dem ISO-Modell und hat also folgenden Aufbau. 01:09:52.410 --> 01:09:55.470 Hier ist nochmal der Begriff Pakete, Blöcke. 01:09:56.450 --> 01:09:58.910 Eigentlich sind es Rahmen, also Sie sehen, es gibt mehrere Begriffe 01:09:58.910 --> 01:09:59.350 dafür. 01:10:01.050 --> 01:10:05.590 Die sieht folgendermaßen aus, dass wir also eine sogenannte 01:10:05.590 --> 01:10:08.190 Blockbegrenzung haben, am Anfang und am Ende. 01:10:09.590 --> 01:10:14.970 Und dann haben wir Adressinformation, Steuerfeld, hier sind 01:10:14.970 --> 01:10:18.650 Quittungsnummern enthalten, die werden wir dann auch nochmal später 01:10:18.650 --> 01:10:22.730 etwas näher beleuchten, das Datenfeld und wieder das 01:10:22.730 --> 01:10:27.810 Blockprüfungsfeld, dahinter steckt wieder das CRC-Verfahren. 01:10:28.530 --> 01:10:34.530 Interessant, im Folgenden ist diese Blockbegrenzung, hierhinter steckt 01:10:34.530 --> 01:10:40.170 nämlich ein Verfahren, das nennt sich Bitstuffing und dahinter steckt 01:10:40.170 --> 01:10:46.510 wieder eigentlich die Frage oder das Ziel der Co-Transparenz. 01:10:47.290 --> 01:10:51.790 Das Thema, das wir hier zu behandeln haben, die Frage, die wir zu 01:10:51.790 --> 01:10:58.170 beantworten haben, ist, wie kann ich Begrenzungsinformationen, also 01:10:58.170 --> 01:11:04.170 hier beginnt der Block, hier endet der Block, wie führe ich die in 01:11:04.170 --> 01:11:11.170 einen bestehenden Datenstrom ein, ohne, dass ich sozusagen innerhalb 01:11:11.170 --> 01:11:20.510 der Transparenz übertragenen Datenfeldes einen Konflikt bekomme, dass 01:11:20.510 --> 01:11:26.350 gegebenenfalls dieses Blockbegrenzungsmuster hier auftreten kann. 01:11:26.810 --> 01:11:34.190 Das heißt, wie kann ich Blockbegrenzungen einführen, also spezielle 01:11:34.190 --> 01:11:39.050 Steuerinformationen einführen, die mir Anfang und Ende vom Block 01:11:39.050 --> 01:11:44.390 identifizieren, ohne dabei Vorgaben an die zu übertragenen Daten zu 01:11:44.390 --> 01:11:44.610 machen. 01:11:45.690 --> 01:11:53.570 Denn wer garantiert mir, dass nicht dieses Bitmuster, bestehend aus 01:11:53.570 --> 01:11:58.510 einer Null und sechs konsekutiven, also aufeinanderfolgenden Einsen, 01:11:58.750 --> 01:12:00.690 dass das nicht in den Nutzdaten enthalten ist. 01:12:01.050 --> 01:12:02.410 Das heißt, ich muss hier irgendwie was tun. 01:12:03.010 --> 01:12:08.110 Ich muss dafür sorgen, dass ich irgendwie diese Blockbegrenzung, dass 01:12:08.110 --> 01:12:11.210 diese Blockbegrenzung nicht in dem Datenfeld auftreten. 01:12:11.510 --> 01:12:16.390 Und das ist genau das Bitstuffing, diese Sequenz darf eben in diesem 01:12:16.390 --> 01:12:19.210 Paket, das heißt in diesen Feldern, nicht auftreten. 01:12:19.890 --> 01:12:24.790 Und das ist, was wir jetzt im Rahmen der Cotransparenz behandeln 01:12:24.790 --> 01:12:25.130 werden. 01:12:25.530 --> 01:12:29.710 Vorher noch ein einfacheres Verfahren, das eben auch Cotransparenz, 01:12:29.910 --> 01:12:32.950 für Cotransparenz sorgt, das wäre eben die Längenangabe. 01:12:32.950 --> 01:12:38.230 Damit habe ich eigentlich auch das gleiche erreicht, wie mit der 01:12:38.230 --> 01:12:39.350 Blockbegrenzung. 01:12:40.150 --> 01:12:43.130 Ich sage nämlich letztendlich, wo hören die Nutzdaten auf. 01:12:43.530 --> 01:12:47.210 Das ganz Vergleichbare mache ich mit dieser Blockbegrenzung. 01:12:47.990 --> 01:12:53.170 Das ist aber ein Problem, das mit diesem Lösungsansatz verbunden ist. 01:12:53.590 --> 01:12:58.650 Wenn hier Fehler auftreten, haben Sie also größere Probleme. 01:12:59.970 --> 01:13:03.110 Und Sie haben noch zusätzlich einen Overhead an der Stelle. 01:13:03.710 --> 01:13:08.910 Also es ist durchaus sinnvoll, sich über ein alternatives Verfahren 01:13:08.910 --> 01:13:09.670 Gedanken zu machen. 01:13:09.830 --> 01:13:11.350 Und das ist genau dieses Bitstuffing. 01:13:12.370 --> 01:13:16.090 Nämlich, das ist jetzt hier angegeben, wie komme ich zu diesem 01:13:16.090 --> 01:13:20.470 Blockbegrenzungszeichen, bestehend aus den 6 Einsen. 01:13:21.290 --> 01:13:29.070 Ich füge in den zu übertragenden Nutzdatenstrom, der hier angedeutet 01:13:29.070 --> 01:13:36.330 ist, füge ich solche Stopfbits ein, also so ein Bitstuffing ein. 01:13:36.890 --> 01:13:39.390 Und zwar nach folgender Regel. 01:13:40.470 --> 01:13:48.470 Wenn 5 aufeinanderfolgende Binärzeichen 1 anliegen, in dem transparent 01:13:48.470 --> 01:13:53.950 zu übertragenden Nutzdatenstrom, dann fügt die sendende 01:13:53.950 --> 01:13:58.970 Datenendeinrichtung, DEE steht für Datenendeinrichtung, ein 01:13:58.970 --> 01:14:00.150 Binärzeichen 0 ein. 01:14:00.810 --> 01:14:04.690 Und die empfangende DEE entfernt eben diese nach 5 01:14:04.690 --> 01:14:08.410 aufeinanderfolgenden Binärzeichen ein folgendes Binärzeichen 0. 01:14:09.310 --> 01:14:16.210 Und damit erhalten Sie, wenn keine Bitfehler auftreten, da haben Sie 01:14:16.210 --> 01:14:20.950 aber das CRC-Verfahren dafür, damit erhalten Sie ein eindeutiges 01:14:20.950 --> 01:14:25.990 Verfahren, wie Sie sozusagen diese eingefügten Nullen identifizieren 01:14:25.990 --> 01:14:29.450 können und entsprechend wieder Co-Transparenz herstellen können. 01:14:30.070 --> 01:14:39.710 Und gleichzeitig dieses Muster hier als Blockanfangs- bzw. 01:14:39.970 --> 01:14:42.570 Endezeichen benutzen können. 01:14:43.230 --> 01:14:47.430 Weil nämlich, wenn nach 5 aufeinanderfolgenden Einsen, das ist ja 01:14:47.430 --> 01:14:51.310 genau hier der kritische Punkt, wenn nach 5 aufeinanderfolgenden 01:14:51.310 --> 01:14:59.870 Einsen keine 0 anliegt, sondern eine 1 anliegt, dann haben wir genau 01:14:59.870 --> 01:15:02.690 den Fall, dass wir am Ende des Blockes angekommen sind. 01:15:03.070 --> 01:15:09.790 Wenn eine 0 anliegt, dann muss diese 0 das eingefügte Zeichen sein vom 01:15:09.790 --> 01:15:10.090 Sender. 01:15:10.430 --> 01:15:14.570 Also das ist ein recht einfaches Verfahren, das eben für diese Co 01:15:14.570 --> 01:15:15.650 -Transparenz auch sorgt. 01:15:17.730 --> 01:15:22.050 Letzter Abschnitt beschäftigt sich jetzt mit Fehlerursachen und 01:15:22.050 --> 01:15:26.530 Fehlerbehandlung in der Schicht 2, das eigentliche, die Hauptfunktion, 01:15:27.410 --> 01:15:30.010 Protokollfunktion, die wir eben in der Schicht 2 haben. 01:15:31.910 --> 01:15:36.630 Wir unterscheiden, müssen überlegen, durch was entstehen überhaupt 01:15:36.630 --> 01:15:37.630 Übertragungsfehler. 01:15:38.750 --> 01:15:41.530 Durch das Medium kann was passieren, durch die Anschlusselektronen 01:15:41.530 --> 01:15:49.050 können Fehler entstehen, die Typen, die wir hier unterscheiden, sind 01:15:49.050 --> 01:15:53.070 Einzelbitfehler, also ein einzelnes Bit ist verfälscht, Bündelfehler 01:15:53.070 --> 01:15:56.830 und Synchronisierfehler, die also hier auftreten können. 01:15:59.530 --> 01:16:03.470 Um welchen Typus es sich handelt, von Fehler es sich handelt, ist zum 01:16:03.470 --> 01:16:06.170 Teil abhängig von der Übertragungsgeschwindigkeit. 01:16:06.870 --> 01:16:09.890 Also was in einem sehr langsamen Medium ein Einbitfehler ist, kann zu 01:16:09.890 --> 01:16:13.730 einem Bündelfehler in einer höheren Übertragungsgeschwindigkeit 01:16:13.730 --> 01:16:14.050 führen. 01:16:14.710 --> 01:16:18.230 Das heißt also hier müssen wir die Übertragungsgeschwindigkeit auch 01:16:18.230 --> 01:16:18.910 mit einbeziehen. 01:16:19.650 --> 01:16:23.010 Das ist genau das, was hier unten angegeben ist. 01:16:23.590 --> 01:16:29.930 Schauen wir uns mal gewisse Werte an, die typischerweise auftreten in 01:16:29.930 --> 01:16:31.650 der Praxis, bezüglich der Medien. 01:16:32.230 --> 01:16:38.950 Sie sehen also verglichen, wenn wir das analoge Fernsprechnetz mit 10 01:16:38.950 --> 01:16:45.050 hoch minus 4 vergleichen mit Glasfaser bis 10 hoch minus 12, dann sind 01:16:45.050 --> 01:16:49.890 das wirklich Dimensionen, in denen wir hier denken müssen. 01:16:51.630 --> 01:16:56.130 Wir haben sehr störungsanfällige Medien, mit dem Fernsprechnetz 01:16:56.130 --> 01:16:56.710 insbesondere. 01:16:57.250 --> 01:17:01.630 Und wenn wir Richtung Glasfaser gehen, sieht die ganze Geschichte 01:17:01.630 --> 01:17:03.030 schon sehr viel angenehmer aus. 01:17:03.030 --> 01:17:08.270 Vom Medium her sind die Fehlerwahrscheinlichkeiten sehr gering. 01:17:08.770 --> 01:17:12.370 Das müssen wir auch in den Protokollen berücksichtigen, dass wir da 01:17:12.370 --> 01:17:18.450 nicht zu viel Aufwand investieren und das Gesamtziel nicht vernünftig 01:17:18.450 --> 01:17:19.230 erreichen können. 01:17:19.290 --> 01:17:22.030 Das gilt insbesondere für Isochron-Datenverkehr, also Multimedia 01:17:22.030 --> 01:17:22.710 -Datenverkehr. 01:17:23.330 --> 01:17:24.670 Da müssen wir uns ein paar Gedanken machen. 01:17:26.670 --> 01:17:32.310 Jetzt müssen wir uns überlegen, treten die Fehler in den Daten auf, in 01:17:32.310 --> 01:17:35.310 den Nutzdaten oder treten sie in den Protokoll, in den 01:17:35.310 --> 01:17:36.830 Steuerinformationen auf. 01:17:39.130 --> 01:17:46.470 Das ist eigentlich an der Stelle nur bedingt relevant, weil sie 01:17:46.470 --> 01:17:49.890 grundsätzlich immer in Schichten denken müssen. 01:17:50.490 --> 01:17:54.370 Und wenn sie in Schichten denken, dann stellen sie fest, dass eine 01:17:54.370 --> 01:17:57.830 Steuerinformation für eine Schicht in der nächsten Schicht schon 01:17:57.830 --> 01:17:59.470 wieder Nutzinformationen darstellt. 01:18:00.070 --> 01:18:03.270 Das heißt also, wenn wir hier kein geschichtetes System hätten, dann 01:18:03.270 --> 01:18:05.030 würde das schon eine massive Rolle spielen. 01:18:05.150 --> 01:18:06.890 Da müssten sie sich schon ein paar Gedanken machen. 01:18:07.230 --> 01:18:11.070 Aber dadurch, dass wir in geschichteten Systemen denken und auch die 01:18:11.070 --> 01:18:15.870 Telematik -Systeme geschichtet aufbauen, spielt das eine geringwertige 01:18:15.870 --> 01:18:22.170 Rolle, weil sie sozusagen von Schicht zu Schicht ändert sich ja, kann 01:18:22.170 --> 01:18:25.530 eine Information von der Steuerinformation zur Nutzinformation werden. 01:18:26.390 --> 01:18:31.190 Wir müssen unbedingt dafür sorgen, dass wir diese Bitfehler erkennen 01:18:31.190 --> 01:18:34.870 und durch entsprechende Maßnahmen beheben können. 01:18:35.830 --> 01:18:39.020 Das ist jetzt die einfachste Form der Fehlererkennung. 01:18:39.890 --> 01:18:42.110 Das ist die Paritätsüberprüfung. 01:18:43.010 --> 01:18:47.230 Sie können sich eine Quer- oder Längsparität hier vorstellen. 01:18:47.230 --> 01:18:51.650 Fangen wir mal mit der Längsparität an. 01:18:52.110 --> 01:18:55.330 Sie haben also hier N-Zeichen, die Sie zu übertragen haben. 01:18:56.150 --> 01:19:00.530 Und Sie fügen jetzt bei der Längsparität ein sechstes Zeichen hinzu 01:19:00.530 --> 01:19:07.990 und füllen dieses Zeichen, diese Steuerinformation so auf, dass Sie 01:19:07.990 --> 01:19:15.670 immer entweder eine gradzahlige oder ungradzahlige Anzahl von Einsen 01:19:15.670 --> 01:19:19.770 beziehungsweise Nullen auf dieser Zeile haben. 01:19:20.270 --> 01:19:23.670 In dem Fall haben wir eine gerade Blockparität. 01:19:24.330 --> 01:19:28.630 Gerade Blockparität heißt, dass Sie also eine gerade Anzahl von Einsen 01:19:28.630 --> 01:19:34.030 immer verlangen und entsprechend hier, wenn eine ungrade Anzahl von 01:19:34.030 --> 01:19:36.730 Einsen in dieser Zeile auftritt, eine Eins ergänzen. 01:19:36.830 --> 01:19:41.670 Wenn eine gerade Anzahl von Einsen hier entsteht, das ist genau diese 01:19:41.670 --> 01:19:45.190 zwei, das ist eine gerade Anzahl, dann kommen wir zur Null. 01:19:45.650 --> 01:19:49.010 Währenddessen hier haben wir dann drei Einsen und wir ergänzen eine 01:19:49.010 --> 01:19:49.350 Eins. 01:19:49.430 --> 01:19:54.710 Das heißt, wir können an der Stelle auf der anderen Seite diese 01:19:54.710 --> 01:19:59.150 Überprüfung machen und entsprechend Bitfehler, gewisse Bitfehler 01:19:59.150 --> 01:20:02.370 zumindest überprüfen oder erkennen. 01:20:03.290 --> 01:20:09.350 Genauso können Sie eben hier auf Querparität überprüfen. 01:20:09.350 --> 01:20:13.510 Hier ergänzen Sie entsprechend nicht zeilenweise, sondern Sie ergänzen 01:20:13.510 --> 01:20:15.670 sozusagen pro Zeichen. 01:20:16.230 --> 01:20:22.290 Sie ergänzen jedes Zeichen um ein Bit und entsprechend genauso wie 01:20:22.290 --> 01:20:25.670 gerade, Sie sorgen dafür, dass die Anzahl der Einsen, bleiben wir bei 01:20:25.670 --> 01:20:27.970 den Einsen, entweder immer gerade oder ungerade ist. 01:20:28.370 --> 01:20:30.350 Das können Sie also beliebig variieren. 01:20:30.490 --> 01:20:36.390 Sie können im Grundsatz auch eine Kreuzparität realisieren, indem Sie 01:20:36.390 --> 01:20:41.490 beide Verfahren einsetzen und Sie können, wie es hier angegeben ist, 01:20:41.690 --> 01:20:46.590 sich überlegen, ob Sie die Querparität auf ungerade Zeichenparität und 01:20:46.590 --> 01:20:49.910 die Längsparität auf gerade Blockparität realisieren. 01:20:50.730 --> 01:20:52.310 Da haben Sie also beliebige Freiheitsgrade. 01:20:52.790 --> 01:20:56.490 Insgesamt führt aber dieses Verfahren nicht sehr weit. 01:20:57.710 --> 01:21:03.090 Sie haben einen relativ hohen Aufwand für die Fehler, diese Bitfehler, 01:21:03.150 --> 01:21:04.750 die Sie tatsächlich damit erkennen können. 01:21:04.750 --> 01:21:08.770 Und das führt dazu, dass man sehr viel effizientere Verfahren heute 01:21:08.770 --> 01:21:09.290 einsetzt. 01:21:09.910 --> 01:21:14.990 Und das in der Praxis am meisten und am häufigsten eingesetzte und 01:21:14.990 --> 01:21:21.490 sich als sehr geeignet herausgestellte Verfahren ist der Cyclic 01:21:21.490 --> 01:21:23.090 Redundancy Check, CRC. 01:21:23.870 --> 01:21:32.810 Die Idee ist folgende, wir sehen die zu prüfende Bitfolge, das sind 01:21:32.810 --> 01:21:38.250 die Nutzdaten, die ich überprüfen möchte, die ich also auf Bitfehler 01:21:38.250 --> 01:21:42.930 überprüfen möchte, die sehen wir als Polynom an, so ein Polynom. 01:21:46.130 --> 01:21:48.590 Das ist das zu überprüfende Polynom. 01:21:49.710 --> 01:21:53.670 Und wir haben ein zweites Polynom, das ist das sogenannte 01:21:53.670 --> 01:21:55.250 Generatorpolynom. 01:21:56.310 --> 01:22:00.170 Und die Idee ist folgende, wir werden da noch Übungsaufgaben machen, 01:22:00.170 --> 01:22:04.530 in denen Sie dann an ganz konkreten Bitfolgen das mal durchexerzieren 01:22:04.530 --> 01:22:04.890 können. 01:22:05.230 --> 01:22:06.730 Die Idee ist relativ einfach. 01:22:06.950 --> 01:22:11.110 Die sieht so aus, dass ich eine Polynomdivision durchführe, also 01:22:11.110 --> 01:22:17.710 sozusagen das Polynom aus dieser zu prüfenden Bitfolge, dass ich 01:22:17.710 --> 01:22:20.570 dieses durch das Generatorpolynom dividiere. 01:22:21.270 --> 01:22:24.430 Ich muss vorher noch eine Erweiterung um Nullfolgen durchführen, damit 01:22:24.430 --> 01:22:28.330 das funktioniert, damit sozusagen die Gradzahl auch angepasst ist. 01:22:28.330 --> 01:22:38.410 Und ich übertrage diesen Rest der Division als Prüfsumme oder als 01:22:38.410 --> 01:22:39.270 Prüfinformation. 01:22:41.570 --> 01:22:48.590 Und jetzt kann auf der anderen Seite, wird mit diesem Rest neu 01:22:48.590 --> 01:22:49.190 dividiert. 01:22:50.510 --> 01:22:56.050 Und wenn keine Bitfehler aufgetreten sind, wenn alles korrekt bei der 01:22:56.050 --> 01:23:01.850 anderen Seite angekommen ist, dann muss diese, dass diese Division auf 01:23:01.850 --> 01:23:03.810 der Empfängerseite den Rest Null ergeben. 01:23:05.670 --> 01:23:10.330 Aufgrund der Konstruktion mit dem Rest und dass ich den Rest eben bei 01:23:10.330 --> 01:23:12.370 der Division beim Empfänger mit einbeziehe. 01:23:13.490 --> 01:23:18.810 Dieses Verfahren hängt ganz stark davon ab, wie Sie das 01:23:18.810 --> 01:23:22.090 Generatorpolynom festlegen. 01:23:22.710 --> 01:23:26.370 Also da können Sie beliebig viele schlechte Ergebnisse erzielen. 01:23:26.550 --> 01:23:30.470 Es gibt drei oder vier verschiedene Generatorpolynome, die also im 01:23:30.470 --> 01:23:34.250 Standard festgelegt sind, die also auch sehr gute Ergebnisse, also 01:23:34.250 --> 01:23:36.530 sehr viele Bitfehler erkennen. 01:23:38.050 --> 01:23:41.750 Und die werden eben dann auch genutzt in den heutigen Verfahren, in 01:23:41.750 --> 01:23:46.290 den heutigen Hardware-Steinen, sozusagen Hardware-Elementen, um dieses 01:23:46.290 --> 01:23:48.330 CRC -Verfahren zu realisieren. 01:23:48.330 --> 01:23:52.270 Wie gesagt, wir werden in der Übung hier drauf noch im Detail 01:23:52.270 --> 01:23:57.330 eingehen, wie diese Polynom-Division vonstatten geht. 01:23:57.410 --> 01:24:00.530 Aber wenn Sie es einmal gemacht haben für ein Beispiel, dann ist das 01:24:00.530 --> 01:24:02.810 sehr schnell einzusehen, dass das funktioniert. 01:24:03.710 --> 01:24:06.710 Was sehr viel schwieriger ist, ist dann die Abschätzung, wie gut ist 01:24:06.710 --> 01:24:10.430 das Verfahren, in welchen Situationen liefert es gute Ergebnisse, 01:24:10.570 --> 01:24:12.050 welche Bitfehler werden nicht erkannt. 01:24:12.470 --> 01:24:16.270 Also das ist dann schon eine sehr mathematische und zahlentheoretische 01:24:16.270 --> 01:24:16.990 Angelegenheit. 01:24:16.990 --> 01:24:20.390 Die Primzahlen spielen dann natürlich bei der Bildung des 01:24:20.390 --> 01:24:22.250 Generatorpolynoms eine ganz erhebliche Rolle. 01:24:23.690 --> 01:24:30.130 So, kommen wir jetzt zu den Fehlerbehandlungen auf der PDU-Ebene, auf 01:24:30.130 --> 01:24:30.870 der Block-Ebene. 01:24:31.550 --> 01:24:36.310 Sie sehen hier eine Übertragung mal ohne Fehlerbehandlung. 01:24:37.470 --> 01:24:41.430 Das ist eigentlich ein sehr untypisches Verhalten für Schicht 2. 01:24:42.430 --> 01:24:45.170 Das gibt es auf der Schicht 2 eigentlich nicht, weil die Schicht 2 01:24:45.170 --> 01:24:48.430 genau dafür da ist, dass wir eben eine Fehlerbehandlung durchführen. 01:24:48.890 --> 01:24:51.490 Aber das wäre das typische Verhalten auf der IP-Schicht. 01:24:52.090 --> 01:24:54.390 Das ist genau, wie die IP-Schicht arbeitet. 01:24:55.130 --> 01:24:58.430 Der ist sozusagen vollkommen egal, dem Sender ist hier vollkommen 01:24:58.430 --> 01:25:01.210 egal, was ankommt, es wird einfach übertragen. 01:25:02.050 --> 01:25:05.070 Das ist also zu sagen, hier soll Ihnen angedeutet werden, so sieht 01:25:05.070 --> 01:25:06.950 eine Übertragung ohne Fehlerbehandlung aus. 01:25:08.390 --> 01:25:12.110 Also für Schicht 2 gibt es doch eher andere Vorgehensweisen. 01:25:12.870 --> 01:25:18.650 Das Erste, was wir eben einfügen können auf der Ebene, was auch 01:25:18.650 --> 01:25:24.250 durchgeführt wird, ist, dass wir ein Acknowledge einführen, also eine 01:25:24.250 --> 01:25:25.350 Bestätigung einführen. 01:25:25.970 --> 01:25:27.290 Das sehen wir also hier. 01:25:30.610 --> 01:25:35.430 Beim Sender wird ein Block P1 übertragen. 01:25:36.590 --> 01:25:39.030 Der wird hier als Indication angegeben. 01:25:39.030 --> 01:25:44.410 Und auf der Empfängerseite wird ein Acknowledge als 01:25:44.410 --> 01:25:46.650 Empfangsbestätigung für dieses P1 angegeben. 01:25:46.850 --> 01:25:51.670 Mit dem Effekt, dass auf der Senderseite hier eine Verzögerung 01:25:51.670 --> 01:25:52.350 stattfindet. 01:25:52.910 --> 01:25:54.070 Das ist eine Verzögerung. 01:25:54.670 --> 01:25:59.170 Die Senderseite, das ist jetzt das Verhalten, das hier vorgegeben 01:25:59.170 --> 01:26:09.370 wird, kann erst dann das nächste Paket absetzen, wenn das erste Paket 01:26:09.370 --> 01:26:11.750 bestätigt wurde, mit diesem Acknowledge-Paket. 01:26:12.450 --> 01:26:13.650 Das ist also auch relativ einfach. 01:26:13.990 --> 01:26:18.490 Was Sie sehen, ist, dass hier eine Bestätigung auf Protokollebene 01:26:18.490 --> 01:26:18.970 erfolgt. 01:26:19.130 --> 01:26:23.190 Es erfolgt keine Bestätigung auf, hat keinen Einfluss auf die 01:26:23.190 --> 01:26:23.530 Dienstschnittstelle. 01:26:24.290 --> 01:26:26.590 Die kriegt das gar nicht mit, das wird transparent gemacht. 01:26:28.770 --> 01:26:34.250 Wenn man ein bisschen mehr spendiert an Steuerinformation, dann kommt 01:26:34.250 --> 01:26:38.090 man genau zu diesen Sequenznummern, dass man eine implizite 01:26:38.090 --> 01:26:40.130 Bestätigung hier vorsieht. 01:26:41.270 --> 01:26:46.890 Die sieht so aus, dass man jetzt anfängt, die Pakete 01:26:46.890 --> 01:26:47.830 durchzunummerieren. 01:26:48.210 --> 01:26:52.190 Das ist also der nächste Schritt in der Fehlerbehandlung und 01:26:52.190 --> 01:26:53.230 Fehlerbearbeitung. 01:26:54.090 --> 01:26:57.250 Sie führen sogenannte Sequenznummern ein. 01:26:58.770 --> 01:27:04.270 Eine Sendefolgenummer, die nennen wir N von S, wird von der Sendeseite 01:27:04.270 --> 01:27:06.150 in aufsteigender Folge vergeben. 01:27:06.550 --> 01:27:08.630 Das heißt, Sie haben jetzt jedes Paket durchnummeriert. 01:27:09.530 --> 01:27:15.710 Und die Empfangsseite, die hat jetzt die Möglichkeit herauszubekommen, 01:27:16.890 --> 01:27:23.350 bis zu welchem Paket hat sie denn erfolgreich die Daten empfangen. 01:27:24.010 --> 01:27:28.470 Und das führt zu dieser Empfangsfolgenummer, die eben angibt auf 01:27:28.470 --> 01:27:29.750 Empfängerseite. 01:27:29.750 --> 01:27:34.690 Bis dahin habe ich die Pakete erfolgreich empfangen. 01:27:35.730 --> 01:27:41.710 Und entsprechend können wir über diese Empfangsfolgenummer jetzt eine 01:27:41.710 --> 01:27:46.210 implizite Bestätigung angeben, nämlich indem wir jetzt nicht nur ein 01:27:46.210 --> 01:27:50.210 Acknowledge angeben, sondern in dieses Acknowledge noch die 01:27:50.210 --> 01:27:51.710 Sequenznummer angeben. 01:27:52.290 --> 01:27:55.050 Also die Paketnummer, bis zu der wir erfolgreich empfangen haben, 01:27:55.050 --> 01:28:00.750 können wir also nicht immer nur ein Paket bestätigen, sondern eine 01:28:00.750 --> 01:28:02.010 ganze Folge von Paketen. 01:28:02.090 --> 01:28:06.450 Nämlich genau bis zu der Nummer, die angegeben ist, genau bis zur 01:28:06.450 --> 01:28:08.450 Nummer NS gleich N minus 1. 01:28:08.910 --> 01:28:10.810 Das heißt, dadurch haben wir eine implizite Bestätigung. 01:28:11.690 --> 01:28:19.690 Und auf der Basis von diesen Nummern setzen sehr viele komplexere 01:28:19.690 --> 01:28:21.270 Protokollverfahren auf. 01:28:21.370 --> 01:28:24.270 Also das Sliding-Window-Protokoll, das wir unter anderem behandeln 01:28:24.270 --> 01:28:28.670 werden, setzt genau auf diese Nummerierung von Paketen auf und 01:28:28.670 --> 01:28:31.730 Empfangsnummern und Sendennummern und Austausch dieser Informationen 01:28:31.730 --> 01:28:33.310 zwischen Sender und Empfänger. 01:28:34.130 --> 01:28:35.690 Gut, ich wäre soweit am Ende. 01:28:35.910 --> 01:28:36.870 Ich wünsche Ihnen ein schönes Wochenende. 01:28:37.570 --> 01:28:37.770 Danke.