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


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.


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.


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



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


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


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

Switch

Switch


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.


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.


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


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


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


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)


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



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



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


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


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



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.)



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


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)


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.


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.


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


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


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 {


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.


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


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


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,


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


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,


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 ] ;




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++;



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.


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++


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


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.


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.


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.

http://www.wireshark.org/docs/relnotes/wireshark-1.6.0.html

http://www.wireshark.org/docs/relnotes/wireshark-1.6.0.html


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 +


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 +


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

http://www.ieee802.org/

http://anonsvn.wireshark.org/wireshark/trunk/doc/README.developer

http://anonsvn.wireshark.org/wireshark/trunk/doc/README.developer

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml

http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml

http://standards.ieee.org/about/get/802/802.html

http://standards.ieee.org/about/get/802/802.1.html



http://www.ieee802.org/1/pages/802.1Q-rev.html

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”

http://www.omnetpp.org/documentation

http://www.omnetpp.org/documentation

http://de.wikipedia.org/wiki/Address_Resolution_Protocol

http://de.wikipedia.org/wiki/Address_Resolution_Protocol

http://de.wikipedia.org/wiki/IP-Adresse

http://de.wikipedia.org/wiki/IP-Adresse

http://de.wikipedia.org/wiki/Hirschmann_GmbH

http://en.wikipedia.org/wiki/IGMP_snooping

http://de.wikipedia.org/wiki/Media_Redundancy_Protocol

http://de.wikipedia.org/wiki/Media_Redundancy_Protocol

http://en.wikipedia.org/wiki/Spanning_Tree_Protocol

http://en.wikipedia.org/wiki/Spanning_Tree_Protocol

Documents

Bachelorthesis Analyse des MMRP-Protokolls nach IEEE 802