1.1.:
Erklären sie warum sich das BSC-Protokoll ohne Änderungen nur gemäß STOP & WAIT und nicht via GO-Back-N ablaufen läßt.
- im BSC-Protokoll wurde ursprünglich der Stop & Wait Mechanismus eingebaut, da er sehr einfach zu implementieren ist
- Die einzelnen Blöcke werden nicht durchnumeriert, insofern ist es nicht möglich zum nten Block zurückzuspringen. Bestätigung erfolgt nur alternierend mit ACK0 oder ACK1
- Das BSC-Protokoll enthält weder für den Empfänger noch für den Sender einen Datenpuffer zur Effizienzsteigerung bereit, so dass mehrere Blöcke
hintereinander empfangen werden können Æ Go-Back-N hat Sliding Window Technik implementiert
--- 1.2.:
Was und an welcher Stelle muss geändert werden um den Ablauf gemäß Go-Back-N zu implementieren?
- Im Meldungsformat müsste zusätzliches Feld für Nummerierung der Datenblöcke mit einer Sequenznummer eingefügt werden. Æ Alternierende Bestätigung mit ACK0 oder ACK1 fällt weg
- Notwendige PufferReservierung beim Sender wegen Aufnahme von mehreren Blöcken.
- Pipelining zur Rahmenübertragung muß implementiert werden (Tanenbaum S. 234) Æ „continuous ARQ“ Æ Sender setzt mehrere Blöcke ab, ehe er wegen evtl.
ausstehenden ACK´s blockiert Æ Sliding-Window-Technik
--- 1.3.:
Welcher Flußkontroll-Mechanismus muß gleichzeitig zu Go-Back-N eingeführt werden?
- Es muß die Sliding-Window-Technik zur Flußkontrolle eingesetzt werden!
- Polling mit Continous Automatic Repeat Request(ARQ) Æ einer Station (Sender oder Empfänger) ist erlaubt mehrere Blöcke (PDU Protocol Data Unit) nacheinander zu senden, bevor auf eine Bestätigung gewartet wird und automatische
Wiederholung einer Sendung Konsequenzen:
- Notwendige Pufferreservierung auf beiden Seiten wegen Aufnahme von mehreren Blöcken
- Die Anzahl der Blöcke, die ohne Bestätigung gesendet werden dürfen, wird in Form von e. sog. „Window-Grösse“ vor dem Austausch der Information zwischen den beiden Partnern ausgehandelt.
--- 1.4.:
Nennen sie 3 Gründe warum das HDLC-Verfahren bei der Übertragung von Nutzdaten effizienter ist als MSV1.
- kann im full Duplex-Betrieb arbeiten
- verwendet keinen Stop & Wait Mechanismus für die Bestätigung, Nachrichten können mit einem Datenpaket bestätigt werden Æ es können mehrere Nachrichten ohne Bestätigung versendet werden Æ Go-Back-N Æ Sliding Windows
Anzahl von Bits - kein Master/Slave
--- 1.5.:
Kann man im Falle von HDLC mehrere Steuerframes hintereinander senden, ohne auf Bestätigung zu warten?
NEIN!
- es muss immer mit einem UA (Unnumbered Acknowledge) nach jedem Steuerframe geantwortet werden
- bestätigt nur den Empfang ohne einen bestimmten Steuerframe zu bestätigen - Insofern können nicht mehrere Steuerframes hintereinander gesendet werden, weil
sonst Unklarheit darüber herrscht, welcher Steuerframe bestätigt wird.
- im Fehlerfall (nach Eintritt eines Timeouts) werden Steuerframes noch mal geschickt.
--- 2.1.
In Netzen gemäß ISO 802.3 und 802.5 werden die elektronischen Signale mittels Manchester- Code übertragen. Warum werden die Signale nicht mittels einer gewöhnlichen binären Codierung übertragen?
Tanenbaum Seite 306
- eine gewöhnliche binäre Codierung führt zu Zweideutigkeiten
- Anfang, Mitte und Ende eines Bits ohne Bezugnahme auf externen Takt müssen vom Empfänger eindeutig erkannt werden
- bei Manchester-Codierung wird jede Bitperiode in zwei gleiche Intervalle unterteilt - binäre 1 (Signal im ersten Intervall hoch, im zweiten niedrig) und binäre 0 (Signal zu
erst Low, dann High)
- in der Mitte entsteht somit ein Übergang, was dem Empfänger die Synchronisation mit dem Sender erleichtert
- Problem mit Manchester: gegenüber einfacher Binärcodierung wird doppelte Bandbreite vorausgesetzt
--- 2.2.:
Bekannterweise werden im Falle von Netzen, die auf Ethernet basieren, die DataLink-Schicht mit Hilfe von zwei Unterschichten (MAC und LLC) oder nur mittels einer Schicht (MAC) realisiert.
Annahme: die höheren Protokollschichten werden direkt (naive Implementation) auf die MAC-Schicht (Ethernet oder Token Ring) aufgesetzt, um die Protokollabläufe zu
beschleunigen (eine Schicht weniger vorhanden). Was wird ohne LLC-Schicht nicht mehr gewährleistet? Begründung.
- LLC verbirgt Unterschiede zwischen den unterschiedlichen 802-Netzen Æ ohne LLC keine Kompatibiltät zwischen Ethernet – Token Ring möglich (Wegfall LLC- Header Æ keine Protokoll-ID zum auslesen)
- keine Flusskontrolle (falls Typ 1 oder 3), falls weitere unsichere Schicht darüber wäre überhaupt keine Kontrolle mehr da
---
2.3.:
Warum wird immer per Monitoring-Tools überprüft, ob ein auf Ethernet basierendes Netz nicht wesentlich über 50-60% der Bandbreite nutzt? Begründung.
Bei mehr als 60 % Netzlast gibt es so viele Kollisionen (Fehler), dass eine Datenübertragung unmöglich wird.
--- 2.4.:
Die Länge eines Ethernet-Frames beträgt 64 Bytes, um sicherzustellen, dass der Sender im Falle einer Kollision am entfernten Ende des Kabels noch läuft. Im Falle von Fast Ethernet wird die Mindestgröße beibehalten, die Bits aber 10mal schneller bewegt. Wie ist es möglich die gleiche minimale Fenstergröße beizubehalten?
- Kabeltypen müssen verändert werden Æ drastisch verkürzen
- gibt einen Algorithmus zur Berechnung der maximalen Länge (Tanenbaum)
--- 2.5.:
Man unterscheidet MAC- und LLC-Frames.
2.5.1.: Welche Rolle haben die MAC-Frames?
2.5.2.: Wer interpretiert und bearbeitet diese Frames?
2.5.3.: Welches sind die äquivalenten Frames zu den oben genannten im Falle eines Ethernet- Zugriffverfahrens?
2.5.1.:
MAC-Frames dienen zur Überwachung und Steuerung des Token Rings, werden benutzt damit die Ringfunktionen (im IEEE 802.5) aufrecht erhalten werden können.
2.5.2.:
Erzeugt und bearbeitet werden sie vom Microcode des Controllers und können vom Ringverwalter oder Ringanalysator aufgezeichnet werden. Bearbeitet werden diese Frames von allen Stationen. Active Monitor überwacht diese Frames
2.5.3.:
gibt es keine!!!
--- 3.1.:
Warum bekommt jeder IP-Frame der die Station verlässt eine Nummer?
- Vermittlungsschicht von TCP-Suite garantiert keine Übertragung und auch keine Reihenfolge der Pakete
- jedes Paket benötigt eindeutige ID (Identifizierung), damit doppelte Pakete von höheren Schichten vermieden bzw. identifiziert werden können
- ohne ID wäre keine Fehlerkontrolle und Flußkontrolle realisierbar
--- 3.2.:
ARP-Meldungen werden als Broadcast-Meldungen generiert.
3.2.1.: Werden diese Meldungen innerhalb eines Switches an alle Anschlüsse weitergeleitet?
3.2.2.: Werden diese Meldungen innerhalb eines Routers an alle Anschlüsse weitergeleitet?
3.2.3.: Werden diese Meldungen an alle VLANs eines Switches weitergeleitet?
- Ja!
- Switch kennt keine IP-Adressen (nur HW-Adressen) - Switch ist innerhalb eines Subnetz
3.2.2.:
- Nein!
- Router verbindet Subnetze miteinander - Broadcast nur innerhalb eines Subnetz 3.2.3.:
- Nein!
- Broadcast geht nur an Rechner in aktuellem VLAN - VLAN stellt eigenes Subnetz dar
--- 3.3.:
Welche Bedeutung hat die „Window-Size“ für TCP-Frames?
- Fensterverfahren entwickelt, bei denen der Sender vor dem Erhalt einer
Nachrichtenquittung eine festgelegte Anzahl von Nachrichten (Fenstergröße w) senden darf.
- Window-Größe = maximaler Empfangspuffer
- Window-Größe wird bei jedem Frame mitgesendet Æ wie viele Pakete im Moment mitgesendet werden können
--- 3.4.:
Zwei Stationen sind an einem shared Ethernet Segment angeschlossen. Diese Stationen erhalten IP-Adressen aus unterschiedlichen IP-Klassen-Bereichen. Wie läßt sich die Datenübertragung zwischen den Stationen realisieren? (zusätzlich Skizze)
Bridge oder Router muss zwischen den beiden Segmenten liegen
--- 3.5.:
Ein Netz der Klasse B im Internet hat folgende Subnetzmaske 255.255.240.0. Wieviele Hosts werden innerhalb des Netzes adressiert?
240.0 = 11110000.00000000 = 12 Bits für Host-ID = 212 = 4096 Æ 4094 Hosts können verwaltet werden (zwei sind reserviert!!!)
--- 4.1.:
Welches Programm dürften diese Frames erzeugt haben?
- Traceroute, weil TTL exceeded und ICMP Echo
- Ping scheidet aus, weil unterschiedliche und vor allem wechselnde IPs - der Client, der TTL exceeded schickt hat wechselnde IP
---
4.2.:
Nennen sie die ersten 3 Router, die ein Frame auf seinem Weg beginnend bei Station 194.95.108.59 bis Station www.uni-erlangen.de durchlaufen muss.
- ab Frame #4: 194.95.108.250 - ab Frame #10: 194.95.104.254 - ab Frame #16: 132.199.24.1
--- 5.1.:
Welche Bedeutung haben die Frames #1 und #2?
- ARP-Broadcast-Meldung um die zur IP-Adresse 194.95.108.250 zugehörende HW- Adresse (MAC) zu bekommen
- PCU4 erhält zugehörige MAC-Adresse
--- 5.2.:
Wozu dient der Port-Befehl in Frame #18?
#18:
rfhnt8001.fh-reg…. [194.95.108.59] DLC Ethertype=0800, size=79 bytes IP D=[194.95.108.38] S=[194.95.108.59] LEN=45 ID=40704
TCP D=21 S=1034 ACK=599354687 SEQ=586433 LEN=25 WIN=8608 FTP-data C PORT=1034 PORT 194,95,108,59,4,11
- 4*256 + 11 = 1035
- am Client wird HighPort #1035 aufgemacht, damit darüber in der FTP-Sitzung Daten geschickt werden können
--- 5.3.:
Identifizieren sie den Aufbau der ersten FTP-Datenverbindung.
- Frames #22 bis #24 über 3-Way-Handshake
