Bachelorthesis Robert Ballon Intelligentes Mikrofonsystem - Einsatzszenarien und Realisierung
Bachelorthesis Analyse des MMRP-Protokolls nach IEEE 802 ...
Transcript of Bachelorthesis Analyse des MMRP-Protokolls nach IEEE 802 ...
Bachelorthesis
Analyse des MMRP-Protokolls nach IEEE
802.3ak einschließlich Erstellung einer
zustandsorientierten Simulation des Protokolls
auf Basis von OMNeT++ sowie weiterer Tools
fur Testzwecke
im Studiengang Technische Informatik
der Fakultat Informationstechnik
7. Semester
Johannes Jochen
Holderlinweg 6, 73730 Esslingen am Neckar
Zeitraum: 07.02.2011 bis 30.06.2011
Datum: 30. Juni 2011
Prufer: Prof. Reinhard Keller
Betreuer: Prof. Reinhard Keller
Firma: Hirschmann Automation and Control GmbH
Betreuer: Dipl.-Ing. (FH) Markus Seehofer und Dipl.-Inform (FH) Jochen Dolezal
Ehrenwortliche Erklarung
Ich versichere, die vorliegende Bachelor-Arbeit selbstandig und ausschließlich unter Verwen-
dung der angegebenen Quellen und Hilfsmittel erstellt zu haben.
Die Arbeit wurde bisher in gleicher oder ahnlicher Form keiner anderen Prufungsbehorde vor-
gelegt und auch nicht veroffentlicht.
Esslingen, den 30. Juni 2011
Unterschrift
ii
Sperrvermerk
Der nachfolgende Hausarbeit enthalt vertrauliche Daten der Hirschmann Automation and Con-
trol GmbH. Veroffentlichungen oder Vervielfaltigungen dieser Arbeit – auch nur auszugsweise –
sind ohne ausdruckliche Genehmigung der Hirschmann Automation and Control GmbH nicht
gestattet. Diese Arbeit ist nur den Prufern sowie den Mitgliedern des Prufungsausschusses
zuganglich zu machen.
iii
Vorwort und Danksagung
Die Firma Hirschmann GmbH wurde 1924 von Richard Hirschmann gegrundet. In der An-
fangszeit wurde die Firma vor allem durch ihren Bananenstecker bekannt, der noch heute in
der Elektrotechnik Verwendung findet.
Ab ca. 1933 wurden damit begonnen, Radioempfanger zu bauen. Schnell machte sich die
Firma Hirschmann GmbH einen Namen mit zuverlassigen Antennen- und Empfangssystemen.
Der Firmengrunder “war Mitbegrunder und Senator der Technischen Akademie Esslingen sowie
Ehrensenator der Universitat Stuttgart”.1
Ab 1997 wurde die Firma durch die Reinmetall AG ubernommen, welche “das Unterneh-
men 2004 an den englischen Investor Hg Capital verkaufte”.2 Daraufhin wurde die Firma
restrukturiert und ein Teil als Hirschmann Automation and Control GmbH (HAC) an das
US-Unternehmen Belden verkauft.
Heute ist die HAC ein Spezialist fur Automatisierungs- und Netzwerktechnik im Bereich
des Industrial-Ethernet. Meine Arbeit im Bereich der Netzwerktechnik konnte hierdurch sehr
profitieren. Dies ist auch auf die gute Betreuung durch Herrn Markus Seehofer und Herrn
Jochen Dolezal zuruckzufuhren, die mir hilfreich zur Seite standen.
1Quelle: [15]2Quelle: [15]
iv
Inhaltsverzeichnis
1 Abkurzungsverzeichniss vii
2 Einfuhrung 1
3 Grundlagen 3
3.1 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Das Internet-Protokoll: IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Unicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4.1 Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4.2 IP-Adressen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 Netzaufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.1 Statisches Netz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5.2 Dynamisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6 Multicast-Adressen dynamisch . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.6.1 IP-“Internet Group Managment Protocol” . . . . . . . . . . . . . . . . . 18
4 Multicast Verteilung nach IEEE 802.1 22
4.1 Funktionelles Kompendium fur MRP . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2 Zustandsautomaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Registrar state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.2 Applicant state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.3 LeaveAll state machine . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.4 PeriodicTransmission state machine . . . . . . . . . . . . . . . . . . . . . 37
5 Simulation mit OMNeT++ 38
5.1 Modell Aufbau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
v
vi Inhaltsverzeichnis
5.2 Registrar Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 Applicant Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.4 LeaveAll Modul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.5 Port Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
5.6 Aufbau des Switch-Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.7 Netzwerkmodul und Simulationsaufbau . . . . . . . . . . . . . . . . . . . . . . . 54
6 Paketformat und Testtools 58
6.1 MMRP-Paketgenerator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.2 Wireshark Dissector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
7 Zusammenfassung und Ausblick 67
1 Abkurzungsverzeichniss
ARP Address Resolution Protocol
BPDU Bridge Protocol Data Unit
CPU Central Processing Unit
CRC Cyclic Redundancy Check
DSAP Destination Service Access Point
DP Designated-Port
FCS Frame Check Sequence
FDB Forwarding Data Base
GARP Generic Attribute Registration Protocol
GMRP GARP Multicast Registration Protocol
IANA Internet Assigned Numbers Authority
IEEE Institute of Electrical and Electronics Engineers
IGMP Internet Group Managment Protocol
IP Internet Protokoll
IPv4 Internet Protokoll version 4
LLC Logic Link Control
MAC Medium Access Control
vii
viii
MMRP Multiple MAC Registration Protocol
MRP Multiple Registration Protocol
NED Network Description
OUI Organizationally Unique Identifier
PID Packet Identifier
RP Root-Port
RSTP Rapid Spanning Tree Protocol
SAP Service Access Point
SNAP Subnetwork Access Protocol
SSAP Source Service Access Point
STP Spanning Tree Protocol
TTL Time To Life
TOS Type of Service
2 Einfuhrung
Im Internet, aber auch in den lokalen Netzwerken, wunschen sich die Kunden vermehrt Video-
/Audio-Live Streams On-Demand zu erhalten. Die Losung dafur heißt meist, einen einzelnen
Server bereitzustellen, der diese Anfragen uber Unicast-Verbindungen erledigt. Dabei konnen
aber Lastprobleme sowohl im Netzwerk als auch auf dem Server auftreten. Zur Losung dieses
Problems stehen Multicast-Adressen zur Verfugung. Multicast-Adressen konnen dabei statisch
in den Netzwerkknoten eingetragen werden oder aber dynamisch uber ein entsprechendes Pro-
tokoll bekannt gemacht werden. Diese Arbeit beschaftigt sich mit der dynamischen Verteilung
durch das Multiple MAC Registration Protocol (MMRP), das als Nachfolger des GARP Multi-
cast Registration Protocol (GMRP) aus der IEEE 802.3D ist. In der Arbeit wird das Verhalten
des Protokolls im Falle einer Anderung der Topologie durch ein Redundanz-Protokoll wie RSTP
untersucht. Die Erstellung eines Paketgenerators und eines Wireshark-Dissectors ist ebenfalls
Teil der Arbeit.
Uber MMRP wird dem Empfanger eines Streams ermoglicht, der Multicast-Gruppe eines
Switches beizutreten, so dass dem Empfanger von einem Sender aus ein Stream zugestellt
werden kann. MMRP propagiert die betreffende Information uber die beteiligten Switche und
registriert den Wunsch, betroffene Multicast-Nachrichten an die entsprechenden Ports weiter-
zuleiten.
Gesteuert wird MMRP, wie auch GMRP, im Wesentlichen uber drei Zustandsautomaten. Der
Automat des MMRP wird dabei lediglich um weitere Ereignisse fur Protokolle wie das RSTP
erganzt. Dies ist erforderlich, damit MMRP im Fehlerfall eine schnellere Neuregistrierung der
Multicast Adressen in den Switches veranlassen kann.
Die Uberprufung der erweiterten Funktionalitat erfolgte mithilfe einer im Rahmen der Ar-
beit erstellten Simulation auf Basis des Simulationswerkzeugs OMNeT++. Durch die Simula-
tion konnte gezeigt werden, dass MMRP nach Erkennung einer Topologieanderung durch das
Redundanz-Protokoll nur ca. 300ms zum Aufbau der neuen Kommunikationsstruktur benotigt,
wahrend bei GMRP im schlechtesten Fall bis zu 15s beobachtet werden. Zudem hat sich gezeigt,
1
2
dass die Ausfallzeit wesentlich durch das Redundanz-Protokoll beeinflusst wird. So erkennt
RSTP einen Verbindungsverlust erst nach ca. 6s, wahrend das Media Redundancy Protocol
(MRP), das in Switches von Hirschmann eingesetzt wird, fur die Erkennung des Verlusts einer
Verbindung und das Freischalten eines redundanten Pfades im Worst-Case-Fall max. 500ms
benotigt (Typisch sind <40ms).
Insgesamt ermoglicht der Einsatz eines schnellen Redundanz-Protokolls und die Propagie-
rung der Multicast-Adressen uber MMRP im Fehlerfall sehr niedere Latenzzeiten auch fur die
Kommunikation mithilfe von Streams.1
1Quelle: [8] Seite 16
3 Grundlagen
Dieses Kapitel liefert einen Uberblick uber die verwendete Netzwerktechnik. In den ersten
Abschnitten wird eine Einfuhrung des Netzwerkstack zu Ethernet begonnen. Anschließend wird
das aufbauende Protokoll des IP Verkehrs naher betrachtet und erlautert. In der Bachelorarbeit
wird ein Verfahren zur Verteilung von Multicast Adressen erortert. Aus diesem Grund wird im
Grundlagenteil der Arbeit der Unterschied zwischen Unicast Verkehr und Multicast Verkehr
naher betrachtet.
Die Netzwerke konnen verschiedene Topologieformen aufweisen. Da dies das Netzwerkproto-
koll MMRP beeinflussen kann, ist im Grundlagenteil unter anderem das Rapid Spanning Tree
Protocol (RSTP)-Protokoll behandelt. Das Protokoll zur Verteilung von IP Multicast Adressen
ist am Schluss des Grundlagenteils aufgefuhrt.
3.1 Ethernet
Das Ethernet Frame stellt die untersten logischen Datenframes dar. Danach wird das Frame
direkt auf die Datenleitung, also das physikalische Medium gelegt. In diesem Frame sind die
48 Bit Medium Access Control (MAC)-Adressen der Kommunikationspartner enthalten. Sie
stellen die Quellen- und Zieladressen dar. Das erste Bit der MAC-Adresse enthalt dabei das
individual/gruppen Bit. Die Adressen unterscheiden sich durch die Tatsache, ob es sich um eine
Unicast (Abschnitt 3.3) oder um eine Multicast-/Brodcast-Adresse (Abschnitt 3.4) handelt. Die
nachsten Felder unterscheiden sich hinsichtlich des Aufbaus des Types. Sie konnen vom Type
Ethernet-II-Frame oder ein IEEE 802.3-Frame sein. Bei dem IEEE 802.3-Frame steht an dieser
Stelle nun ein Lange-Feld des Daten-Paketes. Aus technischen Grunden muss das Frame min.
64 Byte groß sein. Das Datenfeld muss durch ein PAD-Feld mindestens auf 46 Bytes aufgefullt
werden, ist es allerdings schon großer als 46 Byte, wird das PAD-Feld nicht gebraucht. Der
Schluss des Frames stellt die Frame Check Sequence (FCS) dar. In ihr befindet sich eine 32 Bit
große Cyclic Redundancy Check (CRC).
3
4 3.1. ETHERNET
SNAP OUI SNAP PID Daten3 Bytes 2 Bytes Variabel
DSAP SSAP Ctrl Daten
1 Byte 1 Byte 1-2 Bytes Variabel Variabel
PAD(wenn
gebraucht)
Zieladresse Quellenadresse Länge Daten FCS (CRC)8 Bytes 6 Bytes 6Bytes 46-1500 Bytes 4 Bytes2 Byts
Präambel
Abbildung 3.1: Genereller Aufbau eines Ethernet IEEE 802.3 Frames mit LLC und SNAP
Einbettung
Abbildung 3.1 zeigt ein Ethernet Frame. Das Frame teilt sich in zwei wesentliche Frame-
Teile auf. Der untere Teil stellt das bereits besprochene MAC-Frame dar. Der obere Teil, welcher
im MAC-Frame eingebettet ist, stellt das Logic Link Control (LLC)-Frame dar.
Im LLC-Frame gibt es zum Aufteilen der Datenstrome unterschiedliche Service Access Points
(SAP): Die Destination Service Access Point (DSAP) und die Source Service Access Point
(SSAP). In der DSAP ist das erste Bit das Group bzw. Individual Bit. Bei der SSAP dient
das erste Bit als Command oder als Response Bit. Dadurch bleiben nur noch 128 Service-
Punkte zur Verfugung. Um dies aufzuweichen, gibt es in dem Datenteil des LLC-Frames noch
die Moglichkeit, das Subnetwork Access Protocol (SNAP) einzubauen. Die SNAP-Erweiterung
wird anhand der Service Access Point (SAP) id’s: 0xAA und dem Wert 0x03 im Ctrl-Feld
erkannt. Das SNAP-Paket setzt sich aus mehreren Feldern zusammen:
1. Feld ist der SNAP-Organizationally Unique Identifier (OUI).
2. Feld ist der SNAP-Packet Identifier (PID).
3. Datenteil, in denen eine hohere Schicht Daten ablegen kann.
In SNAP lasst sich auch ein EtherType Paket unterbringen. Dazu mussen die Felder SNAP-OUI
= 0x000 und das Feld SNAP-PID den Wert des EtherTypes annehmen. In Abbildung 3.3
sieht man dies beispielhaft fur IP-Pakete, mit dem sich der nachste Abschnitt beschaftigt.1
1Nach [4] Seite 27ff und [10]
KAPITEL 3. GRUNDLAGEN 5
Abbildung 3.2 zeigt das einfachere und altere Ethenet-II-Frame. Es unterscheidet sich vom
IEEE 802.3-Frame hauptsachlich durch das dritte Byte. Im Ethernet-II-Frame steht hier das
Type-Feld, welches den EtherType enthalt. Dieses dient, ahnlich wie das LLC-SAP-Feld, zum
Verteilen des Protokolls an die hoheren Schichten. Da das Ethernet-II-Frame direkt ein Type-
Feld enthalt und die erweiterten Funktionen von LLC nicht unterstutzt, hat es auch keine LLC-
SAP oder SNAP Unterstutzung.
Zieladresse Quellenadresse Type Daten FCS (CRC)8 Bytes 6 Bytes 6Bytes 46-1500 Bytes 4 Bytes2 Byts
Präambel
Abbildung 3.2: Genereller Aufbau eines Ethernet-II-Rahmens. Dieser unterscheidet sich zum
IEEE802.3 Frame nur in dem Type-Feld.
3.2 Das Internet-Protokoll: IP
Dieser Abschnitt beschaftigt sich mit dem Aufbau des Internet Protokoll (IP)-Frames. Dabei
sind die hoheren Protokolle (z.B TCP/UDP) fur die Betrachtung der Arbeit uninteressant und
in dem Grundlagenteil nicht naher beschrieben.
ARP DatenSNAP OUI SNAP PID
0x0806
IP DatenSNAP OUI SNAP PID
0x0800
MAC-Frame
LLC-Frame
SNAP-Frame
Präambel Zieladresse Quellenadresse Länge SNAP PID Daten FCS (CRC)
8 Bytes 6 Bytes 6Bytes 1 Byte 1 Byte 3 Bytes 2 Bytes Variabel Variabel 4 Bytes
8 Bytes 14 Bytes 46 1500 Byte 4 Bytes
DSAP0xAA
SSAP0xAA
Ctrl0x03
SNAP OUIPAD
(wenn gebraucht)
2 Byts
-
1
0x00-00-00
0x00-00-00
0x00-00-00
Byte
Abbildung 3.3: Einbettung des IP und des ARP-Protokolls in ein LLC/SNAP-Frame. Mithil-
fe der SAP-Adresse 0xAA und den verschiedenen EtherType fur IP (0x0800)
und ARP (0x0806). Nach: [11]
Das IP-Paket bettet sich beim IEEE 802.3-Frame in die SNAP-Erweiterung ein. Die Werte
fur die LLC-Felder sind prinzipell der Abbildung 3.3 zu entnehmen. Beispielhaft ist auch das
ARP-Unterprotokoll aufgefuhrt, um aufzuzeigen, dass nicht nur das IP-Protokoll mit seinem
EtherType 0x0800 sich in das SNAP-Feld einbetten lasst.
6 3.2. DAS INTERNET-PROTOKOLL: IP
ARP DatenType0x0806
IP DatenType0x0800
Präambel Zieladresse Quellenadresse Type Daten FCS (CRC)
8 Bytes 6 Bytes 6Bytes Variabel Variabel 4 Bytes8 Bytes 14 Bytes 46-1500 Byte 4 Bytes
PAD(wenn
gebraucht)
2 Byts
MAC-Frame
Abbildung 3.4: Einbettung des IP und des ARP Protokolls in Ethernet-II-Frames mithilfe
der verschiedenen EtherType fur IP (0x0800) und ARP (0x0806). Nach: [11]
Im alteren Ethernet-II Frame ist der EtherType ein direkter Teil der MAC-Schicht. Somit
lassen sich die IP-Pakete dort direkt einbetten. Dies stellt auch die Abbildung 3.4 ubersichtlich
dar. Auch in dieser Abbildung ist das ARP-Protokoll beispielhaft aufgefuhrt.
Das Ethernet-Paket breitet sich nur innerhalb eines kleinen Netzwerkes aus, welches aus
Verteiler-Knoten aufgebaut ist. Diese Knoten sind heutzutage meistens sogenannte Switches.
Die Switche stellen dabei eine logische Grenze dar. Damit diese Pakete auch bei großeren
Netzwerken verteilt werden konnen, kommt das IP-Protokoll ins Spiel. Die Grate, die solche
Netzwerke miteinander verbinden, nennen sich Router.
0 8 16 24 32 BitVersion TOS
data
Header Lenght total lengthidetification flags fragmantation offset
time to life (TTL) protocol header checksumsource IP Address
destination IP Addressoptions(if any)
20bytes
Abbildung 3.5: Der Aufbau des IP-Frames. Ersichtlich ist, dass es einen eigenen Header mit
20 Bytes pro Paket mit sich bringt. Nach: [11]
Das in der Arbeit besprochene und in Abbildung 3.5 dargestellte IP-Paket ist die Version 4
des Protokolles, welches auch Internet Protokoll version 4 (IPv4) genannt wird. Diese Version
ist auch im ersten 4 Bit Feld des Paketes eingebaut. Das Header Length Feld beschreibt die
Lange des IP-Headers. Dies ist notig, da durch das options Feld die Große des Headers sich
andern kann. Dabei ist die Anzahl der 32 Bitworter des headers angegeben. Die Große ist notig,
damit zusatzlich Daten in das options Feld eingebaut werden konnen. Insgesamt ist der Header
KAPITEL 3. GRUNDLAGEN 7
somit auf 60 Bytes beschrankt. Das darauf folgende Type of Service (TOS)-Feld besteht aus 8
Bit. Die ersten 3 Bit dienen einer Prioritatseinteilung; danach folgen 4 Bit fur TOS und ein nicht
belegtes Bit, das den Wert 0 enthalt. Die 4 Bit TOS durfen nur einzeln gesetzt werden, d.h.
es ist eine Kombination nicht moglich. Das ergibt dann 4 mogliche TOS-Zustande: minimize
delay, maximize throughput, maximize reliability und minimize monetary cost. Das total length
Feld gibt die gesamte Große des IP-Paketes in einem 16-Bit (2 Byte) Feld an. Damit konnen
bis zu 65535 Byte in einem Paket ubertragen werden. Ethernet unterstutzt aber nur 1500
Byte. Dieses Problem ist mit dem identification und fragmentation offset Feld behandelt. Das
identification Feld gibt immer das gleiche zusammengehorige Paket an und das fragmentation
offset Feld gibt die Position des Fragmentes im Datenstrom an. Das Time To Life (TTL)-Feld
gibt an, uber wie viele Router ein IP-Paket geschickt werden darf. Jeder Router, der ein IP-
Paket weiterleitet, dekrementiert dieses Feld. Sobald dieses Feld bei Null angekommen ist, ist
das Paket zu verwerfen und nicht mehr weiterzuleiten. Das protocol Feld dient dem Multiplexen
der IP-Daten an die hohere Schicht. IP transportiert Daten fur andere Protokolle. Um diese zu
unterscheiden ist das Feld da. Das Feld header checksum dient zum Absichern des IP headers.
Jedes IP-Paket enthalt eine 32-Bit-Absender- und Empfanger-Adresse. (Die source address und
die destination address) Die IP-Adresse ist nicht mit der MAC-Adresse zu verwechseln. Sie kann
durch das ARP-System zwischen den Adressen ubersetzt werden.[13]
3.3 Unicast
Verbindungen konnen uber die Switches verschieden verteilt werden. Nachfolgend sind in der
Arbeit zwei Typen dieser Verbindungsarten naher betrachtet.
Unicast stellt direkte Verbindungen zwischen zwei Teilnehmern dar. Vorstellbar ist dies wie
ein Telefongesprach zwischen zwei Personen. So stellt ein Switch die Telefonzentrale dar. In
der Abbildung 3.6 sind das die blauen Rechtecke mit den Pfeilen. Hier baut ein Empfanger
uber die Switche eine direkte Verbindung zum Sender auf. In diesem Beispiel sind dadurch drei
direkte Verbindungen vom Sender zu den drei Empfangern notig. Wenn nun die drei Empfanger
den gleichen Daten-Strom (auch stream genannt) empfangen wollen, generieren sie beim Sender
die dreifache Last. Um diese Last nun zu verringern, gibt es zwei Moglichkeiten: Der Sender
sendet an eine Broadcast bzw. Multicast Adresse. Die Broadcast Adresse hat den Nachteil, dass
jeder Endpunkt den Stream bekommt, ob er ihn benotigt oder nicht. Diese Lage verbessert sich
bei der Multicast Adresse.
8 3.4. MULTICAST
S E
E
E
Abbildung 3.6: Aufbau eines einfachen Netzwerkes. Die blauen Knoten stellen Switches dar.
Symbolhaft sind dabei nur Empfanger und Sender dargestellt; es konnen noch
weitere End-Knoten an den Switchen angeschlossen sein.
3.4 Multicast
Broadcast und Multicast Adressen sind beides Gruppenadressen. Broadcast kann man sich z.B.
als einen Radio-Sender vorstellen. Der Nachteil ist, dass dieser Sender an jeden sein Programm
ausstrahlt, egal ob er das Programm empfangen will oder nicht. Multicast hingegen kann dem
Empfanger gezielt mitteilen, dass er einen bestimmten Sender empfangen mochte, der auf dieser
Gruppenadresse sendet. Dadurch wird erreicht, dass nur noch die Empfanger eine Nachricht
vom Sender bekommen, die sich auch dafur interessieren. Der Sender wiederum sendet auf dieser
Gruppenadresse und braucht nicht einzelne Verbindungen zu den Empfangen verwalten. Somit
ist vom Sender zum Switch nur noch eine Verbindung notig. Der Switch wiederum verteilt und
verwaltet diese Muticast-streams. Wie er das macht, wird spater noch genauer vorgestellt.
KAPITEL 3. GRUNDLAGEN 9
S E
E
E
Abbildung 3.7: Aufbau eines einfachen Netzwerkes. Hier sind die Verbindungen allerdings
uber eine Multicast-Adresse gelost
3.4.1 Adressen
Damit Broadcast, Multicast und Unicast auseinandergehalten werden konnen, gibt es fur die
IPv4- und MAC-Adressen jeweils eigene Adressen bzw. Adressenbereiche. Im Folgenden sind
sie kurz beschrieben.
IP Adressen bauen sich aus einer Netzwerkmaske und der eigentlichen Adresse auf. Sie sind
dabei 32 Bit lang und sind zur besseren Ersichtlichkeit je 8 Bit durch einen Punkt getrennt.
Durch die Netzwerkmaske wird das lokale Netzwerk maskiert. Sie gibt an, wie viele Bits der
Adresse frei wahlbar sind. Dies ist wichtig zu wissen, da sich dadurch zwei reservierte Adressen
ergeben. Die erste reservierte Adresse ist die Subnet Broadcast Adresse. Sie ist dadurch defi-
niert, dass die verfugbaren freien Bits jeweils mit einer 1 encodiert werden. So sind z.B. bei
dem Netz 192.168.1.0/242 die letzten 8 Bits auf 1 gesetzt, so ergibt die Broadcast-Adresse:
192.168.1.255. Es gibt auch noch die globale Netz-Broadcast-Adresse: 255.255.255.255. Hier
sind alle 32 Bits der Adresse auf “1” gesetzt. Der Unterschied zwischen diesen beiden Adressen
2192.168.1 sind die feststehenden Bits, die sich aus der /24-Schreibweise der Netzmaske ergibt. Naheres hier:[14]
10 3.4. MULTICAST
besteht lediglich darin, dass sie bei einem Rechner, der mehrere IP-Adressen und oder Netz-
werkarten besitzt, die IP Adresse 255.255.255.255 automatisch an alle vorhandenen Interfaces
die Nachricht uber die Broadcast-Adresse sendet.
MAC-Adressen sind 48 Bit lang und besitzen im Gegensatz zu den IP-Adressen keine Netz-
maske. Sie sind zur besseren Lesbarkeit in hexadezimaler Schreibweise dargestellt und meist alle
8 Bit durch einen Doppelpunkt getrennt. 00:80:63:23:42:2A stellt eine solche MAC-Adresse
dar. Die Broadcast-Adresse der MAC-Adresse ist die FF:FF:FF:FF:FF:FF. Gruppen- und damit
Multcast-Adresse werden anhand des group bits der MAC-Adresse erkannt. Dieses ist das erste
Bit der MAC-Adresse. Die MAC-Adresse 01:80:C2:00:00:20 stellt also eine Multicast-Adresse
dar. Zu beachten ist allerdings, dass das erste Byte 01 durch die kanonisches Darstellung wie
Little Endian im Speicher dargestellt wird. Auf der Leitung steht aber weiterhin noch die Bit-
Reihenfolge: 10000000 00000001 01000011 ... Siehe auch:[10] Seite 126ff.
3.4.2 IP-Adressen
Switche arbeiten meist auf der MAC-Adressen-Ebene. Die Umsetzung der Unicast-IP-Adres-
sen nach Unicast-MAC-Adressen erledigt das ARP-Protokoll. Diese Arbeit beschaftigt sich
allerdings mit Multicast-Adressen und geht daher nicht naher auf das ARP-Protokoll ein. In-
formationen dazu auch hier: [13]
Die IP-Multicast-Adresse ist durch die Codierung der ersten vier Bits auf eine “1” festgelegt.
Die Adresse und der Adressenbereich folgt daraus: 224.0.0.0/4. Der Bereich ist dabei von der
Adresse 224.0.0.0 bis 239.255.255.255. Die IP-Multicast-Adressen werden auf die MAC-
Adresse durch einen festen Block von MAC-Adressen gelegt. Dazu hat die Internet Assigned
Numbers Authority (IANA) einen Bereich fur MAC-Adressen reserviert: 00:00:5E:00:00:00
bis 00:00:5E:FF:FF:FF. Sie nutzt allerdings nur eine Halfte der zur Verfugung stehenden
Adressen fur die IP-Multicast-Adressen und da bei MAC-Adressen das erste Bit “1” sein muss,
um eine Gruppenadresse zu ergeben, ist der entsprechende Bereich hierfur 01:00:5E:00:00:00
bis 01:00:5E:7F:FF:FF. Die Multicast-Adressen haben also auf der IP-Seite 228 Adress-Moglich-
keiten, wahrend auf der MAC-Seite nur 223 Adress-Moglichkeiten zur Verfugung stehen. Hieraus
resultiert, dass es bei 228−23 = 25 = 32 Adressen zu doppelten Adressen auf dem MAC-Layer
kommt. 3
3Informationen aus dem Abschnitt aus [11] Seite 175ff.
KAPITEL 3. GRUNDLAGEN 11
3.5 Netzaufbau
Bei Ethernet-Netzen sind viele verschiedene Varianten der Netztopologie moglich. So kann man
z.B. alles von einem sternformigen uber ein baumartiges bis hin zu einer Linien-Verkabelung
bauen. Allerdings sind all diese Netzwerkarten meist statisch und vertragen auch keine Schleifen
in der Verkabelung zwischen den Netzwerk-Komponenten. In den nachsten beiden Abschnitten
sind die Unterschiede naher betrachtet.
3.5.1 Statisches Netz
Netzwerke, die sich nicht verandern aber auch kleinere Netzwerke, werden meist statisch ein-
gerichtet. Das heißt, dass sie unter anderem auf eventuell redundante Verbindungen verzichten
konnen und somit der Ausfall einzelner Verbindungen manuell zu beheben ist. Zusatzlich ist
die Netztopologie so ubersichtlich, dass es nicht zu versehentlich gesteckten Schleifen innerhalb
der Topologie kommt. Schleifen im Netzwerk haben die unangenehme Eigenschaft das einmal
gesendete Multi- oder Brodcast-Nachrichten die Schleife nicht mehr verlassen. Dadurch kann es
zu einer Beeintrachtigung und im schlimmsten Fall zu einem Stillstand des Netzwerkverkehrs
fuhren.
3.5.2 Dynamisch
In einem dynamischen Netzwerk lost ein Redundanz-Protokoll das Problem der Netzwerk-
schleifen. Dabei hat es auch den positiven Nebeneffekt, dass ein Netzwerkadministrator redun-
dante Verbindungen aufbauen kann. Der Switch schaltet diese Verbindung im Fehlerfall um.
Die nachsten Abschnitte behandeln dabei zwei verschiedene Redundanz-Protokolle; einmal das
Spanning Tree Protocol (STP) und sein Nachfolger Rapid Spanning Tree Protocol (RSTP) sowie
das Multiple Redundency Protokoll (hier auch MRP).
STP
In der Arbeit ist als erstes STP erklart. RSTP leitet sich von dem STP ab und hat prinzipbe-
dingt ahnliche Mechanismen.
STP baut, wie der Name schon vermuten lasst, einen Baum uber das aktive Netzwerk auf.
Redundante Teile des Netzwerkes sind dadurch abgeschaltet. Um den Wurzelknoten (auch Root-
Knoten genannt) zu finden, wird eine SwitchID vergeben und der Knoten mit der kleinsten
12 3.5. NETZAUFBAU
SwitchID ist der Root-Knoten. Diese SwitchID ist 64 Bit lang und besteht aus einem frei
wahlbaren 16 Bit Feld, das die Prioritat bestimmt und der 48 Bit langen MAC-Adresse des
Switches.
Es gibt weitere Parameter um eine redundante Verbindung am gleichen Switch zu erkennen.
Diese Parameter dienen der Entscheidung, welcher Port aktiv geschaltet wird. Dies wird uber
den Port Identifier und die Link Cost bestimmt. Der Port Identifier ist ein 2 Byte großer Wert,
in dem die ersten 8 Bit fur ein frei wahlbares priority Feld besteht und die zweiten 8 Bit aus
der Port Nummer des Anschlusses.
Die Link Cost wurden fruher uber eine lineare Berechnungsformel errechnet:4
LinkCost =1000
DataRateMb/s
Allerdings ist mit dem Aufkommen des 100 Mb/s Ethernets und des 1 Gb/s Ethernets die
Zahl klein geworden und um den moglichen Wertebereich ausnutzen zu konnen ist man auf
eine nichtlineare Verteilung nach Tabelle 3.8 ubergegangen.
Link SpeedRecommended
valueRecommended
rangeRange
<=100 Kb/s 200 000 000*
*Bridges conformant to IEEE Std 802.1D, 1998 Edition, i.e., that support only 16-bit values for Path Cost,should use 65 535 as the Path Cost for these link speeds when used in conjunction with Bridges that support32-bit Path Cost values.
20 000 000–200 000 000 1–200 000 000
1 Mb/s 20 000 000a 2 000 000–200 000 000 1–200 000 000
10 Mb/s 2 000 000a 200 000–20 000 000 1–200 000 000
100 Mb/s 200 000a 20 000–2 000 000 1–200 000 000
1 Gb/s 20 000 2 000–200 000 1–200 000 000
10 Gb/s 2 000 200–20 000 1–200 000 000
100 Gb/s 200 20–2 000 1–200 000 000
1 Tb/s 20 2–200 1–200 000 000
10 Tb/s 2 1–20 1–200 000 000
Abbildung 3.8: Tabelle aus der Norm: [6] Seite 154. Sie zeigt die empfohlenen Werte fur den
Parameter: Link Cost
4Quelle: [10] Seite 211
KAPITEL 3. GRUNDLAGEN 13
Aufbau und Pflege des STP Baums
Bridge 3
Bridge 14
Root Bridge
DesignatedBridge
DP
cost = 100
DP
DP
Bridge 7
DP
Equal cost paths to root;lowest numbered bridge ID isDesignated Bridge
Port 1Port 2Equal cost paths, same bridge ID toroot; lowest numbered port isDesignated Port
RP
Link A
Link B
Abbildung 3.9: Ein kleines Netzwerk mit verschiedenen Port Typen und einem Root-Switch.
Quelle [10] Seite 214
Als Erstes wird der Root-Switch festgelegt (gewahlt). Der Knoten mit der kleinsten SwitchID
wird nun der Root-Knoten. Bei diesem Schritt geht der Switch erst einmal davon aus, dass er
der Root-Knoten ist, und generiert eine entsprechende Bridge Protocol Data Unit (BPDU)-
Nachricht. Sollte die Root SwitchID der empfangenen BPDU-Nachricht kleiner sein, stellt sich
der Switch darauf ein. D.h. er stellt den Port in Richtung dieses Switches als Root-Port (RP)
ein. Alle anderen aktiven Ports sieht er nun als Designated-Port (DP) an und informiert uber
die DP seiner Nachbarn mithilfe der BPDU uber die Topologie-Anderung. Die BPDU-Nachricht
enthalt auch die Kosten zur Root-Switch. Der Root-Switch sendet eine BPDU aus mit den Pfad-
Kosten von Null. Jeder weitere Switch zahlt seine Kosten auf die Pfad-Kosten dazu. Falls dabei
zwei Ports an einem Switch die gleichen Pfad-Kosten aufweisen, kommt die PortID zum Zug.
Der Port, mit der kleinsten PortID gewinnt und wird zum Root-Port bzw. Designated Port.
DP sind die ausgewahlten Ports, die tiefer in den Netzbaum zeigen, wohingegen RP, Ports sind,
die auf den Root-Switch zeigen.
Nachdem nun der Baum aufgebaut ist, muss er auch gepflegt werden. Dazu sendet der Root-
14 3.5. NETZAUFBAU
Switch in regelmaßigen Abstanden eine Nachricht hinaus. Dies wird uber den Parameter Hel-
loTime gesteuert. Die HalloTime ist nach der Norm [6] Seite 153 als default-Wert 2 Sekunden
lang. Diese Nachricht wird an ihre DP abgesetzt. Anschließend verarbeiten die gegenuberlie-
genden Switches die Nachricht in ihrer STP-Einheit. Falls notig updaten sie ihre STP Daten
und senden uber ihren DP wieder eine Nachricht ab. Falls nun eine Verbindung ausfallt, bleibt
auch die HalloNachricht aus. Sollte die Nachricht drei mal nicht beim Empanger aufgetaucht
sein, geht er von einem Verlust des Root-Knotens bzw. dessen Verbindung aus. Dies fuhrt dazu,
dass der Switch sich selbst oder seinen Nachbar als Root-Switch ansieht und mit einer BPDU-
Nachricht wie beim Startup des Systems versucht, sich als neuen Root-Switch zu etablieren.
Falls ein Nachbar-Switch uber eine redundante Verbindung zum “alten” Root Switch besitzt,
wertet er diese Daten aus und schaltet eventuell deaktivierte alternative Ports wieder aktiv, da
uber ihn nun eine gunstigere Route zum “alten” Root Switch moglich ist und arbeitet normal
weiter. Sollte nun eine neue BPDU des Root Switches uber diese Verbindung auf den Switch
mit der fehlenden Verbindung eintreffen, passt dieser sich den neuen Gegebenheiten an. Der
Vorgang der Neukonfiguration in STP kann bis zu 30 Sekunden dauern.[18]
RSTP
Der Nachfolger RSTP von STP hat ein paar Anderungen am Protokoll vorgenommen. RSTP
hat Port-Rollen eingefuhrt, die den Status der einzelnen Ports darstellen. So gibt es Root-Port ,
Designated-Port , Alternate Port und einen Backup Port.
Root-Port : Wie Bei STP gibt es einen Root-Port . Der Root-Port ist der Port, der in Richtung
Root-Switch zeigt. Somit hat er auch die kleinsten Pfadkosten zum Root-Switch.
Alternate-Port : “Der Alternate-Port und der Backup-Port verhalten sich sehr ahnlich[...]”5
sie blockieren den Datenverkehr auf ihren Ports, aber verarbeiten weiterhin BDPU-Nachrichten
auf ihren Ports. Durch den Empfang von besseren BDPU’s, im Sinne von kleineren SwitchID
und/oder Pfadkosten eines anderen Netzwerke Segmentes, ist er zum Alternate-Port geworden.
Backup-Port : Wie bereits der Alternate-Port, blockiert auch der Backup-Port den Datenver-
kehr. Er empfangt und verarbeitet aber weiterhin BPDU-Nachrichten. Durch den Empfang von
besseren BDPU’s, im Sinne von kleinerer PortID, eines anderen Ports des gleichen Netzwerk-
segmentes ist er zum Backup-Port geworden.
Designated-Port : Er zeigt tiefer in den aktiven Netzwerk-Baum hinein. Uber den Designated-
Port werden die Pakete von dem Root-Port also tiefer in das Netz geleitet.
5[10] Seite 323
KAPITEL 3. GRUNDLAGEN 15
Root Bridge
Root Port
DesignatedPort
DesignatedPort
AlternatePort
DesignatedPort
Root Port
BackupPort
Abbildung 3.10: Ein kleines Netzwerk, in dem die verschiedenen Port Rollen der Switche
dargestellt sind. Quelle [10] Seite 233
Hirschmann “Media Redundancy Protocol”
Das Media Redundancy Protocol “basiert auf dem Hiper-Ring, einem von Hirschmann und
Siemens entwickelten und 1999 vorgestellten Protokoll zur Ringredundanz.” Quelle: [17].
Das Protokoll eignet sich, um eine Ringstruktur zu verwalten. Der entstehde Vorteil ist, dass
eine Umschaltung auf eine Redundanz-Verbindung mit einer sehr geringen Latenzzeit moglich
wird. Das Media Redundancy Protocol setzt dabei im Ring einen Redundanz-Manager ein.
Der Redundanz-Manager sendet periodisch Nachrichten aus hinsichtlich der Verfugbarkeit der
Verbindung. Die durch das Protokoll blockierte Verbindung, welche in Abbildung 3.11 gelb
dargestellt ist, lasst aber weiterhin Media Redundancy Protocol Test-Pakete durch. Um nun
einen Fehler zu erkennen, gibt es zwei Moglichkeiten:
• Die beteiligten Switche melden den Verlust der Verbindung.
• Nach einem Ausbleiben der Test-Pakete und das dazufuhrende Time-Out fur das Media
16 3.5. NETZAUFBAU
Redundancy Protocol, geht der Redundanz Manager von einem Verlust der Verbindung
aus.
Switch mitRedundanz Manager
Switch
Switch
Switch
Abbildung 3.11: Netzwerk, das in einem Ring aufgebaut ist. Ein Switch hat einen Redundanz-
Manager fur das Media-Redundancy-Protocol. Die Wolken zwischen den
Switches stellen weitere Netzwerk Kompnenten dar, wie z.B. ein Hub. Die
gelbe Netzwerkverbindung wurde von dem Protokoll deaktiviert.
Im ersten Fall gibt der beteiligte Switch eine Meldung an den Redundanz-Manager aus,
dass die Verbindung verloren gegangen ist. Die Abbildung 3.12 a) zeigt diesen Fall. Hier ist
ersichtlich, dass der Switch rechts unten den Verlust seines Links erkennt. Der Switch setzt
hierauf eine Nachricht ab. Der Redundanz-Manager gibt als Folge der Nachricht seinen blo-
ckierten Port wieder frei. Die Latenzzeiten sind durch diesen Mechanismus sehr gering. Diese
entsprechen typischerweise <40 ms.
Im zweiten Fall tritt der Verbindungsverlust in einem Subnetz auf. Dieses Subnetz, in Abbil-
dung 3.12 b) die rote Wolke, unterstutzt von sich aus allerdings nicht das Media Redundancy
Protocol (weil es z.B. Hubs einsetzt). Die Unterbrechung in diesem Fall wird mithilfe der Test-
Pakete erkannt. Das Protokoll sieht dazu vor, dass es alle 10 bzw. 20 ms (abhangig von der
Konfiguration) ein Test-Paket sendet. In diesem Worst-Case-Fall ist der redundante Pfad in
200 bzw. 500 ms wieder hergestellt. Nach: [9]. Switch in diesen Subnetzen, die kein Media Red-
undancy Protocol verarbeiten, bekommen die Veranderung der Netzwerktopologie nicht mit
KAPITEL 3. GRUNDLAGEN 17
und leiten unter umstanden Netzwerkpakete an die alten Ports hinaus. Vorhandene und so-
mit fehlerhafte Eintrage in der Tabelle fur die Paketweiterleitung sorgt fur das Problem der
fehlgeleiteten Pakete. Erst durch ein erneutes Lehren oder das Loschen der Eintrage bei einem
Time-out ist das Problem behoben.
Switch mitRedundanz Manager
Switch
Switch
Switch
Switch mitRedundanz Manager
Switch
Switch
Switch
Controle-Frame:Link-Down
a) Switch erkennt Link Ausfall. b) Im Subnetz aus Ausfall der Verbindung. (Rote Wolke)
Abbildung 3.12: In diesen Netzwerken ist der Redundanzfall eingetreten. Erkannt wird er auf
zwei verschiedene Weisen. Rot ist jeweils der Teil, der ausgefallen ist. Blau
ist die Leitung, die durch den Redundanz-Manager wieder aktiviert wurde,
um die fehlende Verbindung wieder herzustellen.
3.6 Multicast-Adressen dynamisch
Das Verteilen von Multicast-Adressen auf den zugehorigen Netzwerkknoten kann mit dem
MMRP oder uber das Internet Group Managment Protocol (IGMP)-Protokoll erfolgen. Die Ar-
beit beschaftigt sich im Kapitel 4 ausfuhrlich mit dem MMRP-Protokoll, d.h. es wird in diesem
Abschnitt das IGMP-Protokoll eingefuhrt. Im Unterschied zum Multiple Registration Proto-
col (MRP), das mit der Application MMRP auf dem MAC-Layer arbeitet, arbeitet IGMP auf
dem IP-Layer. IGMP-Snooping das in diesem Zusammenhang auch erwahnt wird, ermoglicht
es Switches, die meist nur auf dem MAC-Layer arbeiten, diese Pakete auf dem MAC-Layer zu
behandeln. Naheres zu IGMP-Snooping ist in diesem Abschnitt zu finden.
18 3.6. MULTICAST-ADRESSEN DYNAMISCH
3.6.1 IP-“Internet Group Managment Protocol”
Das IGMP-Protokoll basiert auf der Funktionalitat, dass einzelne Hosts im Netzwerk einer
Gruppe beitreten konnen. Diese Nachrichten, auch IGMP-Report genannt, wandern von einem
Host uber die Switche zum Router. Dabei wird als Zieladresse die Gruppenadresse der zu betre-
tenden Gruppe verwendet. Der Unterschied zwischen einem Switch und einem Router besteht in
der Tatsache, dass ein Router auf der Ebene der IP--Pakete arbeitet. Er betrachtet also die IP-
Adressen und versendet diese entsprechend seiner “Routing Table” (eine Tabelle in der steht,
uber welche lokale Adresse seiner Interfaces er seine Routing Ziele fur die Adresse finden kann).
Bei IGMP liegt die Intelligenz zur Uberwachung und Verteilung der Multicast-Streams auf dem
Router. Der Router wiederum sendet in periodischen Abstanden eine IGMP-Query-Nachricht
aus. Die Query-Nachricht sendet der Router an die von der IANA festgelegten IP-Adresse fur:
224.0.0.1 “All Systems on this Subnet”[3]. Hosts, die in der entsprechenden Multicast Grup-
pe sind, und in ihr bleiben mochten, antworten mit einer IGMP-Report-Nachricht. Ein IGMP-
Report hat die Zieladresse der beizutretenden Gruppe. Dies hat den Vorteil, dass ein Host im
gleichen Netzwerksegment diese Nachricht auch mitbekommt und sein eigenes Beitreten nicht
mehr bekannt geben muss. (Auch IGMP-Suppression genannt.) Bleibt fur das Netzwerkseg-
ment, fur das der Router zustandig ist, ein Report aus, so stellt dieser nach einem Time-out die
Ubertragung des Multicast Streams ein. Die Anfragen werden vom Router in einem Zeitbereich
von 60 bis 120 Sekunden versendet. Dieser hangt von der Konfiguration des Routers ab. Durch
das Fehlen der Nachricht zum Verlassen der Gruppe in IGMP v1 kann es vorkommen, dass
der Router noch relativ lange das Segment mit Multicast-Nachrichten versorgt, ohne dass ein
Teilnehmer existiert. In IGMP v2 ist dies mit einer Leave-Nachricht verbessert. Hosts konnen
auch asynchron zu der Query-Anfrage eine Respons-Nachricht senden und erreichen dadurch,
dass sie nicht bis zur nachsten Query-Anfrage des Routers warten mussen, um in eine Multicast
Gruppe aufgenommen zu werden.
Query- sowie Report-Nachrichten haben eine TTL von 1. Das zeigt an, dass die Nachricht
nicht weiter uber die Router laufen soll sondern dort der Endpunkt fur die Verarbeitung ist.
Oberhalb des Routers existierten noch Routing-Protokolle fur Multicast-Adressen. Diese sind
fur die Arbeit nicht weiter von Bedeutung.
KAPITEL 3. GRUNDLAGEN 19
IGMP - Snooping
Router
Switch1
Switch2 Switch3
geroutetesNetzwerk
Query
Report
Abbildung 3.13: Ein Netzwerk, das uber mehrere Switche und einen zentralen Router verfugt.
Dieser kann IP-Daten z.B. in das Internet routen
An der Abbildung 3.13 lassen sich mehrere Probleme erklaren. Switche arbeiten auf der
MAC-Adressen-Ebene, was hier bedeutet, dass fur einen normalen Switch eine Query- oder
Response-Nachricht sich nicht von einer anderen Gruppen-Anfrage unterscheidet. Der Switch
sendet somit all diese Nachrichten sowie die anfallenden Multicast-Streams an alle aktiven
Ports (er flutet das Netzwerk). Das nachste Problem ist, dass es ohne einen Router auch keine
zentrale Uberwachung fur den Stream gibt, die eine Moglichkeit hatte, den Multicast Stream in
das Netzwerk einzuschleusen oder eben abzuschalten. Um diese Probleme zu verbessern, gibt
es das IGMP-Snooping (Snooping engl. fur Schnuffeln).
IGMP-Snooping geniest in dem RFC4541-Standard einen informierenden Status.[16].
Eine Moglichkeit ist, dass der Switch mit seiner Central Processing Unit (CPU) alle Mul-
ticast-Nachrichten abhort. Der Router ist durch die Verwendung der Query-Adresse leicht zu
identifizieren. Query-Anfragen sind auf der IP-Adrese 224.0.0.1, welche sich auf die MAC-
Adresse 01:00:5E:00:00:01 ubertragen lasst. Somit kann der Switch den Port, auf der diese
MAC-Adresse eintrifft, als Query-Port bzw. Router-Port erkennen und abspeichern. Daruber
hinaus muss er diese Pakete an alle verbleibenden aktiven Ports weiterleiten.
Eine IGMP-Report-Nachricht hat die Zieladresse der beizutretenden Gruppe. Dies bedeutet,
dass auch die MAC-Adresse dieser IGMP-Report-Adresse diese Zieladresse aufweist. Der IGMP-
Snooping-Switch registriert die MAC-Adresse der IGMP-Report-Nachricht an dem Port, an
20 3.6. MULTICAST-ADRESSEN DYNAMISCH
dem sie aufgetreten ist. Zusatzlich leitet er diese Pakete auch an den Port weiter, an dem der
Router angeschlossen ist. Dies ist notig, um die Multicast-Adresse vom Empfanger bis zum
Router in den Switches erlernen zu konnen.
Durch dieses Verhalten lassen sich Multicast-Adressen auf den Switches erlernen und ei-
ne Verteilung der Streams ermoglichen. Allerdings konnen hierbei mindestens zwei Probleme
auftauchen. Hosts, die IGMP nicht verstehen, sind nicht in der Lage, Multicast-Streams zu
empfangen. Dies liegt an der Tatsache, dass der Switch sein eigentliches Verhalten, unbekann-
te MAC-Zieladressen an alle Ports zu schicken (somit auch seine Multicast-MAC-Adressen),
aufgibt. Daraus resultiert, dass Hosts, die nicht IGMP verwenden, keine Multicast-Nachrich-
ten mehr empfangen konnen. Das zweite Problem ist, dass der Switch mit seiner CPU alle
Multicast-Nachrichten uberwachen muss. Sendet ein Host einen Multicast-Stream mit hoher
Bandbereite aus, so muss die Management-CPU die Pakete uberwachen, was zu Lastproble-
men fuhren kann und somit der Switch seine eigentlichen Netzwerkaufgaben nicht mehr erfullen
kann.
Ergebnis: Stillstand des Netzwerksegments.
Eine weitere Moglichkeit ist, dass der Switch in der Hardware schon IGMP-Pakete erkennen
kann. Dadurch kann die Hardware der Switch-CPU mitteilen, dass ein IGMP-Paket eingetroffen
ist. Der Switch analysiert dabei die Pakete naher, um zu erkennen, ob es sich um ein IGMP-
Query- oder ein IGMP-Report-Paket handelt. Der Port, an dem die Query-Pakete eingetroffen
sind, wird auch hier abgespeichert und die Query-Nachricht an alle ubrigen Ports versendet.
Die CPU analysiert eine IGMP-Report-Nachricht und tragt in der Datenbank zur Weiterlei-
tung der Adressen (Forwarding Data Base (FDB)) die Adresse aus der Report-Nachricht zu
dem dazugehorigen Port ein. Anschließend ist die Report-Nachricht an den Query Port wei-
terzuleiten. Bei dieser Methode muss nicht das Grundverhalten aufgegeben werden, dass der
Switch unbekannte Zieladressen an alle Ports versendet.
KAPITEL 3. GRUNDLAGEN 21
Router
Switch1
Switch2 Switch3
Switch4 Switch5
geroutetesNetzwerk
Q
Q
Q
Q
Q
M1
M1
M1
Report{ }M1
Query{ }Q
Abbildung 3.14: Zeigt ein Netzwerk, in dem die Switche IGMP-Snooping machen. Die Swit-
che haben sich den Query-Port des Routers eingetragen (Q), sowie den Port,
von dem eine Report-Anfrage (M1) kam.
Ein Problem dabei ist allerdings, dass wie in Abbildung 3.14 der Baum vom Router zu sei-
ner linken Seite nicht mit Multicast-Adressen aufgebaut wird. Weiterhin ist es schlecht moglich,
andere Quellen im geswitchten Netzwerk als den Router fur Multicast-Streams zu verwenden.
Unter gewissen Umstanden wurden sie das Netzwerk mit Daten, wie beim Broadcast, fluten.
Um dieses Fluten einzuschranken, kann man bei manchen Switchen einstellen, dass nicht re-
gistrierte Multicast-Adressen nur an den Query-Port gesendet werden. So kann dann auch ein
Multicast-Stream-Sender auch im linken Baum der Abbildung vorhanden sein. Weiterhin muss
so ein Multicast-Stream aber auch bei registrierten Adressen an dem Switch in Richtung Que-
ry (und somit zum Router) wandern. Ist so eine Option nicht moglich, ware je nach Position
des Multicast-Senders nur der Teilbaum unterhalb des Routers und des Senders mit Multicast-
Paketen versorgt.
4 Multicast Verteilung nach IEEE 802.1
Die Institute of Electrical and Electronics Engineers (IEEE) hat in dem Jahr 1980 die Projekt-
gruppe 802 fur Lokale Netzwerke gegrundet und sie entwickelt heute Standards fur “[...]Local
Area Network [...] and Metropolitan Area Network[...]”1. Fur einen kurzen Uberblick hier einige
wichtige Untergruppen fur diese Arbeit; nach [10]2:
• IEEE 802.1 Uberblick, Architektur, Vernetzung und Management
• IEEE 802.2 Logical Link Control
• IEEE 802.3 CSMA/CD MAC und PHY (Ethernet)
Die IEEE 802.1 Gruppe entwickelte innerhalb des IEEE 802.1D [6] das Verfahren GMRP, um
Multicast-MAC-Adressen uber Switche zu verteilen. GMRP und das darunterliegende Generic
Attribute Registration Protocol (GARP) hat allerdings Schwierigkeiten, wenn sich die Netz-
werktopologie andert. Der Nachfolger Multiple MAC Registration Protocol (MMRP), aus [5],
fuhrt dazu in seinen Zustandsautomaten aus der MRP-Schicht zusatzliche Ereignisse ein, die
dazu bestimmt sind, Topologie-Anderungen schnell zu verarbeiten.
4.1 Funktionelles Kompendium fur MRP
In MRP und GARP uberschneiden sich einige Techniken; diese sind teilweise auch in IGMP
enthalten. In diesem Abschnitt wird ein Uberblick uber diese Funktionen dargestellt, um an-
schließend tiefer in die Technologie einzufuhren. Der nachste Abschnitt beschreibt naher die
Zustandsautomaten von MRP.
Um nicht mehr benotigte Gruppen auszutragen, ist in IGMPv1 keine spezielle Nachricht zum
Verlassen der Gruppe vorgesehen. Sie werden automatisch uber ein Time-out Verfahren ausge-
tragen. In MRP, das eine Moglichkeit besitzt, eine Gruppe durch eine Nachricht zu verlassen,
1Quelle:[1]2ab Seite 49
22
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 23
sieht allerdings auch ein Time-out-Verhalten vor. In MRP ist dieses Verfahren garbage collection
genannt[5]3. Dies ist notig, da MRP seine Nachrichten nicht zusatzlich, z.B. durch eine Antwort,
absichert. Um dennoch zuverlassig einer Gruppe beizutreten, ist in MRP vorgesehen, zwei Nach-
richten abzusenden. Beim Verlassen der Gruppe sieht das Protokoll im Gegensatz dazu nur eine
Nachricht vor. Dies ist nicht weiter problematisch, da fur den Fall des Ubertragungsfehlers noch
die garbage collection verwendet wird, um den Eintrag abzubauen. Dazu besitzt jeder Switch
einen Zustandsautomaten, der kontinuierlich die Neuregistrierung aller MAC-Adressen einfor-
dert. Sollte dies nicht in einer gewissen Zeit ablaufen, wird die entsprechende MAC-Adresse
ausgetragen und das Netzwerk mit einer Leave-Nachricht daruber informiert.
MMRP sieht weiterhin ein Source Pruning4 vor. Source Pruning sieht vor, dass die Quelle
des Multicast-Streams stumm geschaltet werden kann. Dies soll bewirken, dass das Netzwerk
nicht mit einem Multicast-Stream belastet wird, fur den es keine Nutzer gibt. Weiterhin verhin-
dert es, dass dieser Stream im Netzwerk nicht an alle Ports geflutet wird, da es fur die Switche
eine unbekannte Ziel-Multicast-Adresse darstellt. Allerdings muss beachtet werden, dass es le-
gacy5-Gerate gibt, die keine Registrierung der Multicast-Adressen vornehmen und somit an
diese Gerate jeder Multicast-Verkehr weitergeleitet werden muss. Diese Gerate kann der ange-
schlossene Switch teilweise erkennen, wenn sich z.B. ein Switch einbindet, der jedes Multicast-
Paket als Broadcast behandelt. Das kann aber meistens auch in die Switche eingetragen werden.
Daruber hinaus gibt es in MMRP eine Service-Nachricht, die diese Information im Netzwerk
propagiert.
Das Protokoll sieht auch vor, registrierte MAC-Adressen zu deregistrieren, wenn eine Ver-
bindung ausfallt, an der MAC-Adressen registriert sind. Da dies aber, z.B. bei legacy-Geraten
nicht funktioniert, werden diese Eintrage auch uber den garbage collection Prozess ausgetragen.
Weiterhin ist in MRP keine explizite Sicherung der ubertragenen Nachrichten vorgesehen.
So erwartet das Protokoll keine Antwort uber den Empfang der gesendeten Nachricht. Dies
Hat den Vorteil, dass das Protokoll prinzipiell schneller arbeiten kann. Allerdings auch den
Nachteil, dass, falls eine Nachricht verloren geht, dies nicht korrigiert wird. Um diesen Nachteil
zu verkleinern, aber dennoch den Vorteil beizubehalten, geht MRP davon aus, dass es sich in
einem Medium mit geringem Datenverlust befindet (dies trifft auf heutige LAN-Netzwerke zu)
und sendet, um sich abzusichern, zwei Nachrichten aus.
3Seite 344englisch fur: abschneiden der Quelle5englisch: Altlast
24 4.2. ZUSTANDSAUTOMATEN
4.2 Zustandsautomaten
MRP verfugt prinzipbedingt uber mehrere Kommunikationswege, die in unterschiedlichen Kon-
texten stehen. So ist ein Teil der Kommunikation extern uber die Ethernetschnitschtelle und
der andere Teil intern uber Schnittstellen des Programmcodes zu erledigen. Diese Unterschiede
zeichnen sich soweit aus, dass MRP dafur in seinen Zustandsautomaten unterschiedliche Events
verwendet. Weiterhin existieren die Zustandsautomaten immer fur einen registrierten Eintrag
und einem Netzwerk-Port am Switch. Ausnahme von dieser Regel stellt der Zustandsautomat
fur den garbage collector dar. Insgesamt bedeutet dies, wenn MRP z.B. zwei MAC-Adressen
gespeichert hat, es auch zwei Mal die entsprechenden Zustandsautomaten benotigt.
Die Zustandsautomaten, die fur jeden registrierten Eintrag einmal vorkommen, heißen Regis-
trar - und Applicant state machine. Daruber hinaus gibt es fur jeden Port eine PeriodicTrans-
mission state machine. Sie ist da, um an alle Applicant state machines des Netzwerk-Ports
periodische Signale abzuschicken, damit diese ihre Eintrage uber das Netzwerk neu registrie-
ren. Dabei stellt die PeriodicTransmission state machine mehr eine Konfigurationsoption fur
den Switch dar. Sie stellt also keine aktive Komponente des Protokolls dar, sondern ist eine
zuschaltbare Funktion fur den Netzwerkingenieur. Der Zustandsautomat fur den garbage col-
lector ist die LeaveAll state machine. Sie existiert fur jeden Switch nur einmal. Sie schickt ihre
LeaveAll Nachrichten an alle im Switch existierenden Registrar - und Applicant state machines
sowie uber die Netzwerk-Ports an die anderen angeschlossenen Switche. Die Zustandsautoma-
ten, die Nachrichten von der LeaveAll state machine bekommen, sollen diese gleichbehandeln,
unabhangig, ob sie durch eine interne oder eine externe Quelle versendet wurde.
Eine weitere Anderung zwischen MMRP und GMRP ist die Tatsche das MMRP nicht nur
Gruppen MAC-Adressen verwaltet, sondern auch in der Lage ist, die Unicast-MAC-Adressen
zu verwalten.
4.2.1 Registrar state machine
Die Registrar state machine speichert in seinen Zustanden ab, hinsichtlich der zu speichernden
MAC-Adresse fur den Port und der MAC-Adresse, fur den er zustandig ist. Dabei hat er die
Zustande:
IN der Registrar hat die MAC-Adresse abgespeichert.
LV von leave; der Registrar ist verlasst den abgespeicherten Zustand, wenn nicht innerhalb
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 25
von einer Time-Out-Zeit eine erneute Aufforderung zum Beitreten der Adresse (den ab-
gespeicherten Zustand) kommt.
MT von Empty; der Registrar hat keine Adresse abgespeichert; er ist leer.
STATE
IN LV MT
EV
EN
T
Begin! MT MT MT
rNew!New
IN
NewStop leavetimer
IN
New
IN
rJoinIn! ||rJoinMt!
IN Stop leavetimerIN
JoinIN
rLv! ||rLA! ||txLA! ||
Re-declare!
Start leavetimerLV
-x- -x-
Flush! MT LvMT MT
leavetimer! -x-LvMT MT
Abbildung 4.1: Zeigt den Zustandsautomaten des Registrars aus MRP. Quelle: [5] Seite 45
In der Abbildung 4.1 ist der Zustandsautomat aus der IEEE 802.1ak Norm ersichtlich[5].
Oben sind die Zustande und links die Ereignisse festzustellen, die einen Wechsel des jeweili-
gen Zustandes ermoglichen. Das “r” vor einem Ereignis deutet auf ein externes, empfangenes
Ereignis hin (aufgrund eines Netzwerkpakets erzeugtes Ereignis). Obwohl das Ereignis “rNew”
in MRP neu dazu gekommen ist, verwendet MMRP dieses Ereignis nicht. Die “-x-” weisen
daraufhin, dass dort kein Wechsel des Zustandes auftritt, bzw. dieses Ereignis nicht fur die-
sen Zustand eintritt. Die großgeschrieben Buchstaben geben den Wechsel in den Zustand an,
wohingegen Ereignisse, die dabei auftreten, auch Kleinbuchstaben enthalten (wie z.b. “Lv”).
Ereignisse, die auftreten, sind durch Ausrufezeichen gekennzeichnet. In der Initialisierungsphase
des Zustandsautomaten tritt das Ereignis Begin! auf. Damit wird erreicht, dass der Zustands-
automat zu Begin im Zustand MT sich befindet. Die Ereignisse Re-declare! und Flush! treten
26 4.2. ZUSTANDSAUTOMATEN
durch ein Redundanz-Protokoll auf und sind ebenfalls in MRP neu dazu gekommen. In der
Norm wird dabei immer auf das RSTP verwiesen. Re-declare! tritt dabei auf, wenn ein Port die
Rolle von einem Designated-Port zu einem Root-Port oder Alternate Port wechselt. (“Port role
changes from Designated to Root Port or Alternate Port”6) Das Ereignis Flush! tritt auf, wenn
die Port-Rolle von einem Root-Port oder Alternate Port zu einem Designated-Port wechselt.
(“Port role changes from Root Port or Alternate Port to Designated Port”6) Die Auswirkungen
auf die Funktionsweise der neuen Events wird im Kapitel 5 naher erortert.
Aktueller Auftretendes Beschreibung
Zustand Ereignis
MT Begin! Anfangzustand; das Ereignis Begin! sorgt dafur, dass der Zu-
standsautomat auch zuverlassig in den Zustand MT ist.
IN rJoinMt! Durch das Empfangen des externen rJoinMt! Ereignisses
wechselt der Zustandsautomat in den Zustand IN. Zeitgleich
sendet er eine Join Nachricht intern aus. (Diese wird von der
Switch-internen Applicant state machine verarbeitet.)
. . . . . . Andert eine Weile seinen Zustand nicht.
LV rLv! Empfangt die Nachricht zum Verlassen seines Zustands. Dies
kann auftreten, da der Kommunikationspartner die MAC-
Adresse deregistriert. Zeitgleich wird der leavetimer gestartet.
Der nach einer definierten Zeit das Signal leavetimer! auslost.
MT leavetimer! Nach Ablauf der Zeit, wir das Ereignis leavetimer! ausgelost.
Hierdurch wechselt der Zustandsautomat in den Zustand und
sendet die interne Nachricht Lv aus.
Tabelle 4.1: Beispielhaftes Durchlaufen des Zustandsautomaten fur das Registrieren und De-
registrieren eines MAC-Eintrages.
Fur ein besseres Verstandnis der Registrar state machines ist in Tabelle 4.1 ein Durchlauf
des Automatens dargestellt. Ersichtlich ist, dass die Registrar state machine nur Nachrichten
an interne Komponenten verschickt. Die Verarbeitung dieser Nachrichten erfolgt meist in der
Applicant state machine. Sie sendet auch Nachrichten auch uber das Netzwerk aus. Mehr dazu
6Quelle: [5] Seite:36
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 27
im nachsten Abschnitt.
Ubersicht uber die Ereignisse, die in der Registart State Machine auftreten konnen:
Begin! Event zum Starten und initialisieren des Zustandsautomanten.
rNew! Event zum schnellen Registrieren von Attributen. (Findet keine Verwendung
in MMRP.)
rJoinIn! Empfang einer JoinIn-Nachricht uber das Netzwerk.
rJoinMt! Empfang einer JoinMt-Nachricht uber das Netzwerk. (Wird von der Applicant
state machine generiert, und der Unterschied zur JoinIn-Nachricht wird dort
erklart.)
rLv! Empfang einer Leave-Nachricht uber das Netzwerk. Dient zur De-Registrierung.
rLA! Empfang einer LeaveAll -Nachricht uber das Netzwerk. Zur De-Registrierung
durch den garbage collector.
txLA! Event fur die Ubertragungsmoglickeit und einer LeaveAll -Nachricht trifft ein.
Hier keine großere Anderung als bei einem normalen rLA! -Event.
Re-declare! Event, das einen Port-Rollen-Wechsel anzeigt. (Von Designated-Port zu
Root-Port oder Alternate Port)
Flush! Event, das einen Port-Rollen-Wechsel anzeigt. (Von Root-Port oder
Alternate Port zu Designated-Port)
leavetimer! Der leavetimer ist abgelaufen und generiert dieses Event um anzuzeigen, dass
der Time-Out zum Re-Registrien vorbei ist.
4.2.2 Applicant state machine
Die Applicant state machine sendet Registrierungswunsche aus. Der Zustandsautomat kann
auch verkleinert werden, wenn nicht parallel eine Registrar state machines laufen muss, die sich
um die Registrierung der Adressen kummert. Dies kann z.B der Fall sein, wenn eine Komponente
fur einen Multicast-Stream nur einem Stream zuhoren will, aber eigenstandig keine Pakete
davon weiterleitet oder solche Pakete generiert. Die kleinere Untermenge der Applicant state
machine bezeichnet sich in der Norm als Applicant-Only-Teilnehmer.
Im Gegensatz zu der Registrar state machine veranlasst die Applicant state machine, Nach-
richten auf dem Netzwerk auszusenden. Events mit der Bezeichnung tx! oder dem beginn tx...!
deuten dabei an, dass es sich um eine transmit opportunity (engl. fur Ubertragungsmoglichkeit)
28 4.2. ZUSTANDSAUTOMATEN
handelt. Die transmit opportunity bietet die Moglichkeit, in verschiedene Umgebungen ande-
re Sendecharakteristiken zu bekommen. Dies umfasst das Potenzial, Nachrichten im geteilten
Medium, wie bei IGMP-Suppression, zu unterdrucken oder auch Nachrichten, die zeitgleich
gesendet werden sollen, zu einer Nachricht zusammenzufassen. Dazu fordert der Zustandsau-
tomat, wenn er in einen Zustand wechselt, der ein tx! -Event besitzt, eine transmit opportunity
an. Ist nicht bereits ein tx! -Event angefordert, so wird das Event generiert. Generieren bedeutet
hierbei, dass das Event in einer zufalligen Zeitspanne von 0 bis JoinTime erzeugt wird. (Der
Default-Wert von JoinTime ist 20 Centisekunden7 = 200 Millisekunden) Der Standard schreibt
dazu: “Whenever a state machine transitions to a state that requires transmission of a mes-
sage, a transmit opportunity is requested if one is not already pending. The message actually
transmitted (if any) is that appropriate to the state of the machine when the opportunity is
presented.”8
Abweichend von dieser Regel verhalt sich der Switch in einem Point-to-Point-Netzwerk. Der
Standard versteht unter einem Point-to-Point-Netzwerk ein geswitchtes Medium, also ein Me-
dium, dass nicht geteilt (shared) wird. (Switch-Netzwerk vs. Hub-Netzwerk) Aus dem Stan-
dard diesbezuglich: “[...] it is an Edge Port [...], or is attached to a point-to-point LAN, rat-
her than a shared medium [...]”9 Der Standard sieht in einem Point-to-Point Netzwerk nicht
die Notwendigkeit der direkten Vereinigung der Pakete durch die JointTime vor. Stattdessen
kann eine transmit opportunity direkt erfolgen. Dies wird allerdings soweit eingeschrankt, dass
es nicht zu einer Flut von Paketen kommt. Dazu durfen nur drei transmit opportunity alle
1,5 · JoinT ime auftreten.(Fur den Default-Wert bedeutet dies, dass nur drei transmit opportu-
nity alle 1,5·200ms = 300ms auftreten durfen.) Die entsprechende Stelle im Standard lautet: “If
operPointToPointMAC [...] is TRUE, a request for a transmit opportunity should result in such
an opportunity as soon as is practicable, given other system constraints, and shall occur within
the value specified for JoinTime subject to not more than three such transmission opportunities
occurring in any period of 1.5*JoinTime”.10 (operPointToPointMAC stellt die Variable dar,
die anzeigt, dass es sich um ein Point-to-Point Netzwerk handelt.)
Bist jetzt wurde angedeutet, dass das Aussenden von Nachrichten im geteilten Medium auch
unterdruckt werden kann. Falls z.B. eine Nachricht zum Bestatigen der Gruppe durch einen
anderen Teilnehmer im Netz fruher eintreffen sollte, als die eigene Nachricht gesendet wurde.
7Quelle: [5] Seite: 468Quelle: [5] Seite: 339Quelle: [6] Seite: 151
10Quelle: [5] Seite 47
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 29
Dies ist in MRP nicht so einfach wie in IGMP gelost. Zudem soll das Protokoll auch bei
einem geteilten Medium sicherstellen, dass es zwei Nachrichten aussendet. Hierbei konnte es
kontraproduktiv sein, eine Nachricht selbststandig zu unterdrucken. D.h. es wird bei MRP, falls
eine Nachricht zum Beitreten auftritt, nur in einem Fall die zweite Nachricht unterdruckt und
sofort zum Endzustand ubergegangen. Letztendlich basiert in MRP das Zusammenfassen auf
der Tatsache der Vereinigung der Nachrichten in einem Switch, der diese mehreren Nachrichten
empfangt und diese in seiner tx! -Event erst gebundelt in einem Paket ubertragt.
Die Applicant state machine sendet unterschiedliche Registrierungsanfragen an den gegenuber-
liegenden Switch aus. Diese hangen mit dem Zustand der Registrar state machine zusammen.
Ist der Registrar state machine im Zustand IN, veranlasst dieser die Applicant state machi-
ne eine JoinIN Nachricht auszusenden. Ist der Registrar state machine allerdings im Zustand
LV oder MT, sendet die Applicant state machine eine JoinMT -Nachricht aus. Dies ist bei der
Applicant state table durch ein “sJ” als Aktion im entsprechenden tx! -Event gekennzeichnet.
Der Zustandsautomat ist komplexer und hat hieraus folgend mehr Ubergange. Damit ist
ersichtlich, warum die Dokumentation des Standards auf Zustandstabellen ausgewichen ist,
als sie durch Zustandsdiagramme zu beschreiben. Weiterhin macht dies die Implementation
vergleichbarer. Dazu aber im Kapitel 5 mehr. Nachfolgend sind die Zustande beschrieben. Diese
Beschreibung stammt großtenteils aus dem Standard und ist ins Deutsche ubersetzt:11
VO Very anxious Observer - Zustand, in dem sich der Automat zu Begin befindet. Dieser
wird auch beim Verlassen der Registrierung wieder erreicht.
VP Very anxious Passive - Der Automat kommt in den Zustand, da er aufgefordert wurde,
die Adresse zu deklarieren. (Dies geschieht durch die Internen Join! -Nachricht, die z.B.
der Registrar aussendet.)
VN Very anxious New - Nicht weiter beschrieben; MMRP macht keinen Gebrauch des New! -
Kommandos, welcher zu diesem Zustand fuhrt.
AN Anxious New - siehe: VN
AA Anxious Active - Die Applikation befindet sich bei der Deklaration der Adresse. Sie hat
bereits eine Join-Nachricht versendet und sendet beim nachsten tx! -Event die zweite
Join-Nachricht aus.
QA Quiet Active - Zustand, in dem die Applikation die Anzahl der notigen Join-Nachrichten
abgesetzt hat. Dies ist der Zustand nach erfolgter Deklaration der Adresse.
LA Leaving Active - Die Applikation war bereits bei der Deklaration der Adresse und hat
11Quelle: [5] Seite 32
30 4.2. ZUSTANDSAUTOMATEN
eine interne Lv -Nachricht empfangen. Sie sendet beim auftretenden tx !-Event eine Lv -
Nachricht uber das Netzwerk aus.
AO Anxious Observer - Die Applikation deklariert selbst keine Adressen, hat aber eine
JoinIN -Nachricht (durch das Netzwerk) erhalten.
QO Quiet Observer - Die Applikation deklariert selbst keine Adressen, hat aber eine JoinIN -
Nachricht (durch das Netzwerk) erhalten.
AP Anxious Passive - Die Applikation hat eine JoinIN -Nachricht empfangen. Anschließend
wird sie aufgefordert, diese Adresse im Netzwerk zu deklarieren. (V O → AO → AP )
QP Quiet Passive - Die Applikation hat zwei JoinIN -Nachrichten empfangen, um in den QO-
Zustand zu kommen. Nun wird sie intern aufgefordert, selbst die Adresse zu deklarieren.
In der Zwischenzeit sind zwei JoinIN -Nachrichten bei ihr eingegangen, deswegen muss
sie selbst keine Nachricht versenden und kann im Zustand QP verbleiben.
LO Leaving Observer - Die Applikation deklariert diese Adresse nicht. Sie hat aber eine Lv -,
LeaveALL- oder Re-Declare-Nachricht empfangen. Beim nachsten tx! -Event versendet
sie eine Empty-Nachricht.
Bei Point-to-Point-Netzwerken werden die Zustande AO, QO, AP und QP nicht gebraucht.
Die Applicant state machine, welche in Abbildung 4.2 zu sehen ist, setzt Nachrichten im
tx! -Event uber Aktionen ab. Um die unterschiedlichen Typen dieser Aktionen verstehen zu
konnen, erfolgt hier eine kurze Beschreibung dieser Aktionen und ihrer Auswirkungen:12
s Sendet eine IN - oder Empty-Nachricht in Abhangigkeit der zugehorigen Registrar
state machine aus.
[s] Sendet eine IN - oder Empty-Nachricht in Abhangigkeit der zugehorigen Registrar state
machine aus. Diese Aktion kann ausgefuhrt werden, wenn sie zu Code-
Optimierungszwecke gebraucht wird.
sJ Sendet eine JoinIN- oder JoinMt-Nachricht aus in Abhangigkeit von der zugehorigen
Registrar state machine.
[sJ] Sendet eine JoinIN- oder JoinMt-Nachricht aus in Abhangigkeit von der zugehorigen
Registrar state machine. Diese Aktion kann ausgefuhrt werden, wenn sie zu Code-
Optimierungszwecke gebraucht wird.
sL Sendet eine Lv -Nachricht aus.
sN Wird nicht benotigt, da MMRP New! -Events nicht verwendet.
12Quelle: [5] Seite: 36
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 31
STATE
VO VP VN AN AA QA LA AO QO AP QP LO
EVENT
Begin! — VO VO VO VO VO VO VO VO VO VO VO
New! VN VN — — VN VN VN VN VN VN VN VN
Join! VP — — — — — AA AP QP — — VP
Lv! — VO LA LA LA LA — — — AO QO —
rNew! — — — — — — — — — — — —
rJoinIn! AO AP — — QA — — QO — QP — —
rIn! — — — — QA — — — — — — —
rJoinMt!||rMt! — — — — — AA — — AO — AP VO
rLv!||rLA!||Re-declare! LO1 — — VN VP VP — LO LO VP VP —
periodic! — — — — — AA — — — — AP —
tx! [s]—
sJAA
sNAN
sNQA
sJQA
[sJ]—
sLVO
[s]—
[s]—
sJQA
[s]—
sVO
txLA! [s]LO
sAA
sNAN
sNQA
sJQA
sJ—
[s]LO
[s]LO
[s]LO
sJQA
sJQA
[s]—
txLAF! LO VP VN VN VP VP LO LO LO VP VP
Abbildung 4.2: Zeigt den Zustandsautomaten des Applicant aus MRP. Quelle: [5] Seite 44
Der Applicant-Only-Automat unterscheidet sich von dem Zustandsautomaten aus Abbil-
dung 4.2 in der Weise, dass die gelb markierten Flachen entfallen. (Der Zustand LO und die
Events txLA! und txLAF! entfallen.) Die leicht gelb markierte Flache zeigt die Zutande, die
bei einem Point-to-Point-Netzwerk entfallen konnen. (AO,QO,AP und QP)
Bei diesem Zustandsautomaten sind die internen Nachrichten die ersten vier Events. Diese
Events werden meist von einem anderen Registrar im selben Switch abgeschickt. Nachrichten,
die mit einen “r” beginnen, weisen auf eine Nachricht hin, die uber das Netzwerk empfan-
gen wurden. (r = receive) Ausnahme stellt hier die rLA! -Nachricht dar. Nachrichten aus dem
LeaveAll -Zustandsautomaten sind als externe wie auch als interne Quelle gleichzubehandeln.
Deshalb gibt es fur sie nur das Event rLA!.
Die Applicant state machine aus MRP hat mehr neue Events bekommen als der vergleich-
bare Zustandsautomat aus GARP. Die meisten Events haben allerdings eine neue Bezeichnung
bekommen, verhalten sich aber ahnlich. Das Event Begin! ist z.B. der Ersatz aus GARP fur
32 4.2. ZUSTANDSAUTOMATEN
Initialize. Ahnliches gilt fur das transmit-opportunity-Event. Der direkte Vergleich aller Events
erscheint als nicht notig, denn die Events sind meist sehr ahnlich benannt, deswegen werden an
dieser Stelle die neu erstellten Events beschrieben. Der Standard schreibt dazu: “MMRP does
not make use of the “new” declaration capability.”13
Der IEEE-Standard sieht als Redundanzprotokoll RSTP vor. Dass die neu hinzugefugten
Events fur MRP auch bei anderen Redundanzprotokollen funktionieren, ist dabei naheliegend.
Sie mussen nur entsprechende Events an den MRP-Zustandsautomaten absetzten. Aus diesem
Grund ist hier beschrieben, wie diese Events auf RSTP reagieren.
Das Event Re-Declare! ist ein neu eingefugtes Event in den MRP-Zustandsautomaten. Es
tritt bei einem Port-Rollenwechsel von einem Designated-Port zu einem Root-Port oder einem
Alternate Port auf. Es dient, um seine Adressen in Richtung des Root-Switches wieder einzu-
tragen. (Erneut zu Deklarieren.) Auf der anderen Seite wird es, falls es keine Antwort erhalt,
auch die Registrierung austragen. Dies wurde beim Wechsel auf den Alternate Port passieren,
da der Alternate Port keine Daten weiterleitet. Insgesamt verhalt sich ein Re-Declare! -Event
ahnlich wie ein LeaveAll! -Event. Der Unterschied zwischen diesen beiden Ereignissen besteht
darin, dass das LeaveAll! -Event an jedem Port im Switch auftritt und uber das Netzwerk ubert-
ragen wird. Das Re-Declare! -Event tritt nur an dem Port auf, an dem sich ein Rollenwechsel
vollzogen hat. Als Gegenstuck dazu gibt es das Flush! -Event. Dieses greift allerdings nur in
der Registrar state machine ein und sorgt dort fur eine schnelle Austragung der registrierten
Adressen.
Um das Verhalten der App. beim Registrieren, Neudeklarieren und Deregistrieren einfacher
verstehen zu konnen, ist in Tabelle 4.2 der Verlauf beispielshaft dargestellt:
Applicant- Autretendes Beschreibung
Zustand Ereigniss
VO Begin! Der Anfangszustand; Um sicher in diesen Zustand zu kom-
men, tritt das Event Begin! zur Initialisierung auf.
13Quelle [5] Seite: 62
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 33
Applicant- Autretendes Beschreibung
Zustand Ereigniss
VP Join! Eine Anwendung mochte die Adresse im Netzwerk deklarie-
ren (um Daten empfangen zu konnen). Sie sendet ein Join! -
Event ab. (Alternativ kann auch Registrar im Switch den
Beitritt zu einer Gruppe propagieren und somit die anderen
Applicants veranlassen, diese in den weiteren Switchen zu
deklarieren.) Durch dieses Event geht der Automat in den
Zustand VP uber.
AA tx! Beim Eintreten in den Zustand VP wird eine transmit op-
portunity angefordert. Diese sorgt fur das Event tx!. Darauf-
hin sendet der Applicant eine Join-Nachricht ab. Wenn der
Registrar sich im Zustand IN befindet, wird eine JoinIN -
Nachricht abgesendet, anderenfalls eine JoinMt-Nachricht.
Sollte es sich um eine Application-Only-Automaten handeln,
sendet sie immer eine JoinIN-Nachricht ab, obwohl die Re-
gistrar state machine fehlt. Anschließend befindet sich der
Automat im Zustand AA.
QA tx! Durch das Betreten des Zustandes AA ist ebenfalls eine
transmit opportunity anzufordern. Durch das anschließen-
de tx! -Event wird ebenfalls eine Join-Nachricht zu den glei-
chen Bedingungen wie bei dem vorigen Schritt abgesendet.
Danach befindet sich der Automat im QA-Zustand. Diesen
verlasst er nicht ohne Anforderung von außen.
. . . . . . Bleibt im Zustand QA, bis ein neues Event eintrifft.
VP Re-Declare! Das Re-Declare-Event veranlasst den Automaten sich vom
Zustand QA zu losen und die Deklaration seiner Adresse er-
neut vorzunehmen. Aus diesem Grund wandert der Automat
in den Zustand VP. (Alternativ konnte an den Automaten
auch eine Leave-Nachricht (rLv! ) uber das Netzwerk oder
eine LeaveAll -Nachricht (rLA! ) eintreffen.)
34 4.2. ZUSTANDSAUTOMATEN
Applicant- Autretendes Beschreibung
Zustand Ereigniss
AA tx! Im Zustand VP hat der Automat eine transmit opportunity
angefordert. Dies fuhrt im Event tx! erneut zum Senden ei-
ner Join-Nachricht. Weiterhin wechselt der Automat durch
das tx! -Event in den Zustand AA.
QA tx! Erneutes Eintreffen in AA fuhrt zur Anforderung der trans-
mit opportunity. Durch das tx! -Event wird die zweite Join-
Nachricht abgesetzt und der Automat wandert in den Zu-
stand QA.
. . . . . . Bleibt im Zustand QA, bis ein neues Event eintrifft.
LA Lv! Eine interne Leave-Nachricht (Lv! ) veranlasst den Automat,
in den Zustand LA zu wechseln. Das Lv -Event ist durch
eine Application abgesendet worden, die die Adresse nicht
mehr benotigt. Eine weitere Moglichkeit besteht darin, dass
ein Registrar im Switch seine Adresse deregistriert und dies
durch das Lv -Event im Switch weiter propagiert.
VO tx! Beim Eintreten in den LA-Zustand ist eine transmit oppor-
tunity anzufordern. Dies fuhrt im anschließenden tx! -Event
dazu, dass der Automat eine Leave-Nachricht uber das Netz-
werk sendet und in den Zustand VO wechselt. Dies ist wie-
der der Anfangszustand.
Tabelle 4.2: Verlauf des Zustandsautomaten beim Registrieren bis zum Deregistrieren der
Adresse.
Abschließend zur Applicant state machine noch ein Uberblick der eingesetzten Events:
Begin! Event zur Initialisierung des Automaten.
Join! Interenes Event; Aufforderung zur Deklaration der Adresse.
Lv! Interenes Event; Aufforderung die Deklaration zu deregistrieren.
rJoinIn! Externes Event; Die Application state machine des verbundenen Switches
wurde aufgefordert, die Adresse zu deklarieren. Sie hat eine Join-Nachricht
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 35
abgesetzt, die sagt, dass ihr eigener Zustandsautomat sich im Zustand IN
befindet. (Oder, dass sie eine Applicant-Only state machine ist. )
rIn! Externes Event; der Automat hat den Zustand eines verbundenen Registrars
durch einen verbundenen Applicant state machine empfangen. Er befand sich im
Zustand IN.
rJoinMt! Externes Event; Join-Nachricht wurde empfangen mit der Information, dass sich
der entsprechende Registrar nicht im Zustand IN befindet.
rMt! Externes Event; Die Nachricht informiert daruber, dass sich der entsprechende
Regisrar nicht im Zustand IN befindet.
rLv! Externes Event; Zeigt an, dass die verbundene Applicant state machine die
Deklaration deregistriert.
rLA! Dieses Event kann sowohl von einer externen als auch von einer internen Quelle
stammen. Zeigt an, dass eine LeaveAll -Nachricht empfangen wurde. Eventuelle
Deklarationen mussen erneut deklariert werden, um einen Abbau der
Deklaration zu vermeiden.
Re-Declare! Internes Event; Erneutes Deklarieren durch Wechsel der Port-Rolle notig.
perodic! Internes periodisches Event, das durch die Periodic state machine erzeugt wird.
tx! Event, das anzeigt, dass nun eine Ubertragungsmoglichkeit existiert.
txLA! Event fur die Ubertragungsmoglichkeit mit zeitgleicher LeaveAll -Nachricht.
txLAF! Event fur die Ubertragungsmoglichkeit mit zeitgleicher LeaveAll -Nachricht und
fehlendem Platz fur weitere Adressen.
4.2.3 LeaveAll state machine
Die LeaveAll state machine dient der garbage collection. Dazu sendet sie ein periodisches Signal
an alle aktiven Zustandsautomaten des Switches und ins Netzwerk aus. Eine Applicant state
machine deklariert daraufhin ihre Adressen erneut. Wahrend dessen ist der Regsitrar auf der
anderen Seite dabei, seine eingetragenen Adressen zu deregistrieren. Da erneut die Deklaration
der Applicant state machine beim Regsitrar eintrifft, verlasst dieser den Abbau seiner Adres-
sen. (Er wechselt vom Zustand LV wieder in den Zustand IN.) Sollte aber z.B. der Abbau
der Adresse fehlgeschlagen sein, bekommt der Registrat nun keine erneute Aufforderung, die
Adresse beizubehalten. Dies sorgt dann dafur, dass er sie abbaut und somit unnotige Adressen
abgeraumt werden. (=garbage collcetion)
36 4.2. ZUSTANDSAUTOMATEN
STATE
Active Passive
EVENT
Begin! Start leavealltimerPassive
Start leavealltimerPassive
tx!sLA
Passive -x-
rLA! Start leavealltimerPassive
Start leavealltimerPassive
leavealltimer! Start leavealltimerActive
Start leavealltimerActive
Abbildung 4.3: Zeigt den LeaveAll Zustandsautomaten aus MRP. Quelle: [5] Seite 44
Die LeaveAll state machine hat zwei Zustande, um ihre Aufgabe zu erfullen. In Abbildung
4.3 ist die LeaveAll state machine aus dem Standard dargestellt. Bei der Initialisierung geht
der Automat in den Zustand Passiv und generiert ein zeitgesteuertes Event (leavealltimer! ).
Dieses Event tritt in einer zufalligen Zeitspanne innerhalb von LeaveAllTime bis zum 1,5-
fachen der LeaveAllTime auf. (LeaveAllTime ist dabei eine Variable, die als Grundwert bei 10
Sekunden liegt. Somit ist die Zeitpanne also zwischen 10 und 15 Sekunden.) Tritt das Event
leavealltimer! auf, so wechselt der Automat in den Zustand Active. Hier fordert er eine transmit
opportunity an. Im Zustand Active konnen zwei verschiedene Verhaltensweisen auftreten, je
nachdem, welches Event zuerst eintrifft:
1. Es tritt das tx! -Event auf und veranlasst den Automaten eine LeaveAll -Nachricht auszu-
senden. Anschließend wird das leavealltimer! -Event wieder nach der gleichen Regel erneut
generiert.
2. Es trifft von außen eine LeaveAll-Nachricht ein. Das leavealltimer! -Event wird wieder
nach der gleichen Regel erneut generiert und in den Zustand Passiv gewechselt.
Der Grund fur die zufallige Zeitspanne fur das leavealltimer! -Event liegt darin begrundet, dass
anderenfalls sich die LeaveAll state machine uber das Netzwerk hinweg zeitlich synchronisieren
wurde. Diese hatte bei großen Netzwerken den Nachteil, dass alle Switche im Netzwerk immer
zur selben Zeit den garbage collcetion Prozess ausfuhren und es somit zu Stoßzeiten fuhren
kann.
KAPITEL 4. MULTICAST VERTEILUNG NACH IEEE 802.1 37
4.2.4 PeriodicTransmission state machine
Die PeriodicTransmission state machine ist bei MRP neu hinzugekommen. Sie veranlasst die
Applicant state machine periodisch Nachrichten auszusenden, um diese erneut zu deklarieren.
Sie dient mehr dem Netzwerkmanagement und kann vom Administrator hinzugeschaltet wer-
den. Da sie allerdings keinen entscheidenen Einfluss fur die Reaktionszeit des MMRP-Protokolls
beim Umschalten eines Redundanzprotokolles wie RSTP hat, ist sie hier nur aus Grunden der
Vollstandigkeit erwahnt. Naheres zu ihr findet sich im Standard: [5].
5 Simulation mit OMNeT++
OMNeT++ ist eine Simulationssoftware, die zum Einsatz kam, um das Verstandnis fur das
Zusammenspiel zwischen den Zustandsautomaten zu vertiefen. Sie ist ein ereignisorientierter
Simulator.(Englisch: Discrete event simulation.) Dabei werden Ereignisse/Events zu diskreten
Zeitpunkten verarbeitet.
Prinzipiell lassen sich damit Straßenverkehr, Logikschaltungen aber auch Netzwerkprotokol-
le simulieren. All diese Systeme lassen sich durch diskrete Ereignisse beschreiben. So ist im
Straßenverkehr eine Ampel ein Knotenpunkt, der zeitlich ankommende Autos regelt. (Diskrete
Punkte sind hier die Autos und die Schaltzeit der Ampelphasen.) Dies kann durch zufallige
Ereignisse weiter gestreut werden. Beispielsweise, wenn ein Fußganger uber diese Ampel gehen
mochte. Fur Logikschaltungen kann man sich vorstellen, dass die verschiedenen Baugruppen
(Und-/Oder- bzw. Speicherglieder) erst ihren Zustand andern, wenn sich ihre Eingange durch
diskrete Ereignisse geandert haben.
In diesem Kapitel beschaftigt sich die Arbeit als erstes damit, wie diese Baugruppen in OM-
NeT++ fur das Netzwerkprotokoll MMRP erstellt werden konnen. Danach wird beschrieben,
wie die Simulation hierfur aufgebaut wurde und welche Resultate durch die Simulation ersicht-
lich wurden. Das Verhalten von MMRP steckt hauptsachlich in den Zustandsautomaten von
MRP. MMRP bescheibt naher den Rahmenaufbau und das besondere Verhalten, das MMRP
von anderen MRP-Applikationen unterscheidet. Damit ist als Beispiel gemeint, dass MMRP
beim Eintritt des Registrars in den Zustand IN auch eine MAC-Adresse in die FDB eintragen
muss. Die Simulation untersucht hauptsachlich das Verhalten von MMRP und im Besonde-
ren das Verhalten im Zusammenhang mit einem Redundanzprotokoll wie RSTP. Aus diesem
Grund ist die Simulation auf MRP vereinfacht worden. Besonderheiten wie das New! -Event,
das in MMRP nicht benotigt wird, sind dabei beachtet. Weiterhin wurde ein vereinfachtes
RSTP-Protokoll aufgebaut. Dies wird an geeigneter Stelle naher erklart.
38
KAPITEL 5. SIMULATION MIT OMNET++ 39
5.1 Modell Aufbau
Simulationsmodelle werden uber Module zusammengebaut. Die Module bestehen aus einer
Network Description (NED)-Datei und einem C++ Objekt. NED-Dateien beschreiben hier
den Aufbau des Modules. Sie dienen außerdem zum Aufbau von mehreren Modulen zu einem
Netzwerk. Es ist auch moglich, diese Netzwerke weiter zu verschachteln oder automatisch ge-
nerieren zu lassen. Die Eclipse-IDE, die zum Lieferumfang von OMNeT++ gehort, bietet zum
automatischen Generieren verschiedene Topologieformen an. Das C++ Objekt bildet die Logik
des Modules ab. In der Simulation sind die Aktionen einzelner Zustandsautomaten aus MRP
in diese Module gewandert. So existiert ein Modell fur den Registrar -, Applicant- und die Lea-
veAll -Automaten. Der Automat fur die PeriodicTransmission ist nicht aufgebaut, weil er fur
das Umschaltverhalten zu einem Redundanzprotokoll keinen wesentlichen Einfluss hat.
Die Module Registrar -, Applicant- und LeaveAll state machine sind mit einem zusatzlichen
Modul fur die Ports, welches die Ports des einzelnen Switches nach außen darstellt, mithilfe
einer weitern NED-Datei zu einem Switch-Modul definiert. Dieses Switch-Modul bildet dann
die Grundlage fur das Netzwerkmodell. An dieser modularen Verschachtelung lasst sich gut
erkennen, dass die NED-Dateien in OMNeT++ ubersichtliche Modelle ermoglichen. Die NED-
Dateien stellen so jeweils eine neue Abstraktionsebene dar.
5.2 Registrar Modul
Die Zustandsautomaten in MRP machen einen Unterschied zwischen den Nachrichten, die sie
von externen oder von internen Quellen bekommen haben. Um diesem Verhalten Rechnung zu
tragen und auch die Simulation ubersichtlicher zu halten, wurden fur die Pakete unterschiedliche
Kommunikationsschnittstellen geschaffen.
22 simple Reg i s t ra rS
23 {24 @display ( ” i=b l o c k / cogwhee l , red ” ) ;
25 gates :
26 // I n t e r e n Por t s
27 input MAPIn [ ] ;
28 output MAPOut [ ] ;
29 // Por t s nach außen
30 input PortIn ;
31 output PortOut ;
32 // C o n t r o l l e Nachr i ch t en −> Zustand an den A p p l i c a n t u b e r t r a g e n
33 output ControleOut ;
34 }
Listing 5.1: Registrar state machine Module der NED-Datei (RegistrarS.ned) zur
Beschreibung des Aufbaus.
40 5.2. REGISTRAR MODUL
Listing 5.1 zeigt dazu die NED-Beschreibung des Registar state machine Modules. In Zei-
le eins wird der Typ des Modules und der Name definiert. Im spater erklarten C++ Objekt
taucht diese Abhangigkeit auch auf. OMNeT++ genugen diese Abhangigkeiten, um das Si-
mulationsmodell zu generieren. Das SimpleModule ist die Grund-Klasse, aus dem das Model
aufgebaut wird. Nahere Beschreibung zu der Klasse erfolgt beim Definieren des C++ Objek-
tes. Der @display-Befehl dient der Darstellung des Registrar -Modules im Simulationsfenster.
Dabei dient das @-Zeichen am Anfang des Befehls zur Identifizierung als Eigenschaft (englisch:
property). Das Registrar -Modul wird so als Standardeinstellung mit einem Icon als Zahnrad
dargestellt.
Ab Zeile vier folgen die Definitionen der Verbindungen, ersichtlich am Schlusselwort gates.
Wie bei C++ mit public, protected und private sind die Unterteilungen der einzelnen
Module der NED-Datei durch ein Schlusselwort mit abschließenden Doppelpunkt unterteilt.
Die Verbindungen sind uber ihre Richtung und anschließendem Bezeichner definiert. Dazu
bietet OMNeT++ die Moglichkeiten an:
1. input; Die Nachricht geht in das Modul hinein.
2. output; Die Nachricht geht aus dem Modul heraus.
3. inout; Die Nachricht kann uber die Verbindung bidirektional versendet werden.
Die nur internen Kommunikationsverbindungen sind bei den MRP-Modulen durch die Vor-
silbe MAP (MRP Attribute Propagation) gekennzeichnet. Diese Vorsilbe ist bei der Entwicklung
der Module entstanden und zur anschaulichen Abgrenzung der Kommunikationsweise beibe-
halten, obwohl sie durch den Standard nicht auf die interne Kommunikation beschrankt ist.
Die Verbindung mit der Bezeichnung PortXXX dienen der Kommunikation nach außen. An sich
wird die Ausgabe-Richtung nach extern fur den Registar nicht benotigt. Die Verbindung mit
der Bezeichnung ControleOut dient zur Ubertragung des Zustandes des Registrars an den Ap-
plicant, der unterschiedliche Join-Nachrichten aufgrund des Zustandes des Registrars absenden
konnen muss.
KAPITEL 5. SIMULATION MIT OMNET++ 41
16 #include <omnetpp . h>
17 #include ” cons tTypes . h”
18
19 class Reg i s t ra rS : public cSimpleModule
20 {21 protected :
22 virtual void i n i t i a l i z e ( ) ;
23 virtual void handleMessage ( cMessage ∗msg) ;
24 private :
25 Reg i s t r a r : : S ta te s cur rS ta t e ;
26 cMessage ∗ leavetimerMsg ; // i s t zwar n i c h t n o t i g , aber e i n f a c h e r , um auf den s p e i c h e r z u z u g r e i f e n !
27 Events getEventType ( cMessage ∗msg) ;
28 } ;
Listing 5.2: Dekleration der Registrar-Klasse in der Datei RegistrarS.h
In Listing 5.2 ist die Klasse RegistrarS definiert. Sie stellt eine abgeleitete Klasse von
cSimpleModule dar. (OMNeT++ verwendet als prefix fur Klassen ein kleines “c”.) Die Klas-
se bietet Methoden, um Nachrichten zu senden, in die Warteschlange fur eigene Nachrichten
einzuplanen und um Nachrichten (oder auch in diesem Fall Events genannt) abzubrechen.
Diese Nachrichten (in OMNeT++ Messages genannt) werden von den einzelnen Modulen an
den OMNeT++ Simulationskernel geschickt. Dieser plant die Nachrichten ein und verteilt die
Nachrichten an die einzelnen Module.
Beim Starten der Simulation wird die Methode initialize() aufgerufen. Durch sie konnen
z.B. die Parameter, das Aussehen oder auch der Zustand des Zustandsautomaten zum Start-
zeitpunkt festgelegt werden. Die Verwendung eines Konstruktors oder eines Destruktors wird
aufgrund der Struktur der Klassen und des Simulationskernels von OMNeT++ nicht empfoh-
len. Um Elemente zu loschen oder auch Statistiken abspeichern zu lassen, gibt es die Methode
finish().
Die Methoden und Variablen unterhalb der Private-Anweisung sind fur dieses Modul defi-
niert. So speichert die Variable currState den augenblicklichen Zustand des Registrar -Zustands-
automaten ab. Die Methode getEventType() verarbeitet die einzelnen Nachrichten und teilt
sie den entsprechenden Events zu.
Der Aufbau der Zustandsautomaten sowie die Definitionen fur die auftretenden Events sind
in der Datei constTypes.h definiert. Aus Grunden der Vergleichbarkeit zum Standard [5] wurde
der Zustandsautomat uber eine Zustandstabelle erstellt. Nachfolgendes Listing 5.3 zeigt diese
Tabelle aus der Datei constTypes.h. Aus Kompatibilitatsgrunden fur das Betriebssystem Mi-
crosoft Windows muste der Zustand IN in die Schreibweise In geandert werden, auch wenn diese
Notation im Standard fur Events verwendet wird. Auf anderen Betriebssystemen, auf denen
der Simulator OMNeT++ lauft, ist dies nicht notig, denn IN wird durch die Datei windefs.h
definiert und diese ist Windows-spezifisch. Um eine einheitliche Notation zu erhalten, sind die
42 5.2. REGISTRAR MODUL
anderen Zustande ahnlich geschrieben.
80 namespace Reg i s t r a r
81 {82 enum State s
83 {84 In=0,
85 Lv ,
86 Mt
87 } ;88
89 const State s Table [ 6 ] [ 3 ]=
90 {91 /∗ In∗/ /∗LV∗/ /∗MT∗/
92 /∗Begin ! ∗/ {Mt, Mt, Mt} ,93 /∗rNew ! ∗/ { In , In , In } , // wird aber n i c h t
verwendet , v o l l s t a n i g k e i t s h a l b e r
94 /∗ r J o i n I n !
95 ∗ rJoinMt ! ∗/ { In , In , In } ,96 /∗ rLv ! rLA !
97 ∗ txLA !
98 ∗Re−Dec lare ! ∗/ {Lv , Lv , Mt} ,99 /∗Flush ! ∗/ {Mt, Mt, Mt} ,
100 /∗ l e a v t i m e r ! ∗/ { In , Mt, Mt}101
102 } ;103 }
Listing 5.3: Definition der Registrar state tabel in der Datei constTypes.h
In der Datei constTypes.h sind die Zustandsautomaten, Events usw. definiert. Die Zu-
standsautomaten sind hier untergebracht, um eine Zentrale und einfach zu bearbeitende Stelle
zu haben. OMNeT++ bietet von sich aus ein Macro und Methoden Set, um “Finite State
Machines”1 abzubilden. Allerdings kam diese Erkenntnis erst spat im Entwicklungsprozess der
Simulationsmodelle, so dass die Zustandsautomaten hier manuel aufgebaut wurden. Mehr zu
den State Machines im Handbuch zu OMNeT++: [12].
Die Tabelle des Zustandsautomaten ist, wie das Listing 5.3 zeigt, durch ein zweidimensio-
nales Array aufgebaut. Dieses Vorgehen bietet zwei entscheidende Vorteile:
1. Der Aufbau der Tabelle entspricht dem Aufbau des Zustandsautomaten aus Abbildung
4.1.
2. Ubergange in den neuen Zustand sind durch eine einfache Zeile programmiert.
Durch dieses Vorgehen lassen sich Ubertagungsfehler beim Programmieren der Zustandsauto-
maten minimieren. Denn ein Verglich mit den Zustandsautomaten aus dem Standard und den
programmierten Automaten ist aufgrund derselben Aufbauweise einfach zu vollziehen. Weiter-
hin lasst sich in den nur durch die Code Zeile:
1Quelle:[12] Seite 83
KAPITEL 5. SIMULATION MIT OMNET++ 43
currState=Registrar::Table[EventType][currState];
ein Ubergang zu dem neuen Zustand ermoglichen. Hier ist EventType eine beispielhafte Varia-
ble, die das aktuell auftretende Event widerspiegelt (wie z.B. rLA! ).
In der Datei RegistrarS.cc ist die Logik des Models hinterlegt. Sie beschreibt die Methoden
aus der RegistrarS.h Datei. Außerdem kummert sie sich um die Auswertung der Nachrich-
ten. Dazu kann sie unterscheiden, uber welche Verbindung die Nachricht eingetroffen ist. Dies
geschiet mit Hilfe der Namen der Gates aus dem Listing 5.1. Zunachst erfolgt allerdings eine
Beschreibung der Initialisierungs-Routine, um den Zustandsautomaten in seine Anfangsbedin-
gungen zu bringen.
18 Define Module ( Reg i s t ra rS ) ;
19
20 void Reg i s t ra rS : : i n i t i a l i z e ( )
21 {22 cur rSta t e=Reg i s t r a r : :Mt ;
23 ge tD i sp l aySt r ing ( ) . updateWith ( ” i=b l o c k / cogwhee l , red ” ) ;
24 WATCH( cur rSta t e ) ; //um in Tkenv s i c h t bar zu machen
25 leavetimerMsg = new cMessage ( ” l e a v e t i m e r ” ) ; // e r s t beim z e s t o r e n der c l a s s e l o s c h e n !−> e i n f a c h e r
26 }
Listing 5.4: Methode zum Initialisieren des Registrar-Zustandsautomaten. Weiterhin
zusatzliche Definitionen fur OMNeT++
Zeile 18 aus dem Listing 5.4 ist ein Makro, um das Modul RegistrarS fur OMNeT++ zu
registrieren. Die anschließenden Zeilen dienen der Definition der Methode initialize(). In ihr
wird in der Zeile 22 der Anfangszustand der Variable currState zugewiesen. Die zwei weiteren
Befehle dienen der Darstellung des Registrars im Simulationsfenster. Fur eine bessere Darstel-
lung der Zustande bei der Simulation, sind die Zustande in verschiedene Farben eingeteilt. So
ist der Anfangszustand MT rot, der Zustand IN grun und der Zustand LV gelb. Bei der Initia-
lisierung ist der Anfangszustand MT und somit wird auch die Farbe des Registrar-Modules auf
rot gesetzt. Mithilfe des WATCH()-Makros lasst sich der Inhalt der Variable currState in dem
Simulationsfenster darstellen. Zum Abschluss der Methode wird noch eine Nachricht kreiert.
Die Nachricht dient, in dem Zustandsautomaten ein Event zeitgesteuert zu erzeugen.
Das Listing zur Methode RegistrarS::handleMessage(...) ist nur auszugsweise darge-
stellt, denn sie umfasst um die 100 Zeilen und wurde viel Platz beanspruchen.
28 void Reg i s t ra rS : : handleMessage ( cMessage ∗msg)
29 {30 EV<<”RR: Massage hand l e : ”<<endl ;
31 Reg i s t r a r : : S ta te s tmpState = cur rSta t e ;
32 switch ( getEventType (msg) )
33 {
44 5.2. REGISTRAR MODUL
58 case rLv :
59 case rLA :
60 case txLA :
61 case ReDeclare :
62 i f ( cur rS ta t e==Reg i s t r a r : : In )
63 {64 cancelEvent ( leavetimerMsg ) ; // s i c h e r i s t s i c h e r . . .
65 scheduleAt ( simTime ( )+LeaveTime , leavetimerMsg ) ;
66 }67 cur rS ta t e=Reg i s t r a r : : Table [ 3 ] [ cu r rS ta t e ] ;
68 break ;
Listing 5.5: Auszug aus der RegistrarS::handleMessage()-Methode.
Der Ubergabeparameter aus dem Listing 5.5 ist die Nachricht, die durch den Simulations-
kernel an die Methode ubergeben wird. In OMNeT++ ist der Makrobefel EV eingebaut, um
eine Nachricht als Stream zu den Log-Nachrichten im Simulationsfenster auszugeben. Um eine
Trennung zwischen der Auswertung der Nachricht und der Verarbeitung der Events durch ein
switch...case... block zu erledigen, ist die Auswertung der Nachricht in die private Funktion
getEventType(...) der Klasse RegistrarS gewandert.
Events, die in dem Zustandsautomaten zusammengefasst sind, sind auch im case-Block zu-
sammengefasst, wie es im Listing ab Zeile 58 ersichtlich ist. Ist der Zustandsautomat im Zustand
IN (Zeile 62 uberpruft dies) und tritt z.B. das Event rLv auf, soll der Zustandsautomat in den
Zustand LV wechseln. Dies ist durch die Zeile 63 bewerkstelligt, welche zeitgleich fur die ande-
ren Zeilen keine Anderung des Zustandes herbeifuhrt. Allerdings ist die Uberprufung auf den
Zustand IN notig, damit das Ereignis Start leavtimer generiert werden kann. Dies geschieht in
OMNeT++ mit den Zeilen 64 und 65. OMNeT++ organisiert die Events intern durch War-
teschlangen. Der Befehl scheduleAt(...) sorgt dafur, dass das Event an die richtige Stelle
der Warteschlange eingeplant und die Nachricht an das eigene Registrar-Modul geschickt wird.
Mithilfe der Funktion simTime(), welche die aktuelle Simulationszeit zuruckliefert, tritt das
Ereignis also um LeaveTime versetzt in der Zukunft auf. LeaveTime ist dabei in der Datei
constTypes.h definiert und stellt eine Zeit von 600ms dar. Der Standard sieht hier eine varia-
ble Zeitspanne von 600ms bis 1s vor. Die Simulation soll mogliche Umschaltzeiten bei einem
Redundanzprotokoll untersuchen. Aus diesem Grund ist der kleinstmogliche Default-Wert an-
genommen, um ein mogliches Fehlverhalten mit diesen niedrigen Zeitgroßen untersuchen zu
konnen. cancelEvent loscht mogliche bereits bestehende Timer-Events.
Durch das temporare Abspeichern des Zustandes des Automaten in Zeile 31, ist es moglich,
spater eine Anderung des Automaten zu tracken.
KAPITEL 5. SIMULATION MIT OMNET++ 45
113 i f ( cu r rS ta t e !=tmpState )
114 {115 cMessage ∗StateControleMsg ;
116 switch ( cu r rS ta t e )
117 {118 case Reg i s t r a r : : In :
119 StateControleMsg = new cMessage ( ”C IN” ) ; // b e s s e r erkennbar mit C das es e i n e
c o n t r o l e n a c h r i c h t i s t !
120 send ( StateControleMsg , ” Contro leOut ” ) ;
121 ge tD i sp l aySt r ing ( ) . updateWith ( ” i=b l o c k / cogwhee l , green ” ) ;
122 break ;
Listing 5.6: Auszug aus RegistrarS.cc, um die Anderungen des Zustandes versenden zu
konnen.
Listing 5.6 zeigt dazu, wie dies im Modul behandelt wird. Das Mitteilen der Anderung an
das zugehorige Applicant-Modul ist notig, denn dieses Modul muss abhangig von den Zustanden
des Registrars unterschiedliche Nachrichten versenden. Zeitgleich kann an diesem Listing auch
aufgezeigt werden, wie eine Nachricht in OMNeT++ uber die verschiedenen Gates versendet
wird.
Die Zeile 119 erzeugt ein neues Objekt vom Type cMassage. Durch das Ubergeben des Strings
"C_IN" bekommt das Objekt den entsprechenden Namen zugewiesen, an dem die Eigenschaft
des Registrars zu erkennen ist. Anschließend sendet der Befehl send(...) die Kontrollnach-
richt ab. Der zweite Parameter des send(...)-Befehles gibt dabei das Gate an, auf dem der
Simulator die Nachricht verteilt. Dies ist wichtig, denn spater wird uber weitere NED-Dateien
die Verbindungen zwischen den Modulen definiert und hier dienen die Namen der Gates als
Endpunkte der Verbindungen zwischen den Modulen. Weiterhin ist es durch das Tracken der
Anderung des Zustandes moglich, die Farbdarstellung des Registrar-Modules anzupassen.
137 Events Reg i s t ra rS : : getEventType ( cMessage ∗msg)
138 {139 Events tmpEvent=MAX e;
140 EV<<” in R e g i s t r a r g e t E v e n t . . : ”<<endl ;
141 i f (msg−>i s S e l fMes sage ( ) )
142 {143 EV<<”RR: s c h e d u l e Mesage ”<<msg−>getName ( )<<”\n” ;
144 i f ( strcmp (msg−>getName ( ) , ” l e a v e t i m e r ” )==0){tmpEvent=leave t imer ;}145 else i f ( strcmp (msg−>getName ( ) , ”txLA” )==0){tmpEvent=txLA ;}146 } else i f ( strcmp (msg−>getArr iva lGate ( )−>getName ( ) , ”MAPIn” )==0) // I n t r e n e n a c h r i c h t
147 {148 EV<<”RR: Map i n t e r n e Nachrich : ”<<msg−>getName ( )<<”\n” ;
149 i f ( strcmp (msg−>getName ( ) , ” Flush ” )==0){tmpEvent=Flush ;}150 else i f ( strcmp (msg−>getName ( ) , ” ReDeclare ” )==0){tmpEvent=ReDeclare ;}151 else i f ( strcmp (msg−>getName ( ) , ” C l e a v e ” )==0){tmpEvent=schne l lLeave ;}152 else i f ( strcmp (msg−>getName ( ) , ” L e a v e A l l ” )==0){tmpEvent=rLA ;}153 delete msg ; // s o l l t e h i e r auch zu l o s c h e n s e i n . .
154 } else // n a c h r i c h t e n von ausen
155 {156 i f ( strcmp (msg−>getName ( ) , ”New” )==0){tmpEvent=rNew ;} // der v o l l s t a n d i g k e i t h a l b e r , mmrp b a r u c h t
das n i c h t !
157 else i f ( strcmp (msg−>getName ( ) , ” Jo inIn ” )==0){tmpEvent=rJo in In ;}158 else i f ( strcmp (msg−>getName ( ) , ” JoinMt ” )==0){tmpEvent=rJoinMt ;}159 else i f ( strcmp (msg−>getName ( ) , ”Lv” )==0) {tmpEvent=rLv ;}
46 5.3. APPLICANT MODUL
160 else i f ( strcmp (msg−>getName ( ) , ” L e a v e A l l ” )==0){tmpEvent=rLA ;}161 delete msg ; // b e s s e r h i e r d i e e x t e r n e n a c h r i c h t l o s c h e n . . . wird j a nichtmher g e b r a u c h t !
162 }163 EV<<” Event : ”<<tmpEvent<<”\n” ;
164 return tmpEvent ;
165 }
Listing 5.7: Methode, die die Nachrichten (*msg) in Events umwandelt aus RegistrarS.cc
Abschließend zum Registrar-Modul ist die Methode zur Umwandlung der Nachrichten in
Events betrachtet. In Listing 5.7 ist sie abgebildet. Die Methode handleMessage(...) ruft
sie auf und ubergibt als Parameter die Nachricht. Das Objekt der Nachricht, welches von der
Klasse cMessage abgeleitet ist, enthalt mehrere Informationen, die auszuwerten sind. So “weiß”
das Objekt, ob es nicht uber ein Gate, sondern durch ein scheduleAt(...) an sich selber
gesendet wurde. Dies ist wichtig, da hierdurch z.B. das leavetimer -Event generiert wird. Die
Uberprufung darauf erfolgt in Zeile 141 des Listings. Falls das nicht zutrifft, ist zu uberprufen,
durch welches Gate die Nachricht ankam. (Zeile: 146). Durch das Senden einer Nachricht an
sich selbst, hat diese kein Gate und liefert auf die Abfrage nach einem Gate einen Nullpointer
zuruck. Aus diesem Grund ist es wichtig, die Reihenfolge einzuhalten.
Eine Besonderheit, die noch nicht beschrieben ist, stellt das Event schnellLeave aus Zeile
151 dar. Der Standard sieht vor, dass ein Port, an dem ein Zustand gespeichert hat und der
die aktive Topologie verlasst, diesen auch deregistrieren soll. “If a Port is removed from the
set, and that Port has registered an attribute that another Port has also registered, then a
MAD Leave.request is propagated to the MAD instance for that other Port.”2
Die eigentlichen Vergleiche, bezuglich des Types des Gates und des Types der Nachricht, sind
an sich einfache Stringvergleiche der String-Namen aus den entsprechenden Objekt-Klassen und
bedurfen keiner großeren Erklarung.
5.3 Applicant Modul
Das Applicant-Modul ist prinzipiell ahnlich dem Registrar -Modul aufgebaut. Um teilweise Wie-
derholungen zu vermeiden, sind nur Anderungen und Erganzungen in diesem Abschnitt auf-
gefuhrt. Damit der Zusammenhang ersichtlich bleibt, sind teilweise ahnliche Listings, nur fur
den Applicant, aufgefuhrt.
2Quelle: [5] Seite: 28
KAPITEL 5. SIMULATION MIT OMNET++ 47
23 class ApplicantS : public cSimpleModule
24 {25
26 protected :
27 virtual void i n i t i a l i z e ( ) ;
28 virtual void handleMessage ( cMessage ∗msg) ;
29
30 private :
31 cMessage ∗txMsg ; // h i e r brauch i c h s i e aber ; −> da s i e von mehere s t e l l e n auch abgebrochen werden kann
32
33 Appl icant : : S ta te s cur rS ta t e ;
34 Reg i s t r a r : : S ta te s currRegState ;
35
36 Events getEventType ( cMessage ∗msg) ;
37 void ReScheduleTxEvent (void ) ;
38
39 } ;
Listing 5.8: Definition der Applicant-Klasse aus ApplicantS.h
In Zeile 34 des Listings 5.8 ist ersichtlich, dass die Klasse eine Variable besitzt, die den Zu-
stand des zugehorigen Registrats abspeichert. Diese erfolgt, wie bereit beim Registrar erwahnt,
uber die Control -Nachrichten des Registrars. Das Modul muss den Zustand des Registrars
speichern, denn es sendet unterschiedliche Join-Nachrichten aus. Weiterhin ist eine Methode
hinzugekommen. Die Methode ReScheduleTxEvent(...) kreiert beim Eintritt in den entspre-
chenden Zustand ein tx! -Event. Spater mehr dazu.
35 void ApplicantS : : handleMessage ( cMessage ∗msg)
36 {37 Appl icant : : S ta te s tmpState=cur rSta t e ; //um Anderung erkennen zu konnen . .
38
39 switch ( getEventType (msg) )
40 {
42 case Join :
43 cur rS ta t e=Appl icant : : Table [ 2 ] [ cu r rS ta t e ] ;
44 ReScheduleTxEvent ( ) ;
45 break ;
Listing 5.9: Auszug aus der Implementation von der Applicant-Klasse in der Datei:
ApplicantS.cc.
Das Listing 5.9 zeigt die Verarbeitung der Nachrichten. Das Augenmerk hier liegt jedoch
auf der ReScheduleTxEvent(...)-Methode, denn diese ist in dem Applicant-Modul neu hin-
zugekommen. Zuerst wechselt der Zustandsautomat auf den neuen und anschließend wird die
ReScheduleTxEvent(...)-Methode, aufgerufen um eventuell notige tx! -Events anzufordern.
214 void ApplicantS : : ReScheduleTxEvent (void )
215 {216 switch ( cur rS ta t e )
217 {218 case Applicant : : Vo :
219 cancelEvent ( txMsg ) ;
220 break ;
48 5.4. LEAVEALL MODUL
221 case Applicant : : Vp :
222 cancelEvent ( txMsg ) ;
223 txMsg−>setName ( ” t x ” ) ;
224 scheduleAt ( simTime ( )+dblrand ( ) ∗JoinTime , txMsg ) ;
225 break ;
Listing 5.10: Auszug aus der Implementation von der Applicant-Klasse. Sie zeigt dabei die
Methode ReScheduleTxEvent(...) in der Datei: ApplicantS.cc.
Wie aus dem Listing 5.10 in der Zeile 219 zu erkennen ist, werden beim Eintreten in
Zustande, in denen kein tx! -Event auftreten und eventuell vorhanden sein konnen, abgebrochen.
Dies kann vorkommen, wenn der Zustandsautomat ein tx! -Event in einem vorigen Zustand
angefordert hat, aber durch ein anderes Event in den neuen Zustand wandert. Die Methode
dblrand(...) innerhalb des Befehls scheduleAt(...) in Zeile 224 liefert eine Gleitkomma-
Zufallszahl von 0 bis 1 zuruck. Dies ist notig, wie bereits ausfuhrlich beschrieben, um die
JoinTime in der vorgeschriebenen Zeitspanne zu bekommen. Diese liegt standardmaßig im
Bereich von 0 bis 200 ms.
5.4 LeaveAll Modul
Das LeaveAll-Modul ist prinzipiell ahnlich wie die beiden anderen Module aufgebaut. Allerdings
gibt es eine Besonderheit: Die LeaveAll-Nachrichten unterscheiden sich beim Empfang nicht
von internen oder externen Nachrichten. Aus diesem Grund macht das LeaveAll-Modul keinen
Unterschied fur die Gates zum Versenden von internen oder externen Nachrichten.
21 simple LeaveAllS
22 {23 parameters :
24 bool enable = de f au l t ( t rue ) ;
25 @display ( ” i=b l o c k / b r o a d c a s t ” ) ;
26 gates :
27 input in [ ] ;
28 output out [ ] ;
29 input Controle [ ] ;
30 }
Listing 5.11: Auszug aus dem Aufbau der LeaveAllS.ned Datei.
Hieran lasst sich fur OMNeT++ noch eine weitere Eigenschaft fur das Versenden von Nach-
richten erklaren. Wie teilweise bei den bereits vorgestellten Modulen hat hier das Input und
das Output Gate eckige Klammern am Ende “[]”. Diese zeigen an, dass dieses Gate mehre-
re Verbindungen besitzen kann. In OMNeT++ sind diese Gates auch als Vektoren bezeichnet.
Beim Empfangen stellt dies keine Besonderheit dar. Beim Versenden einer Nachricht muss aller-
dings angegeben werden, uber welchen Gate-Vektor versendet werden soll. So ist es vorstellbar,
KAPITEL 5. SIMULATION MIT OMNET++ 49
dass unterschiedliche Nachrichten bezogen auf den Endpunkt der Verbindung gesendet werden
konnen. Diese Simulation ist aber darauf ausgelegt, dass dafur spezielle Gates existieren. Hier
muss also die Nachricht nur dupliziert werden. OMNeT++ macht dies nicht selbststandig.
32 void LeaveAllS : : handleMessage ( cMessage ∗msg)
33 {34
35 switch ( getEventType (msg) )
36 {37 case tx :
38 i f ( cu r rS ta t e==LeaveAll : : Activ )
39 {40 cur rS ta t e=LeaveAll : : Table [ 1 ] [ cu r rS ta t e ] ;
41 cMessage ∗LeaveAllMsg=new cMessage ( ” L e a v e A l l ” ) ;
42 for ( int i =0; i<ga t eS i z e ( ” out ” ) ; i++)
43 {44 send ( LeaveAllMsg−>dup ( ) , ” out ” , i ) ;
45 }46 delete LeaveAllMsg ;
Listing 5.12: Auszug aus dem Programmcode zum LeaveAll-Modul, die das Versenden an
mehrere Gate-Vektoren zeigt. Aus der Datei: LeaveAllS.cc
Das Listing 5.12 zeigt die bereits mehrfach behandelte handleMessage()-Methode, hier al-
lerdings fur das LeaveAll -Module. In Zeile 42 beginnt die for-Schleife fur das mehrfache Versen-
den von Nachrichten uber einen Gate-Vektor. Mithilfe der OMNeT++ mitgelieferten Methode
gateSize() lasst sich die Große des Gate-Vektors bestimmen. Als Ubergabeparameter dient
hier der String, der das Gate identifiziert. Die Methode liefert anschließend die Große des Gate-
Vektors zuruck. Somit kann der Integer “i” bis zur maximalen Anzahl des Gate-Vektors erhoht
werden und die Schleife hierbei mehrfach durchlaufen wenden. Das Versenden der Nachricht
findet in Zeile 44 statt. Hierbei ist zu beachten, dass die Methode send() um den Parameter
der Position im Gate-Verktor erweitert ist, um anzugeben, uber welches exakte Gate die Nach-
richt versendet werden soll. Da dies innerhalb der Schleife geschieht und hierbei immer nur ein
Duplikat der Nachricht zu versenden ist, ist der Parameter der Integer, der erhoht wird. In der
send()-Methode wird auch die Nachricht dupliziert; diese geschieht mit dem Befehl dup().
50 5.5. PORT MODULE
32 void LeaveAllS : : i n i t i a l i z e ( )
33 {34 cur rS ta te=LeaveAll : : Pass iv ;
35 WATCH( cur rSta t e ) ; // V a r i a b l e in Tkenv s i c h t b a r . .
36 // i n t i = c u r r S t a t e ;
37 i f ( par ( ” e n a b l e ” ) )
38 {39 l eava l l t imerMsg = new cMessage ( ” l e a v e a l l t i m e r ” ) ;
40 scheduleAt ( simTime ( )+LeaveAllTime+dblrand ( ) ∗1.5∗ LeaveAllTime , l eava l l t imerMsg ) ;
41 }42 }
Listing 5.13: Auszug aus dem Programmcode zum LeaveAll-Modul, welches die Initialisierung
des Modules zeigt. Aus der Datei: LeaveAllS.cc
Bei der Initialisierung des Modules ist noch eine kleine Besonderheit vorhanden. Durch einen
Simulationsparameter lasst sich das Modul auch abschalten. Dies ist eingebaut, um ein mogli-
ches Fehlverhalten und auch das genaue Verhalten der neu hinzugekommenen Events in MMRP
zu prufen. Dazu ist in Zeile 37 des Listings 5.13 mithilfe des Befehls par() aus OMNeT++ ge-
pruft, ob der Parameter auf true gesetzt ist. Die Default-Einstellung ist dabei in der NED-Datei
im Listing 5.11, Zeile 24 auf true festgelegt.
Die Verarbeitung der Nachrichten folgt im LeaveAll -Module den gleichen Schritten wie bei
den anderen Modulen. Der Empfang der Nachricht ist durch die handleMessage()-Methode ge-
regelt. Diese leitet die Nachricht an die eigene Methode getEventType() weiter, welche, wie bei
den anderen Modul-Klassen auch, aus dem Names-String des cMassage-Objekts den Eventtyp
der Nachricht ableitet und zuruck gibt. Das Verarbeiten des Events ist durch eine switch..case
Anweisung geregelt. Das Wechseln der Zustandsautomaten ist hier, wie bei den Anderen Modu-
len auch, uber die eine Zeile geregelt: currState=LeaveAll::Table[X][currState];. (Wobei
hier das “X” als Platzhalter fur den Eventtyp steht.)
5.5 Port Module
Als weiteres Modul gibt es noch das Port-Modul. Das Port-Modul soll ein Port im Switch
darstellen. Dabei bundelt es die internen Nachrichten und leitet sie an einen extern liegenden
Port weiter. Weiterhin ist ein rudimentares RSTP-Protokoll auf den Port-Modulen eingebaut.
Dies soll die Simulation um die neu hinzugekommenen Events in MMRP vereinfachen. Das
Verfahren hinter RSTP ist im Grunlagenteil naher erklart und es ist nicht Gegenstand der
Analyse, RSTP zu untersuchen; deswegen ist die Implementierung in diesem Abschnitt nicht
ausfuhrlich beschrieben. Das Port-Modul bietet weiterhin eine großere Anzahl an Parametern,
KAPITEL 5. SIMULATION MIT OMNET++ 51
die fur die Eigenschaften von der Simulation wichtig sind. Diese sollen hier kurz beleuchtet
werden.19 simple Port
20 {21 parameters :
22 bool s t a r tB lo ck ing = de f au l t ( f a l s e ) ; // b e i beg inn in B l o c k i n g ?
23 bool tc = de f au l t ( f a l s e ) ; // mog l i ch das s i c h der Zustand vom Port a n d e r t ?
24 bool repeat = de f au l t ( f a l s e ) ;
25 bool disableMMRPEvents = de f au l t ( f a l s e ) ;
26 int timeTc = de f au l t (5 ) ; //wann s o l l s i c h t der p o r t andern
27 int portID = de f au l t (−1) ; // per z u f a l l s e t z t e n
28 int switchID = de f au l t (−1) ; // f e h l e r , wenn n i c h t g e s e t z t
29 int l inkCost = de f au l t (1 ) ;
30 int halloTime = de f au l t (2 ) ;
Listing 5.14: Die Parameter des Port-Modules aus der NED-Datei: Port.ned
Im Listing 5.14 sind einige Parameter des Portes mit ihren Default-Werten aus der NED-
Beschreibungsdatei abgedruckt. Der erste Parameter startBlocking bestimmst ob der Port bei
Beginn der Simulation abgeschaltet sein soll. Der Parameter tc, steht fur Topologie Change und
soll einen Wechsel der Topologie herbeifuhren. Dazu wechselt der Port von einem “funktionie-
renden” Port zu einem blockierenden Port. Dies kann auch in die andere Richtung erfolgen. So-
bald der Parameter auf true (=wahr) gesetzt wird, ist die Anderung des Portzustandes moglich.
Den Zeitpunkt, wann dies in der Simulation Passiert, bestimmt der Parameter timeTC. Weiter-
hin ist es moglich, dass die Anderung nach Ablauf der gleichen Zeitperiode wieder ruckgangig
gemacht wir; dies regelt der Parameter repeat. Der Parameter disableMMRPEvents ist gege-
ben, um die speziellen MMRP-Events die in dem Zusammenhang mit dem Wechsel der To-
pologie auftreten, abzuschalten. Der Sinn dahinter ist, dass so ein Vergleich mit dem alteren
GMRP-Protokoll einfacher moglich ist. Die weiteren Parameter (portID, switchID, linkCost,
halloTime) sind fur das RSTP-Potokoll gedacht. Der Parameter switchID muss gesetzt werden,
da aus ihm sich der Root-Switch bestimmt. Die weiteren Parameter konnen auf den Default-
Werten gelassen werden. Der Wert -1 zeigt bei der portID an, dass der Port sich eine zufallige
Portnummer (oder auch ID) bestimmt. Dies hat auf die Simulation keinen großeren Einfluss, da
das RSTP-Protokoll hier nur rudimentar eingebaut ist und so z.B. die Backup-Ports aus RSTP
nicht 100% unterstutzt und getestet sind. Diese Einschrankung kam zustande, da die Imple-
mentierung des RSTP-Protokolls nur als Unterstutzung der MMRP-Events fur den Wechsel der
Topologie in der Simulation gedacht ist. Denn die speziellen Events wie Flush! oder Re-declare!
konnen beim Wechsel der Topologie durch das RSTP-Protokoll einen kaskadenhaften Effekt
herbeifuhren, dies nur “Manuel” zu uberlegen erschien zu fehleranfallig.
Weiterhin sind in der Beschreibung der NED-Datei noch die Gates vorhanden, diese unter-
scheiden sich allerdings nicht gravierend von den anderen Module-Gates und sind hier deswegen
52 5.6. AUFBAU DES SWITCH-MODULES
von der Beschreibung als Listing ausgespart.
5.6 Aufbau des Switch-Modules
Nachdem alle wesentlichen Module beschrieben sind, lassen diese sich in OMNeT++ uber eine
weitere NED-Datei zu einem Modul zusammenlegen. Diese Verschaltung der Komponenten
entscharft die gesamte Komplexitat des Aufbaus. Verschiedene Detailtiefen lassen sich so in der
Simulation darstellen.
17 module Switch4way
18 {19 @display ( ” b g l =13; bgb =715 ,535 ” ) ;
20 gates :
21 inout port [ 4 ] ;
22 submodules :
23 Reg1 : Reg i s t ra rS {24 @display ( ”p =126 ,213 ” ) ;
25 }26 App1 : ApplicantS {27 @display ( ”p =126 ,329 ” ) ;
47 LeaveAll : LeaveAllS {48 @display ( ”p =347 ,268 ” ) ;
49 }50 port1 : Port {51 @display ( ”p =62 ,268 ” ) ;
62 connections :
63 port1 . extPort <−−> port [ 0 ] ;
64 port2 . extPort <−−> port [ 1 ] ;
65 port3 . extPort <−−> port [ 2 ] ;
66 port4 . extPort <−−> port [ 3 ] ;
75 Reg1 . PortOut −−> port1 . in++;
76 App1 . PortOut −−> port1 . in++;
77 Reg1 . PortIn <−− port1 . out++;
78 App1 . PortIn <−− port1 . out++;
79 Reg1 . ControleOut −−> App1 . Contro le In ;
80 Reg1 .MAPOut++ −−> LeaveAll . Contro le++;
81 Reg1 .MAPOut++ −−> App2 .MAPIn++;
82 Reg1 .MAPOut++ −−> App3 .MAPIn++;
83 Reg1 .MAPOut++ −−> App4 .MAPIn++;
84 Reg1 .MAPIn++ <−− port1 .MAPOut++;
85 App1 .MAPIn++ <−− port1 .MAPOut++;
Listing 5.15: Auszuge aus der NED-Datei: Switch4Way.ned, die den Modulaufbau eines
Switches verdeutlichen.
In Listing 5.15 ist das Switch-Modul ersichtlich. Dabei ist zu erkennen, dass dieses Modul
vier Port-Gates besitzt, mit dem es zu einem Netzwerk verbunden werden kann. (Zeile 21 und
Zeilen 50ff.) Neu hinzugekommene Befehle in der NED-Beschreibung sind die Anweisungen:
submodules und connections.
KAPITEL 5. SIMULATION MIT OMNET++ 53
Die Anweisung submodules lasst es zu, dass in diesem Unterblock des Moduls Switch4Way-
Module aus anderen Modulen definiert werden konnen. So definiert z.B. die Zeile 23 das Modul
Reg1, welches aus dem Modul RegsitrarS besteht. In dem Block mit den geschweiften Klam-
mern werden noch Zusatzinformationen abgelegt. Hier gibt der Display-String die Position des
Modules Reg1 im Modul Switch4Way an.
Die Anweisung connections regelt die Verbindungen der einzelnen Submodule im Modul
Switch4Way. In den Zeilen 63ff sind die Port-Module des Modul Switch4Way an die Gates
angeschlossen. Aus den Zeichen --> bzw. <-- lasst sich die Verbindungsrichtung ableiten. Dies
hangt damit zusammen, ob der Port Nachrichten aussenden oder empfangt. Bei Pfeilen in
beiden Richtungen handelt es sich um input und output Ports, so wie die Port-Gates in Zeile
21 des Modul Switch4Way definiert sind. Dabei wird bei den Verbindungen ab Zeile 63ff auf
zwei verschiedene Weisen auf die Arrays der Gates zugegriffen. Im ersten Fall, wie die Zeile 63
beispielsweise zeigt, ist durch die explizite Angabe des Indexes des Arrays in den Klammern das
Gate bestimmt. Im zweiten Fall, wird durch ein ++-Zeichen, wie es z.B. in Zeile 75 Verwendung
findet, ein weiteres Gate dem Array hinzugefugt.
package mmrp
Switch ay
Reg1
App1
Reg2 App2
Reg3 App3
Reg4
App4
port1
port2
port4
port3LeaveAll
Abbildung 5.1: Zeigt das Switchmodul, welches durch die Beschreibung der NED-Datei ent-
standen ist.
54 5.7. NETZWERKMODUL UND SIMULATIONSAUFBAU
In der Abbildung 5.1 ist das Switch4Way als Grafik zu erkennen. Dabei ist ersichtlich, dass
die Verbindungen der Module fur die internen Botschaften entsprechend geschaltet sind. Wei-
terhin ist zu erkennen, dass die Symbole der einzelnen Zustandsautomaten in der Standardein-
stellung rot sind. Dies Zeigt an, dass der Registrar sich im Zustand MT befindet. Beim Applicant
ist das Symbol rot damit man erkennt, dass der Applicant keine entsprechende Deklaration ge-
macht hat und der somit im Zustand VO sich befindet. Der LeaveAll -Zustandsautomat existiert
nur einmal im Switch, da er periodisch eine Aufforderung absendet, um zu uberprufen, ob noch
alle benotigten Registrierungen registriert bzw. deregistriert sind. Aus diesem Switch-Modul
lasst sich dann die letzte Modulebenen aufbauen. Ein Netzwerk Modul, welches aus mehre-
ren Switchen besteht. Dieses Modul kann anschließend an die Simulation ubergeben werden.
Weiterhin ist im Switch-Modell die PeriodicTransmission state machine nicht mit eingebaut,
da sie eine optionale Einstellungsmoglichkeit fur periodisches Aussenden der registrierten In-
formationen hat. Dies konnte zwar im Zweifel die Neuregistrierung mit einer Verzogerung der
periodischen Nachrichten erreichen, in der Arbeit jedoch soll untersucht werden, wie sich die
neuen Events fur RSTP auf das Verhalten der Zustandsautomaten auswirken. Somit ist sie fur
das Simulationsmodell nicht relevant.
5.7 Netzwerkmodul und Simulationsaufbau
Abbildung 5.2: Zeigt das Netzwerkmodell als Screenshot aus OMNeT++
KAPITEL 5. SIMULATION MIT OMNET++ 55
Um das Simulationsmodell abzuschließen, muss noch das Modul Netzwerk aufgebaut werden.
Der Aufbau des Netzwerkmodelles folgt dem gleichen Schema wie bei den einzelnen Switchen,
deswegen wird an dieser Stelle nicht naher auf den NED-Code des Modelles eingegangen.
Um die Simulation starten zu konnen, muss in OMNeT++ deklariert werden, welches Modell
und welche Parameter es dafur verwende soll. Dies gescheit mithilfe einer INI-Datei. In der
omnetpp.ini ist dabei angegeben, dass er das Netzwerk aus Abbildung 5.2 verwenden soll,
wenn beim Start der Simulation die Konfigurationseinstellung Network4WaySW4Port1 gewahlt
wird. Zum Starten der Simulation wird die Datei mmrp[.exe] mit dem Ubergabeparameter
omnetpp.ini aufgerufen. Das Netzwerk ist so konfiguriert, dass der alternative Port durch das
RSTP-Protokoll am Switch4 in Richtung Switch3 liegt. Das JoinMod ist ein einfaches Modul,
welches eine Registrierung anstoßt. So wurde also der Empfanger eines Multicast-Streams in
dieser Simulation am Port des JoinMod sitzen. Am Anfang der Simulation sind die Ports der
Switch-Modelle blau. Die blaue Farbe der Ports zeigt an, dass sich das Netzwerk uber das
RSTP-Protokoll noch nicht konfiguriert hat. Nach ca. 2 Sekunden in der Simulationszeit ist
das RSTP-Protokoll fertig und es kann mit dem eigentlichen Teil der Simulation begonnen
werden. (Die 2 Sekunden kommen aus der HelloTime aus RSTP)
Abbildung 5.3: Zeigt Simulationsbilder des Netzwerkes. Das linke Bild zeigt das Netzwerk vor
der Deklaration und Registration einer MAC-Adresse. Das rechte Bild zeigt
die Simulation nach der Deklaration und Registration einer MAC-Adresse.
Die Abbildung 5.3 zeigt den Screenshot des simulierten Netzwerkes. Dabei sind die Switch-
Module in der Reinfolge aufgebaut, wie das Netzwerk auch geformt ist. Aus diesem Grund ist
56 5.7. NETZWERKMODUL UND SIMULATIONSAUFBAU
auch nicht ein Bild mit der Netzwerktopologie abgebildet. Die Sichtweise der Switch-Module ist
weiterhin gewahlt, da sich hier auch die Zustande der einzelnen Zustandsautomaten leichter er-
kennen lassen. Auf dem linken Bild der Abbildung ist das Netzwerk durch das RSTP-Protokoll
fertig konfiguriert. Die Ports sind grun markiert, um anzuzeigen das sie Pakete fur MMRP
durchlassen. Weiterhin ist ein Port am Switch4 gelb, da dieser den Alternante-Port aus RSTP
darstellt und somit keine Pakete fur MMRP durchlasst. Die einzelnen Zustandsautomaten sind
noch rot, da sie sich im Anfangzustand befinden und somit keine Adresse deklariert oder regis-
triert haben.
Das rechte Bild zeigt die Simulation, nachdem eine Adressen Deklaration eingetroffen und
verarbeitet ist. Die Anfrage ist am Switch1 am linken Port eingetroffen (auf dieser Seite be-
finden sich, wie man in Abbildung 5.3 entnehmen kann, das JoinMod -Modul). Der Registrar
registriert daraufhin die Adresse und geht in den Zustand IN (hier dargestellt durch das grune
Symbol). Dabei sendet der Registrar intern eine Join! -Nachricht ab. Dies veranlasst die Appli-
cant-Zustandsautomaten des Switches wiederum zur Deklaration der Adresse bei den benach-
barten Switchen. Nach erfolgreicher Deklaration befinden sie sich im Zustand QA und sind in
dem Simulationsbild grun dargestellt. Die benachbarten Switche des Switch1 empfangen wie-
derum eine Aufforderung, die Adresse zu registrieren und an ihren Ports weiter zu deklarieren.
An der Abbildung lasst sich die Ausbreitung und die gleichmaßige Verteilung der Nachricht
erkennen. Weiterhin ist ersichtlich, dass der Registrar an den Ports in Richtung des JoinMod
grun durchgeschaltet ist und somit ein Multicast-Stream bei ihm ankommen kann. (Das Join-
Mod ist der Anfangspunkt fur die Join-Nachricht, er symbolisiert sozusagen einen Empfanger,
der einer Muticast-Gruppe beitritt und somit potenziell Nachrichten bzw. Streams empfangen
kann.)
Bei einem Wechsel der Topologie greifen die neuen Events von MRP. Wenn beispielsweise
der linke Port des Switches 4 ausfallt (Port1), dann fehlt dem Switch auf der einen Seite der
Root-Port als auch die Multicast-Weiterleitung auf in Richtung des Root-Switches. Dies fuhrt
zu zwei Aktionen. Erstens, durch den Verlust der Verbindung tragt MMRP automatisch die Re-
gistrierung an diesem Port aus. Dazu sendet es eine Leave-Nachricht Switch intern aus. Neu ist,
dass er aufgrund des Topologiewechsels ein Flush-Event aussendet wird. Beide Events fuhren zu
einer Deregistrierung der Adressen. Zweitens informiert RSTP seine Ports im Switch uber den
Wechsel der Topologie. Was wiederum veranlasst den Alternate-Port seinen Status zu wechseln,
was an dieser Stelle auch erst ein Flush-Event hervorruft. Nachdem nun im Switch intern die
Adressen ausgetragen sind und zeitgleich der inaktive Port, welcher vorher ein Alternate-Port
KAPITEL 5. SIMULATION MIT OMNET++ 57
war, sich auf ein Root-Port umschaltet, sendet dieser ein Re-Declare-Event aus. Dies veranlasst
den Applicant Zustandsautomaten in den Zustand LO zu wechseln. Im Zustand LO wartet
er die JoinTime ab und sendet eine Mt-Nachricht ab. Das Empfangen der Mt-Nachricht am
Switch3 fuhrt dazu, dass der Applicant-Zustandsautomat am unteren Port erneut seine Adresse
deklariert. Dazu geht dieser Automat in den Zustand AA uber und sendet nach einer JoinTime
erneut den Deklarationswunsch an den Switch 4 ab. Der Switch 4 Registriert intern die Adres-
se. Nach insgesamt 2-mal der JoinTime ist also am Switch4 die neue Route fur die Multicast
Adresse bekannt. Dies fuhrt also u einer theoretischen maximalen Verzogerung durch MMRP
von:
2 · JoinT ime = 2 · 200ms = 400ms
Bei RSTP kann es allerdings zu weiteren Verzogerungen kommen, wenn z.B. nicht wie in
diesem Idealfall der Ausfall des Portes direkt gefunden wird, sondern erst durch den Ausfall
der Hallo-Nachrichten erkannt werden kann. Das bedeutet, dass sich RSTP erst nach 6 Sekun-
den neu konfiguriert. Dies ist fur den Fall der Standardeinstellung von 2 Sekunden gegeben.
Weiterhin kann das Netzwerk aufgrund seiner Topologie durch RSTP auch erst nach einiger
Zeit wieder in einen stabilen Zustand konvergieren. Um den Vorteil von maximal 200ms zur
Neuregistrierung der Adressen nicht zu verlieren, ist es deshalb eventuell notig, ein anderes
Redundantprotokoll, wie das Media Redundancy Protocol von Hirschmann, fur das Netzwerk
einzusetzen.
6 Paketformat und Testtools
Abbildung 6.1 zeigt das MRP-Paket. Dabei sind alle Elemente aus MRP ersichtlich, denn die
eigentliche Applikation MMRP, die das Paket letztendlich erstellt, braucht nur einen Teil der
Elemente. Nachfolgend ist abgeleitet vom MRP-Frame, das MMRP-Frameformat naher erklart.
MRP ist ein Protokoll fur die MAC-Schicht. Aus diesem Grund befindet sich das MMRP-
Paket auch direkt im Daten-Teil der MAC-Schicht. In der Abbildung 6.1 ist dies versucht, durch
das Element EtherType deutlich zu machen. Das Element EtherType ist noch ein Teil der MAC-
Schicht. Allerdings ist der Type 0x88f6 fur das MMRP-Frame im EtherType Feld reserviert.
Nach dem Feld EtherType in der Grafik kommt das erste Feld aus dem MMRP-Frame. Es ist
das Feld fur die Protokollversion. Das Feld hat den Wert eins. Danach konnen eins oder auch
mehrer Message Felder kommen. Diese werden durch ein EndMark Feld abgeschlossen. (Ein
zwei Byte großes Feld, welches aus Nullen besteht.) Ein Message Feld ist durch drei wesentli-
che Elemente aufgebaut. Das Feld AttributeListLength ist nicht Bestandteil des MMRP-Frames
aus diesem Grund ist auch nur die Rede von drei wesentlichen Feldern. AttributeType Feld gibt
an, welcher Typ von Attribut ubertragen werden kann. MMRP ubertragt zwei verschiedene
Typen. Das Feld hat eine Zwei encodiert, wenn es eine MAC-Adresse ubertragt. Die Große des
Attributes, welches eine MAC-Adresse darstellt, ist 6 Byte. Hieraus flogt, dass im Feld Attri-
buteLength die Große mit 6 encodiert ist. Das letzte Feld des Message-Feldes ist das Feld fur
die AttributeList. Das Feld AttributeList ist wiederum ein zusammengesetztes Feld aus einer
Liste des Feldes VectorAttribute. Das Ende der Liste markiert ein EndMark Feld nach dem
letzten VectorAttribute. Das Feld VectorAttribute besteht wiederum aus drei Feldern. Dem Feld
VectorHeader, FirstValue und dem eigentlichen Vector. Das 2 Byte große Feld VectorHeader ist
in zwei Bit-Felder aufgeteilt. Dabei sind die ersten 3 Bits fur das LeaveAll -Event vorgesehen.
Die restlichen 13 Bits definieren die Anzahl der zu ubertragenen Events und heißen Number-
OfValues. Das nachste Element ist in MMRP meist eine MAC-Adresse, dabei ist der Typ des
Feldes FirstValue abhangig von dem encodierten Type AttributeType in dem Message Feld.
58
KAPITEL 6. PAKETFORMAT UND TESTTOOLS 59
0..1
Byt
e0.
.1 B
yte
3 B
its13
Bits
2 B
yte
2 B
yte
1..2
2 B
yte
0..N
Byt
e
Attr
ibut
Lis
t3.
.N B
yte
3..N
Byt
e2
Byt
e
Mes
sage
1 B
yte
1 B
yte
2 B
yte
5..N
Byt
e
Mes
sage
{Mes
sage
}M
RP
DU
1 B
yte
9..N
Byt
e9.
.N B
yte
2 B
yte
Th
ree
Pa
cked
Eve
nts
{Th
reeP
acke
dE
vent
s}V
ecto
r
Leav
eAllE
ven
tN
um
berO
fVa
lues
Vec
tro
H
ead
er
Ve
cto
rHe
ade
rF
irstV
alu
eV
ect
or
Vec
tro
A
ttrib
ute
Ve
cto
rAttr
ibut
e{V
ecto
rAttr
ibu
te}
End
Mar
k
Att
ribut
eT
ype
A
ttrib
ute
Leng
th
[Attr
ibu
teL
istL
eng
th]
Att
ribut
eLi
st
...[E
ther
Typ
e]
Pro
toco
lVer
sion
End
Mar
k
Abbildung 6.1: Zeigt das Format des MRP-Paketes. MMRP ist eine Applikation auf MRP
und braucht nur einen Teil des MRP-Paketes. Erstellt nach: [7] Seite 178ff.
60 6.1. MMRP-PAKETGENERATOR
Fur eine MAC-Adresse belegt dieses Feld 6 Bytes, wie es auch in AttributeLentgh Feld des
Message Feldes angegeben ist. Im anschließenden Feld ThreePackedEvents werden je 3 Events
in einem Byte ubertragen. Die Anzahl dieser Felder ergibt sich aus dem Wert, der im Feld Num-
berOfValues abgelegt ist. Weiterhin steht das erste Event des ThreePackedEvents im Feld fur
die MAC-Adresse aus dem FirstValue-Feld. Das zweite Event im ThreePackedEvents Byte steht
fur die MAC-Adresse aus dem FirstValue-Feld + 1. Beim dritten Event gilt dies entsprechend.
(Also Wert aus dem Feld FirstValue+2).
Das ThreePackedEvents wird nach folgender Formel berechnet:
ThreePackedEventsBY TE = (((((AttributeEvent)·6)+AttributeEvent)·6)+AttributeEvent)
= 36 · AttributeEvent + 6 · AttributeEvent + AttributeEvent
Weiterhin ist die maximale Zahl, die dabei erreicht werden kann, nur 36 · 5 + 5 · 6 + 6 =
180 + 30 + 6 = 216 und ist damit kleiner als die 256 Moglichkeiten, die ein Byte in seinem
Zahlenraum ablegen kann.
6.1 MMRP-Paketgenerator
In der Arbeit ist ein MMRP-Paketgenerator auf der Idee eines bereits existierenden GMRP-
Paketegenerators, welcher bei Hirschmann entwickelt wurde, entstanden. Dieser Paketgenerator
kann sowohl unter Windows als auch unter Linux mithilfe der Pcap-libary Pakte erzeugen.
Abbildung 6.2: Zeigt den Aufrufgraphen aus der Main-Methode.
Abbildung 6.2 zeigt den prinzipiellen Aufrufgraphen der Main-Funktion. Allerdings sind in
dem Graphen nur die selbst geschriebenen Funktionen dargestellt. So sind weiter Systemfunk-
tionen und Funktionen aus der Pcap-Libary nicht dargestellt.
KAPITEL 6. PAKETFORMAT UND TESTTOOLS 61
Die Main-Funktion uberpruft als erstes, ob ein Parameter ubergeben wird; denn aus diesem
Parameter wird die MAC-Adressen-Liste ausgelesen. Anschließend initialisiert sie die Pcap-
Libary. Die Funktion readMacList(), der Klasse Cmmrp, liest aus der MAC-Adressen-Liste,
welche auf der Festplatte als ASCII-encodierte Datei vorliegt, die MAC-Adressen ein und legt
sie intern im Objekt der Klasse Cmmrp in einer Liste ab. Diese Liste wird zur Sicherheit noch
auf dem Bildschirm ausgegeben. Nun ist das Programm soweit, um ein MMRP-Frame zu er-
stellen und an die Pcap Schnittstelle zu versenden. Dies geschieht uber den Funktionsaufruf
mmrPDU der Klasse Cmmrp. Die Funktion packet_handler() ist eine Funktion, die der Pcap-
Libary ubergeben wird, um dort empfangene Pakete von Pcap auszuwerten. Dazu analysiert die
Funktion das Paket und schickt bei einem Empfang eines LeaveAll -Event erneut eine JoinMt-
Nachricht fur die MAC-Adressen ab. Dies sollte den Switch veranlassen, die MAC-Adressen in
sich einzutragen. Fur ein vollstandiges Verhalten musste allerdings fur jede MAC-Adresse ei-
ne ApplicantOnly-Zustandsautomat implementiert werden, denn vom Switch konnte auch eine
Lv -Nachricht versendet werden, auf die der Zustandsautomat fur die einzelne MAC-Adresse
wiederum ein JoinIn bzw. JoinMT absenden musste.
Das eigentliche Generieren des MMRP-Paketes passiert in der Klasse Cmmrp, aus diesem
Grund wird sie in der Arbeit naher beschrieben.
18 class Cmmrp
19 {20 public :
21 Cmmrp(bool frameType=fa l se ) ;
22 ˜Cmmrp( ) ;
23 int readMacList ( const std : : s t r i n g f i leName ) ;
24 void printMacList (void ) ;
25 int mmrPDU( pcap t ∗adhandle ) ;
26 int c a l c u l a t e S i z e (void ) ;
27 void setIeeeFrame (bool frameType ) ;
28 protected :
29 private :
30 std : : vec tor <Cmac> mac ;
31 bool ieeeFrame ;
32 void threePackedEvents (unsigned char events [ 3 ] , unsigned char ∗packed ) ;
33 unsigned char∗ vectorAttr ibJoinMt ( int numberOfValues , unsigned char f i r s tVa l u e [ 6 ] , unsigned char∗dstBuf , int s i z e , bool l eaveAl lEvent=fa l se ) ;
34 bool macComparePlusOne (unsigned char∗ mac1 , unsigned char∗ mac2) ;
35 unsigned char∗ message (unsigned char∗ dstBuf , int s i z e ) ;
36 } ;
Listing 6.1: Zeigt die Deklaration der Klasse Cmmrp()
Bei der Entwicklung des Frame-Generators ist die Moglichkeit eingebaut worden einen IEEE-
Frame und einem EthernetII-Frame zu genieren. Allerdings ist dies nicht direkt mit Pcap
moglich, da Pcap automatisch das unterstutzte Frame-Format von dem Betriebssystem und/oder
der Netzwerkkarte verwendet. Aus diesem Grund sind in der Klasse die Zeilen 27 und 31 des
Listings 6.1 eigentlich uberflussig. Die Funktionen sind in der Klasse weiterhin enthalten, da
62 6.1. MMRP-PAKETGENERATOR
hierdurch ein Wechsel auf ein anderes Frame-Format einfacher moglich wird.
Das MMRP-Frame ist an sich sehr verschachtelt. Um dies einigermaßen ubersichtlich und
doch Modular darzustellen ist die Klasse Cmmrp entstanden. So sind die einzelnen Hauptebenen
durch einzelne Methoden abgetrennt. Lediglich einfachere Elemente, wie z.B. VectorHeader ist
direkt in der Funktion vectorAttribJoinMt() aus Zeile 33 verarbeitet.
Nachfolgend wird der Aufbau eines MMRP-Paketes durch die Klasse naher beleuchtet. Dazu
wird als Erstes die Funktion mmrPDU() durch die Main-Funktion aufgerufen. Ubergeben be-
kommt die Funktion den handler fur die Netzwerkkarte. Die Funktion mmrPDU() wiederum be-
rechnet als erstes die Große des Paketes mithilfe der Funktion calculateSize(). calculateSize()\verb
liefert nur die Große des MMRP-Datenpaketes zuruck. Fur ein EthernetII-Frame muss dies
noch um die Große des EthernetII-Frame-Header erweitert werden, bevor der die entsprechende
Große auf dem Heap mit einem malloc()-Befehls reservieren kann. (Pcap bzw. das Betriebssys-
tem kummert sich automatisch um die FCS.) Der MAC-Header sowie das ProtocolVersion-Feld
wird nun an die Speicherstelle des Heaps kopiert. Diese Speicherstelle wird um die Position
verschoben und an die nachste Ebene des MMRP-Paketes weiter gereicht. Dies ist die Mes-
sage-Ebene. Danach wird das Message-Feld mit einem EndMark -Feld abgeschlossen. Fur die
Message-Ebene ist die entsprechende Funktion, also die message()-Funktion zustandig. Die
message()-Funktion kopiert die beiden bereits bekannten Elemente AttributeType und Attri-
buteLength an die entsprechenden Stellen. Bevor nun die einzelnen Vektoren innerhalb der Attri-
buteList geschrieben werden konnen muss erst noch die Anzahl der zusammengehorigen MAC-
Adressen in der Liste erkannt werden. Dies geschieht mithilfe der Funktion macComparePlusOne().
Nachdem die Anzahl der zusammengehorigen Elemente bekannt ist, kann ein VectorAttribu-
te geschrieben werden. Dies funktioniert mithilfe der Funktion vectorAttribJoinMt(). Das
JoinMt im Funktionsnamen steht dafur, dass an die Funktion threePackedEvents() fur jedes
Event ein JoinMT ubergeben wird. In der Funktion vectorAttribJoinMt() werden weiterhin
die Elemente VectorHeader und FirstValue geschrieben. Dies ist auch aus den Ubergabepa-
rametern des Listings in Zeile 33 zu erkennen.
Durch dieses Vorgeben ist die Generierung des Paketes leicht anpassbar; so ist es sehr leicht
moglich, auch andere Events in einen Vektor zu verpacken, sollte dies notig sein.
KAPITEL 6. PAKETFORMAT UND TESTTOOLS 63
6.2 Wireshark Dissector
Der Wireshark Dissector ist mithilfe der beiden Dissector GMRP und MSRP entstanden. Diese
sind im Source Code auf der Wireshark Homepage zu finden.
Abbildung 6.3: Zeigt ein aufgezeichnetes MMRP-Paket durch Wireshark, welches mithilfe
des Dissectors sich analysieren lasst.
Der Screenshot der Abbildung 6.3 zeigt ein aufgezeichnetes MMRP-Paket, welches mithilfe
des in der Arbeit entstandenen Wireshark Dissector ananlysiert werden kann. Der Dissector
ist in der Zwischenzeit auch in der Version 1.6 von Wireshark enthalten. (Wie den Release
64 6.2. WIRESHARK DISSECTOR
Notes entnommen werden kann. http://www.wireshark.org/docs/relnotes/wireshark-1.
6.0.html)
Im unteren Bereich des Wireshark-Fensters lasst sich das Frame als Daten-Blob erkennen.
Daruber ist die Ansicht, die durch den Dissector eine einfachere Analyse des Frames ermoglicht.
Wireshark erkennt, dass es sich um ein MMRP-Frame handelt anhand des EtherTypes (0x88f6)
und ubergibt den Inhalt des Frames an den Dissector weiter. (Spater im Abschnitt wird dar-
auf eingegangen, wie die Ubergabe der Daten genau geregelt ist, hier sollen erst einmal die
wesentlichen Elemente des Dissectors beleuchtet werden.)
Als erstes zeigt der Dissector die Protokoll Version des MMRP-Frames an. Danach kommt das
entsprechende Message-Feld, welches sich ausklappen lasst, um die weiteren Felder innerhalb
des Message-Schicht analysieren zu konnen. Dabei zeigt der Dissector hier schon an, ob sich die
Message um eine MAC-Adresse handelt. Innerhalb der Message-Ebene sind die entsprechenden
Felder im Dissector dargestellt. Auch hier lasst sich der AttributeType der Message-Nachricht
direkt am Feld ablesen. Dazu zeigt er einerseits den dezimalen Wert an, als auch die Bedeu-
tungen hierzu. In der Abbildung ist dies hier eine MAC-Adresse. Sie hat auch die Große von 6
Bytes, wie sich am AttributeLength-Element erkennen lasst. Die AttributeListe wiederum ist ein
Element, das sich ausklappen lasst, da es in sich mehrere Felder enthalt. So gestaltet sich dies
auch mit den nachsten zwei ineinander geschachtelten Feldern VectorAttribute und VectrorHea-
der. Innerhalb des VectorHeaders sind die zwei Bit-Felder noch aufgeschlusselt. Anschließend
ist das Feld FirstValue, welches sich nicht gesondert darstellt, da es auf der einen Seite ei-
ne MAC-Adresse enthalt, aber auf der andren Seite auch noch weitere Werte innerhalb des
MMRP-Frames annehmen kann. Das darauf folgende Element in der Darstellung des Dissec-
tors entspricht dem ThreePackedEvents Feld des MMRP-Paketes, allerdings ist hier bereits das
Feld entpackt und entsprechend dem Event zugeordnet. Dieser Unterschied lasst sich auch an
der Datendarstellung erkennen. Dort ist der Wert mit 0x6c dargestellt. Dies entspricht dezimal
108; teilt man nun 108 durch 36, da es nur ein Element enthalt, so kommt man auf das Ergeb-
nis 3, welches einem JoinMT -Event entspricht. Anschließend an den Vektor sind noch weitere
Vektoren, die allerdings hier nicht ausgeklappt wurden. Abgeschlossen werden diese Vektoren
durch ein EndMark -Feld, welches im Dissector fur den Vektor als auch fur das Message-Feld
endet.
KAPITEL 6. PAKETFORMAT UND TESTTOOLS 65
220 stat ic void
221 dissect mmrp ( t vbu f f t ∗tvb , pa ck e t i n f o ∗pinfo , p r o t o t r e e ∗ t r e e )
222 {223 /∗ Set up s t r u c t u r e s needed t o add t h e p r o t o c o l s u b t r e e s and manage them ∗/
224 proto i tem ∗ t i , ∗msg ti , ∗ a t t r l i s t t i , ∗ v e c t a t t r t i , ∗ f i r s t v a l u e t i ;
225 p r o t o t r e e ∗mmrp tree , ∗msg tree , ∗ a t t r l i s t t r e e , ∗ v e c t a t t r t r e e ; // , ∗ f i r s t v a l u e t r e e ;
226
227 /∗ Make e n t r i e s in P r o t o c o l column and I n f o column on summary d i s p l a y ∗/
228 c o l s e t s t r ( pinfo−>c in fo , COL PROTOCOL, ”MRP−MMRP” ) ;
229
230 c o l s e t s t r ( pinfo−>c in fo , COL INFO, ” M u l t i p l e Mac R e g i s t r a t i o n P r o t o c o l ” ) ;
231
232 i f ( t r e e ) {
241 t i = pro to t r e e add i t em ( tree , proto mmrp , tvb , 0 , −1, ENC NA) ;
242 mmrp tree = proto i t em add subt r ee ( t i , ett mmrp ) ;
243
244 pro to t r e e add i t em (mmrp tree , hf mmrp proto id , tvb , MMRP PROTOCOL VERSION OFFSET, 1 , ENC BIG ENDIAN
) ;
Listing 6.2: Zeigt den Beginn der Main-Dissector Funktion. Aus der Datei:
packet-mrp-mmrp.c
Im Listing 6.2 ist der Anfang der Main-Dissector Funktion zu erkennen. An sie wird durch
tvbuff_t *tvb das Frame, welches zu untersuchen gilt, als Pointer ubergeben. Die verschiede-
nen Elemente, welche in Wireshark dargestellt sind, werden uber einen Baum (hier durch den
Pointer proto_tree *tree reprasentiert) verwaltet. An diesem Baum wird auch in Zeile 241
das erste Element angehangt, welches das komplette MMRP-Frame darstellt. Dieses Element
wird um einen Subtree erweitert und ein weiteres Element die Protokollversion erweitert. Fur
ein tieferes Verstandnis der einzelnen Wireshark-Funktionen sei an dieser Stelle auf das Devel-
oper Howto: [2] verwiesen. Der Parameter MMRP_PROTOCOL_VERSION_OFFSET gibt den Offset der
Protokollversion im Datenpuffer an und wurde am Anfang der Datei uber Defines festgelegt.
251 msg o f f s e t = 0 ;
252 while ( tvb ge t n tohs ( tvb , MMRP ATTRIBUTE TYPE OFFSET + msg o f f s e t ) != MMRPENDMARK) {
264 msg t i = pro to t r e e add i t em (mmrp tree , hf mmrp message , tvb ,
265 MMRP MESSAGE GROUP OFFSET + msg o f f s e t ,
266 −1, ENC NA) ;
267 msg tree = proto i t em add subt r ee ( msg ti , ett msg ) ;
268
269 /∗ Append A t t r i b u t e T y p e d e s c r i p t i o n t o t h e end o f t h e ” Message ” head ing ∗/
270 proto i t em append text ( msg tree , ” : %s (%d ) ” , v a l t o s t r ( a t t r i bu t e type ,
271 a t t r i bu t e t yp e va l s , ”<Unknown>” ) , a t t r i bu t e t yp e ) ;
272
273 dissect mmrp common1 ( msg tree , tvb , msg o f f s e t ) ;
Listing 6.3: Zeigt den Beginn der Message-Schleife im Dissector.
Im Listing 6.3 sieht man die Hauptschleife des Dissectors. Sie dient der Analyse meh-
rere Message-Felder, die nacheinander im MMRP-Frame auftauchen konnen. Die Variable
msg_offset dient dabei als Offset der einzelnen Message-Felder im Frame. Anschließend wird
66 6.2. WIRESHARK DISSECTOR
ab Zeile 264 wieder ein neuer Ast in den bestehenden Baum eingefugt. Der Knoten zu diesem
Ast wird in Zeile 270 noch um den Typ des Attributes erweitert. Die dissect_mmrp_common1()-
Funktion stammt ursprunglich aus dem MSRP-Dissector und zerlegt die Feldelemente Attribu-
teType und AttributeLength.290 v e c t o f f s e t = 0 ;
291 while ( tvb ge t n tohs ( tvb , MMRP VECTOR HEADER OFFSET + msg o f f s e t + v e c t o f f s e t ) != MMRPENDMARK)
{
300 number o f va lues = tvb ge t ntohs ( tvb , MMRP NUMBER OF VALUES OFFSET + msg o f f s e t + v e c t o f f s e t
)
301 & MMRP NUMBER OF VALUES MASK;
302
303 v e c t a t t r l e n = 2 + a t t r i b u t e l e n g t h + ( number o f va lues + 2) /3 ; /∗ s t o r e s 3 v a l u e s per b y t e
∗/
304
305 v e c t a t t r t i = pro to t r e e add i t em ( a t t r l i s t t r e e , h f mmrp vector at t r ibute , tvb ,
306 MMRP VECTOR ATTRIBUTE GROUP OFFSET + msg o f f s e t +
v e c t o f f s e t ,
307 v e c t a t t r l e n , ENC NA) ;
308
309 v e c t a t t r t r e e = proto i t em add subt r ee ( v e c t a t t r t i , e t t v e c t a t t r ) ;
310
311 dissect mmrp common2 ( v e c t a t t r t r e e , tvb , msg o f f s e t + v e c t o f f s e t ) ;
312
313 i f ( a t t r i bu t e t yp e == MMRP ATTRIBUTE TYPE MAC) {314 /∗ MMRP F i r s t V a l u e i s a Mac Adress ∗/
315
316 f i r s t v a l u e t i = pro to t r e e add i t em ( v e c t a t t r t r e e , h f mmrp f i r s t va lue , tvb ,
317 MMRP FIRST VALUE GROUP OFFSET + msg o f f s e t +
v e c t o f f s e t ,
318 a t t r i bu t e l eng th , ENC NA) ;
319 /∗ Decode t h r e e packed e v e n t s . ∗/
320 o f f s e t = di s sec t mmrp three packed event ( v e c t a t t r t r e e , tvb ,
321 MMRP MAC THREE PACKED OFFSET + msg o f f s e t +
v e c t o f f s e t ,
322 number o f va lues ) ;
Listing 6.4: Zeigt die Schleife fur das VectorAttribute
Listing 6.4 zeigt, dass die anschließende Schleife zum Analysieren des VectorAttribute Fel-
des im MMRP-Frame. Die Variable vect_offset dient, wie beim Message Feld, den Offset der
einzelnen VectorAttribute Felder trennen zu konnen. Das NumberOfValues Feld wird anschlie-
ßend ausgelesen und damit die Lange des VectorAttribute ausgerechnet. Dies ist notig, um in
Wireshark durch das Auswahlen der analysierten Felder diese im Datenfenster hervorheben zu
konnen. Ab Zeile 305 wird hier das VectorAttribute Feld einem eigenen Ast im Baum hinzu-
gefugt. dissect_mmrp_common2() ist fur die Darstellung der Bit-Felder LeaveAll -Event und
NumberOfValues zustandig. Die Fallabwagung durch den if-Block ermoglicht die Behandlung
der verschieden Attribute-Typen. In dem Listing ist dabei die Analyse des MAC-Typs dar-
gestellt, welche als Erstes das FisrtValue-Element in Wireshark hervorhebt und anschließend
uber die Methode dissect_mmrp_three_packed_event() die ThreePackedEvents zerlegt und
fur Wireshark darstellt.
7 Zusammenfassung und Ausblick
Das MMRP ermoglicht das dynamische Registrieren von MAC-Adressen auf den verschiede-
nen Switchen. Hierbei konnen vor allem auch Multicast-MAC-Adressen registriert werden. Das
Verfahren eignet sich hierfur bei Switchen eher gut, da es im Gegensatz zu dem IGMP keinen
Router benotigt, von dem aus die Registrierung uberwacht wird. Dies ist bei Switchen besonders
sinnvoll, da sie anders als Router nicht auf der IP-Ebene, sondern auf der MAC-Ebene arbeiten
und somit in lokalen Netzwerken nicht unbedingt ein Router vorhanden ist oder benotigt wird.
Weiterhin bietet das Protokoll, wie in der Simulation gezeigt wurde, den Vorteil, dass es die
Aste eines Netzwerkbaumes, welcher sich z.B. durch das RSTP-Protokoll formt, gleichmaßig
ausnutzt und so im Gegensatz zu IGMP auch die Moglichkeit besteht, einen Multicast-Stream-
Sender im gleichen lokalen Netzwerk unabhangig vom Router einsetzen zu konnen. Weiterhin
konnte durch die Simulation aufgezeigt werden, dass durch MMRP eine deutliche Verbesserung
der Performance im Falle einer Verbindungsunterbrechung und anschließender Korrektur durch
ein Redundanz-Protokoll wie RSTP bzw. des Media Redundancy Protocol im Gegensatz zu
dem alteren Protokoll GMRP moglich ist. Dadurch und durch die Moglichkeit der im weite-
ren durch die Einfuhrung der Protokolle unterhalb von MRP (wie MMRP und MSRP) wird
es besser moglich, auch Multicast-Videostreams fur die Sicherheitstechnik z.B. durch Uber-
wachungskameras einzusetzen und zeitgleich Bandbreite im Netzwerk einzusparen. Weiterhin
konnte eine Kombination von IGMP mit MMRP durch spezielle Gateways direkt auf den Swit-
chen die Vorteile von MMRP auch fur die normalen Protokolle mit sich bringen, denn MMRP
setzt voraus, dass eine Anwendung speziell fur MMRP geschrieben ist, wo hingegen IGMP be-
reits in den meisten Betriebssystemen integriert ist. Durch die in dieser Arbeit entstandenen
Test-Tools ist es nun einfacher moglich, Switche auf die Funktionalitat von MMRP zu testen. So
ist auf der einen Seite durch einen Paket-Generator moglich, MAC-Adressen auf den Switchen
zu Registrieren als auch direkt die Nachrichten durch einen Wireshark Dissector zu analysieren.
67
Abbildungsverzeichnis
3.1 Genereller Aufbau eines Ethernet IEEE 802.3 Frames mit LLC und SNAP Ein-
bettung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2 Genereller Aufbau eines Ethernet-II-Rahmens. Dieser unterscheidet sich zum
IEEE802.3 Frame nur in dem Type-Feld. . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Einbettung des IP und des ARP-Protokolls in ein LLC/SNAP-Frame. Mithilfe
der SAP-Adresse 0xAA und den verschiedenen EtherType fur IP (0x0800) und
ARP (0x0806). Nach: [11] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4 Einbettung des IP und des ARP Protokolls in Ethernet-II-Frames mithilfe der
verschiedenen EtherType fur IP (0x0800) und ARP (0x0806). Nach: [11] . . . . 6
3.5 Der Aufbau des IP-Frames. Ersichtlich ist, dass es einen eigenen Header mit 20
Bytes pro Paket mit sich bringt. Nach: [11] . . . . . . . . . . . . . . . . . . . . . 6
3.6 Aufbau eines einfachen Netzwerkes. Die blauen Knoten stellen Switches dar.
Symbolhaft sind dabei nur Empfanger und Sender dargestellt; es konnen noch
weitere End-Knoten an den Switchen angeschlossen sein. . . . . . . . . . . . . . 8
3.7 Aufbau eines einfachen Netzwerkes. Hier sind die Verbindungen allerdings uber
eine Multicast-Adresse gelost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.8 Tabelle aus der Norm: [6] Seite 154. Sie zeigt die empfohlenen Werte fur den
Parameter: Link Cost . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.9 Ein kleines Netzwerk mit verschiedenen Port Typen und einem Root-Switch.
Quelle [10] Seite 214 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.10 Ein kleines Netzwerk, in dem die verschiedenen Port Rollen der Switche darge-
stellt sind. Quelle [10] Seite 233 . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.11 Netzwerk, das in einem Ring aufgebaut ist. Ein Switch hat einen Redundanz-
Manager fur das Media-Redundancy-Protocol. Die Wolken zwischen den Swit-
ches stellen weitere Netzwerk Kompnenten dar, wie z.B. ein Hub. Die gelbe
Netzwerkverbindung wurde von dem Protokoll deaktiviert. . . . . . . . . . . . . 16
68
Abbildungsverzeichnis 69
3.12 In diesen Netzwerken ist der Redundanzfall eingetreten. Erkannt wird er auf
zwei verschiedene Weisen. Rot ist jeweils der Teil, der ausgefallen ist. Blau ist
die Leitung, die durch den Redundanz-Manager wieder aktiviert wurde, um die
fehlende Verbindung wieder herzustellen. . . . . . . . . . . . . . . . . . . . . . . 17
3.13 Ein Netzwerk, das uber mehrere Switche und einen zentralen Router verfugt.
Dieser kann IP-Daten z.B. in das Internet routen . . . . . . . . . . . . . . . . . 19
3.14 Zeigt ein Netzwerk, in dem die Switche IGMP-Snooping machen. Die Switche
haben sich den Query-Port des Routers eingetragen (Q), sowie den Port, von
dem eine Report-Anfrage (M1) kam. . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1 Zeigt den Zustandsautomaten des Registrars aus MRP. Quelle: [5] Seite 45 . . . 25
4.2 Zeigt den Zustandsautomaten des Applicant aus MRP. Quelle: [5] Seite 44 . . . 31
4.3 Zeigt den LeaveAll Zustandsautomaten aus MRP. Quelle: [5] Seite 44 . . . . . . 36
5.1 Zeigt das Switchmodul, welches durch die Beschreibung der NED-Datei entstan-
den ist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2 Zeigt das Netzwerkmodell als Screenshot aus OMNeT++ . . . . . . . . . . . . . 54
5.3 Zeigt Simulationsbilder des Netzwerkes. Das linke Bild zeigt das Netzwerk vor
der Deklaration und Registration einer MAC-Adresse. Das rechte Bild zeigt die
Simulation nach der Deklaration und Registration einer MAC-Adresse. . . . . . 55
6.1 Zeigt das Format des MRP-Paketes. MMRP ist eine Applikation auf MRP und
braucht nur einen Teil des MRP-Paketes. Erstellt nach: [7] Seite 178ff. . . . . . . 59
6.2 Zeigt den Aufrufgraphen aus der Main-Methode. . . . . . . . . . . . . . . . . . . 60
6.3 Zeigt ein aufgezeichnetes MMRP-Paket durch Wireshark, welches mithilfe des
Dissectors sich analysieren lasst. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Tabellenverzeichnis
4.1 Beispielhaftes Durchlaufen des Zustandsautomaten fur das Registrieren und De-
registrieren eines MAC-Eintrages. . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Verlauf des Zustandsautomaten beim Registrieren bis zum Deregistrieren der
Adresse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
70
Listings
5.1 Registrar state machine Module der NED-Datei (RegistrarS.ned) zur Beschrei-
bung des Aufbaus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 Dekleration der Registrar-Klasse in der Datei RegistrarS.h . . . . . . . . . . . 41
5.3 Definition der Registrar state tabel in der Datei constTypes.h . . . . . . . . . . 42
5.4 Methode zum Initialisieren des Registrar-Zustandsautomaten. Weiterhin zusatz-
liche Definitionen fur OMNeT++ . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.5 Auszug aus der RegistrarS::handleMessage()-Methode. . . . . . . . . . . . . 44
5.6 Auszug aus RegistrarS.cc, um die Anderungen des Zustandes versenden zu
konnen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.7 Methode, die die Nachrichten (*msg) in Events umwandelt aus RegistrarS.cc . 45
5.8 Definition der Applicant-Klasse aus ApplicantS.h . . . . . . . . . . . . . . . . . 47
5.9 Auszug aus der Implementation von der Applicant-Klasse in der Datei: ApplicantS.cc. 47
5.10 Auszug aus der Implementation von der Applicant-Klasse. Sie zeigt dabei die
Methode ReScheduleTxEvent(...) in der Datei: ApplicantS.cc. . . . . . . . . 47
5.11 Auszug aus dem Aufbau der LeaveAllS.ned Datei. . . . . . . . . . . . . . . . . 48
5.12 Auszug aus dem Programmcode zum LeaveAll-Modul, die das Versenden an
mehrere Gate-Vektoren zeigt. Aus der Datei: LeaveAllS.cc . . . . . . . . . . . 49
5.13 Auszug aus dem Programmcode zum LeaveAll-Modul, welches die Initialisierung
des Modules zeigt. Aus der Datei: LeaveAllS.cc . . . . . . . . . . . . . . . . . 50
5.14 Die Parameter des Port-Modules aus der NED-Datei: Port.ned . . . . . . . . . 51
5.15 Auszuge aus der NED-Datei: Switch4Way.ned, die den Modulaufbau eines Swit-
ches verdeutlichen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.1 Zeigt die Deklaration der Klasse Cmmrp() . . . . . . . . . . . . . . . . . . . . . . 61
6.2 Zeigt den Beginn der Main-Dissector Funktion. Aus der Datei: packet-mrp-mmrp.c 65
6.3 Zeigt den Beginn der Message-Schleife im Dissector. . . . . . . . . . . . . . . . . 65
71
72 Listings
6.4 Zeigt die Schleife fur das VectorAttribute . . . . . . . . . . . . . . . . . . . . . . 66
Literaturverzeichnis
[1] 802, IEEE: IEEE 802 LAN/MAN Standards Committee. http://www.ieee802.org/,
2011. – Kopie ”LMSC, LAN MAN Standards Committee (Project 802).htm”
[2] Coe, James ; Ramirez, Gilbert: Wireshark developers HOWTO. http://anonsvn.
wireshark.org/wireshark/trunk/doc/README.developer, 2010. – Kopie ”READ-
ME.developer”
[3] IANA: IPv4 Multicast Address Space Registry. http://www.iana.org/assignments/
multicast-addresses/multicast-addresses.xml, Mai 2011. – Kopie ”multicast-
addresses.xml”
[4] IEEE: IEEE Std 802.1ak - IEEE Standard for Local and Metropolitan Area Networks:
Overview and Architecture. http://standards.ieee.org/about/get/802/802.html,
2002
[5] IEEE: IEEE Std 802.1ak - IEEE Standard for Local and metropolitan area networks
- Virtual Bridged Local Area Networks Amendment 7: Multiple Registration Protocol.
http://standards.ieee.org/about/get/802/802.1.html, 2004
[6] IEEE: IEEE Std 802.1D-2004 - IEEE Standard for Local and Metropolitan Area Networks:
Media Access Control (MAC) Bridges. http://standards.ieee.org/about/get/802/
802.1.html, 2004
[7] IEEE: IEEE P802.1Q-REV/D1.4 - Draft Standard for Local and Metropolitan Area
Networks – Media Access Control (MAC) Bridges and Virtual Bridged Local Area
Networks. http://www.ieee802.org/1/pages/802.1Q-rev.html, 2011
[8] Jochen, Johannes: Analyse des MMRP-Protokolls nach IEEE 802.3ak einschließlich Er-
stellung einer zustandsorientierten Simulation des Protokolls auf Basis von OMNeT++
sowie weiterer Tools fur Testzwecke. In: IT-Innovationen Band 7 (2011)
73
74 Literaturverzeichnis
[9] Maisch, Werner: Media Redundancy Protocol( MRP ). 2010. – Hirschmann Automation
and Control GmbH interne Pressentationsfolie
[10] Seifert, Rich ; Edwards, Jim: The all-new switch book: the complete guide to LAN
switching technology. Wiley, 2008. – ISBN 978–0–470–2815–6
[11] Stevens, W. R.: TCP/IP Illustrated, Volume 1: The Protocols. Addison-Wesley, 2005. –
ISBN 0–201–63346–9
[12] Varga, Andras: OMNeT++ User Manual; Version 4.1. http://www.omnetpp.org/
documentation, 2010. – Kopie ”Manuel Omnet.pdf”
[13] Wikipedia: Address Resolution Protocol. http://de.wikipedia.org/wiki/Address_
Resolution_Protocol, 2011. – Kopie ”Address Resolution Protocol.htm”
[14] Wikipedia: Address Resolution Protocol. http://de.wikipedia.org/wiki/
IP-Adresse, 2011. – Kopie ”IP-Adresse.htm”
[15] Wikipedia: Hirschmann GmbH. http://de.wikipedia.org/wiki/Hirschmann_GmbH,
2011. – Kopie ”Hirschmann GmbH.html”
[16] Wikipedia: IGMP snooping. http://en.wikipedia.org/wiki/IGMP_snooping, 2011. –
Kopie ”IGMP snooping.htm”
[17] Wikipedia: Media Redundancy Protocol. http://de.wikipedia.org/wiki/Media_
Redundancy_Protocol, 2011. – Kopie ”Media Redundancy Protocol.htm”
[18] Wikipedia: Spanning Tree Protocol. http://en.wikipedia.org/wiki/Spanning_Tree_
Protocol, 2011. – Kopie ”Spanning Tree Protocol.htm”