RNcom Schicht 1 - Versionsgeschichte

Ragnar_alt: /* Siehe auch */

2006-03-12T13:42:06Z

‎Siehe auch

Ragnar_alt am 11. März 2006 um 18:36 Uhr

2006-03-11T18:36:16Z

Ragnar_alt am 11. März 2006 um 12:23 Uhr

2006-03-11T12:23:50Z

Ragnar_alt am 10. März 2006 um 22:42 Uhr

2006-03-10T22:42:42Z

Ragnar_alt: /* Allgemeiner Nachrichtenaufbau: */

2006-03-10T22:42:17Z

‎Allgemeiner Nachrichtenaufbau:

Ragnar_alt: /* Application Server */

2006-03-10T22:41:28Z

‎Application Server

Ragnar_alt am 10. März 2006 um 22:37 Uhr

2006-03-10T22:37:06Z

Ragnar_alt am 10. März 2006 um 22:27 Uhr

2006-03-10T22:27:53Z

Änderungen zeigen

Ragnar_alt am 10. März 2006 um 21:25 Uhr

2006-03-10T21:25:18Z

Ragnar_alt am 9. März 2006 um 23:01 Uhr

2006-03-09T23:01:02Z

Neue Seite

''Hier entsteht eine Seite zur RNcom Schicht 1 - work in progress''
{{Baustelle|Ragnar}}

== RNcom Schicht 1 - eine Übersicht ==

[[Bild:Layer1.gif]]

=== Allgemeines ===

Die Schicht 1 weis nichts mehr von der konkreten Hardware. Sie kennt nur noch eine Menge an
Verbindungen die genutzt werden kann. Im folgenden werden diese Verbindungen '''Segmente'''
genannt und die über ein Segment erreichbaren Kommunikationspartner '''Devices'''. Hauptaufgabe
der Schicht 1 ist die Weiterleitung von Nachrichten über verschiedene Segmente hinweg. Dazu
nehmen die Router Nachrichten von den lokalen Knoten und den angeschlossenen Segmenten entgegen
und leiten diese an die relevanten lokalen Knoten bzw. Segment weiter.

'''Anmerkung:''' Aus Sicht der Schicht 1 haben die Devices keine eigene Adresse.

=== Eigenschaften von Segmenten ===
Die Segmente können wie folgt klassifiziert werden.

* Adressierbar/Broadcast only
:Bei '''Adressierbaren Verbindungen''' kann jedes an das Segment angeschlossene Device einzeln
:addressiert werden. Alle Devices haben eine '''gemeinsame Broadcastadresse'''. Ein Beispiel
:hierfür wäre eine Verbindung die auf Broadcasts im lokalen Netz aufbaut. Der Vorteil der
:Adressierung ist das nicht adressierte Knoten auch nicht belastet werden.

:Im Gegensatz dazu gibt es Segmente die ihre Nachrichten '''immer''' als '''Broadcast''' verschicken.
:Die Devices müssen dann selbst entscheiden, ob die Nachrichten für sie relevant sind. Ein Beispiel
:hierfür sind Multicastgruppen.

:Achtung: Wenn innerhalb desselben Transportmediums mehrere parallele Verbindungen (wie z.B. TCP-IP Streams)
:existieren, die keinen gemeinsamen Broadcast teilen, dann sind diese Verbindungen auf Schicht 1
:verschiedene Segmente, obwohl sie physisch ein Kommunikationsmedium teilen.

* Device Listing
:'''Achtung: Im folgenden geht es um andere Devices, nicht um die Adressen der angeschlossenen/erreichbaren Knoten.'''

:Wichtig für das Routing ist ausserdem, ob ein Router genau weis, welche anderen Router über eine
:Verbindung zu erreichen sind. Bei Punkt zu Punktverbindungen wie z.B. TCP-IP Streams oder serieller
:Kommunikation werden diese Informationen durch das Medium vorgegeben. Bei anderen Medien wie z.B.
:Multicastgruppen hat die Verbindung prinzipbedingt kein Wissen über die angeschlossenen Router.

Ob die Adressierbarkeit und die Kenntnis der Verbindungspartner durch das Medium selbst oder durch
das entsprechende Schicht 0 Protokoll gewährleistet wird ist für das Routing unerheblich.

Interessant werden diese Eigenschaften beim Dynamischen Routing. Ein dynamisches Routingprotokoll ist
wesentlich einfacher zu implementieren, wenn die erreichbaren Devices bekannt und adressierbar sind.

=== Dynamisches Routing ===

Woher weis nun ein Router, wohin eine Nachricht weitergeleitet werden muss?

* Statische Konfiguration
{|{{Blaueschmaltabelle}}
| Die Zuordnung von Adressen zu Devices/Segmenten wird statisch konfiguriert. Bestimmte Adressen werden
also immer an bestimmte Segmente weitergeleitet. Besonders bei uCs dürfte dies der Standardfall sein.
Hier kann das statische Routing auch problemlos angewendet werden, da neben den lokalen Knoten nur ein
Segment mit vmtl. einem Device existiert. Eine weitere einfache Möglichkeit der statischen Konfiguration
ist die Assoziation von Netzen und Devices bei der bestimmte Netze fest zu einem bestimmten Device
weitergeleitet werden.
|}

* Dynamische Konfiguration
{|{{Blaueschmaltabelle}}
| Bei der dynamischen Konfiguration kann ein Router zur Laufzeit bestimmen, welche Adressen über welche
Devices erreichbar sind. Dazu müssen ihm die direkt erreichbaren Router Auskunft geben können, welche
Adressen über sie direkt(lokal) und indirekt(durch Weiterleitung) erreichbar sind. Bei Netzwerken mit
Kreisstrukturen muss zusätzlich die Entfernung zum Ziel übertragen werden damit der Router nach der
Verbindung mit dem kürzesten Weg suchen kann.
|}

'''Beispiel:'''
Der "embedded Windows" Router in der Mitte des Beispielbildes hat 5 Segmente
mit insgesamt 8 Devices. Wenn er nun seine Devices nach ihren Routen befragt,
so erhält er als Antwort (von links oben im Uhrzeigersinn):
(1.1, 1.2)
(1.3)
(3.1)
(4.1, 4.2, 4.3)
(5.4, 5.5, 4.6)
(5.1, 5.2, 5.3)
(2.2, 2.3)
(2.1)

=== Acks und Nacks ===

Was macht ein Router wenn die Zieladresse nicht bekannt ist?

* Verwerfen: dem Absender wird die Ungültigkeit der Adresse nicht mitgeteilt.

* Statusrückmeldung (Ack/Nack)
{|{{Blaueschmaltabelle}}
| Der Absender erfährt, ob die Nachricht erfolgreich versendet oder
verworfen wurde. Problem: ''Diese Antwort muss der Absender geeignet
der eigentlichen Nachricht zuordnen können''. Die Nachricht sollte also
z.B. eine eindeutige Sequenznummer tragen.
|}

== Application Server ==

Auf Schicht 2 können auch eventuelle "Application Server" aufsetzen. Sie übernehmen
die eigentliche Anbindung der Hardware und habe keine lokalen Knoten. Stattdessen
stellen sie effiziente Anbindungsmöglichkeiten auf Schicht 0 zur Verfügung. Der Vorteil
dabei ist, das der Application Server die Verwaltung und Konfiguration der Hardware
übernimmt und Clientprogramme bequem über ein einziges Kommunikationsprotokoll (auf
Schicht 0) auf das Netz zugreifen können.

==Autor==

* [[Benutzer:Ragnar|Ragnar]]

[[Kategorie:Projekte]]
[[Kategorie:Software]]

@@ Zeile 188: / Zeile 188: @@
 ** [[RNcom Schicht 0 UART Spezifikation]]
 ** [[RNcom Schicht 0 TCP-IP Stream Spezifikation]]
 * RNcom Schicht 1
 ** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
 * [[RNcom Schicht 2]]
@@ Zeile 199: / Zeile 199: @@
 *[[Network Controller/PC Schichten]]
 *[[Network Controller/PC Spezifikationen]]
 ==Autor==

@@ Zeile 15: / Zeile 15: @@
 auf jedem Segment möglichst gering zu halten. Praktisch bedeutet dies, eine eingehende Nachricht (möglichst)
 nur an die Knoten weiterzuleiten, die wirklich zu den Empfängern dieser Nachricht gehören.
@@ Zeile 76: / Zeile 79: @@
 * Verwerfen: dem Absender wird die Ungültigkeit der Adresse nicht mitgeteilt.
-* Statusrückmeldung (Ack/Nack)<br/>Der Absender erfährt, ob die Nachricht erfolgreich versendet oder verworfen wurde. <br/> Problem: ''Diese Antwort muss der Absender geeignet der eigentlichen Nachricht zuordnen können''. Die Nachricht sollte also z.B. eine eindeutige Sequenznummer tragen.
+* Statusrückmeldung (Ack/Nack)<br/>Der Absender erfährt, ob die Nachricht erfolgreich versendet oder verworfen wurde. <br/> Problem: ''Diese Antwort muss der Absender geeignet der eigentlichen Nachricht zuordnen können''. Die Nachricht sollte also z.B. eine eindeutige Sequenznummer (auf Schicht 1) tragen.
@@ Zeile 165: / Zeile 170: @@
   |-
   | Byte 6
-  | rowspan=3 colspan=2 | Datenpaket, Format abhängig von Schicht 2
+  | rowspan=3 colspan=2 | Nutzdaten für Schicht 2
   |-
   |  ...

@@ Zeile 140: / Zeile 140: @@
 {| {{Blaueschmaltabelle}}
   | Length
-  | Länge des Datenpaketes
+  | Länge des Datenpaketes, evtl abzüglich der bereits <br/>definierten Headerbytes (implementierungsabhängig)
   |}
@@ Zeile 172: / Zeile 172: @@
   |-
   |}
 ==Siehe auch==
@@ Zeile 181: / Zeile 186: @@
 * RNcom Schicht 1
 ** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
 * [[RNcom Schicht 2]]

← Nächstältere Version		Version vom 10. März 2006, 22:42 Uhr
Zeile 1:		Zeile 1:
−	~~''Hier entsteht eine Seite zur RNcom Schicht 1 - work in progress''~~
−	~~{{Baustelle\|Ragnar}}~~
−
−
	== RNcom Schicht 1 - Übersicht ==		== RNcom Schicht 1 - Übersicht ==

@@ Zeile 110: / Zeile 110: @@
 zwischen den verschiedenen Routern ermöglicht.
 <br/>
 Allgemeines Format aller Nachrichten:
@@ Zeile 175: / Zeile 176: @@
   |-
   |}
 ==Siehe auch==

@@ Zeile 85: / Zeile 85: @@
 === Application Server ===
-Auf Schicht 2 können auch eventuelle "Application Server" aufsetzen. Sie übernehmen die
+Auf Schicht 1 können auch eventuelle "Application Server" aufsetzen. Sie übernehmen die
 eigentliche Anbindung der Hardware und habe keine lokalen Knoten. Stattdessen stellen sie
 effiziente Anbindungsmöglichkeiten auf Schicht 0 zur Verfügung. Der Vorteil dabei ist, das
@@ Zeile 91: / Zeile 91: @@
 Clientprogramme bequem und gleichzeitig über ein einziges Kommunikationsprotokoll (auf
 Schicht 0) auf das Netz zugreifen können.
 === Anmerkungen ===

@@ Zeile 63: / Zeile 63: @@
 * Welche anderen Devices sind erreichbar? <br/> Diese Frage mag trivial erscheinen, bei einigen Medien wie z.B. Multicastgruppen ist sie jedoch nicht zu beantworten. In diesem Fall weis der Router nicht vorab, welche anderen Devices existieren. Entsprechend schwierig ist es, diese Devices gezielt zu ihrer Routingtabelle zu befragen.
-* Welche Adressen sind über ein bestimmtes Device verfügbar? <br/> Wie werden diese Informationen übertragen? <br/> Wie werden sie erneuert? </br> Was passiert wenn das Device ausfällt oder abgesteckt wird?
+* Welche Adressen sind über ein bestimmtes Device verfügbar? <br/> Wie werden diese Informationen übertragen? <br/> Wie werden sie erneuert? <br/> Was passiert wenn das Device ausfällt oder abgesteckt wird?
 * Je nach Art und Menge der Adressen kann die Routingtabelle ziemlich groß werden. Große Routingtabelle verbrauchen nicht nur unerheblichen Speicherplatz, sie sind auch sehr schwer zu übertragen.
@@ Zeile 83: / Zeile 83: @@
-=== Anmerkungen ===
+=== Application Server ===
-* Wenn innerhalb desselben Transportmediums mehrere parallele Verbindungen (wie z.B. TCP-IP Streams) existieren, die keinen gemeinsamen Broadcast teilen, dann sind diese Verbindungen auf Schicht 1 verschiedene Segmente, obwohl sie physisch ein Kommunikationsmedium teilen.
+Auf Schicht 2 können auch eventuelle "Application Server" aufsetzen. Sie übernehmen die
 * Aus Sicht der Schicht 1 haben die Devices keine eigene Adresse, nur die lokal angeschlossenen Knoten sind adressierbar. Die Devices sind also die "Netzinfrastruktur" während die (adressierbaren) Knoten die Teilnehmer sind.
-* '''Application Server'''<br/> Auf Schicht 2 können auch eventuelle "Application Server" aufsetzen. Sie übernehmen die  eigentliche Anbindung der Hardware und habe keine lokalen Knoten. Stattdessen stellen sie effiziente Anbindungsmöglichkeiten auf Schicht 0 zur Verfügung. Der Vorteil dabei ist, das der Application Server die Verwaltung und Konfiguration der Hardware übernimmt und Clientprogramme bequem über ein einziges Kommunikationsprotokoll (auf Schicht 0) auf das Netz zugreifen können.
+* Die Adressen der Knoten müssen die Netzwerktopologie nicht zwingend wiederspiegeln. Theoretisch können die Adressen rein zufällig verteilt sein. Um ein effizientes Routing zu ermöglichen, können hier jedoch Einschränkungen getroffen werden. Siehe dazu auch: [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
-* DHCP / Enumeration<br/> Ein Dienst der einem anderen Device einen Adressbereich für seine lokalen Knoten zuweisen kann.
+* DHCP / Enumeration<br/> Ein Dienst der einem anderen Device einen Adressbereich für seine lokalen Knoten zuweisen kann könnte auf dieser Schicht angesiedelt sein.

@@ Zeile 2: / Zeile 2: @@
 {{Baustelle|Ragnar}}
-== RNcom Schicht 1 - eine Übersicht ==
 [[Bild:Layer1.gif]]
 === Allgemeines ===
 Die Schicht 1 weis nichts mehr von der konkreten Hardware. Sie kennt nur noch eine Menge an
 Verbindungen die genutzt werden kann. Im folgenden werden diese Verbindungen '''Segmente'''
-genannt und die über ein Segment erreichbaren Kommunikationspartner '''Devices'''. Hauptaufgabe
+und die über ein Segment erreichbaren Kommunikationspartner '''Devices''' genannt.
 der Schicht 1 ist die Weiterleitung von Nachrichten über verschiedene Segmente hinweg. Dazu
 nehmen die Router Nachrichten von den lokalen Knoten und den angeschlossenen Segmenten entgegen
-und leiten diese an die relevanten lokalen Knoten bzw. Segment weiter.
+und leiten diese an die relevanten lokalen Knoten bzw. Segmente weiter. Ziel dabei ist es die Netzlast
-'''Anmerkung:''' Aus Sicht der Schicht 1 haben die Devices keine eigene Adresse.
+{|{{Blaueschmaltabelle}}
-=== Eigenschaften von Segmenten ===
+Woher weis nun ein Router, wohin eine Nachricht weitergeleitet werden muss?
-Die Segmente können wie folgt klassifiziert werden.
+=== Statisches Routing ===
-* Adressierbar/Broadcast only
+Nachteile:
-:Bei '''Adressierbaren Verbindungen''' kann jedes an das Segment angeschlossene Device einzeln
+* nicht flexibel (Routing muß extra konfiguriert werden)
-:addressiert werden. Alle Devices haben eine '''gemeinsame Broadcastadresse'''. Ein Beispiel
+* Falsche (überflüssige) Weiterleitung von Nachrichten
-:hierfür wäre eine Verbindung die auf Broadcasts im lokalen Netz aufbaut. Der Vorteil der
+Vorteile:
-:Adressierung ist das nicht adressierte Knoten auch nicht belastet werden.
+* einfach zu realisieren
-:Im Gegensatz dazu gibt es Segmente die ihre Nachrichten '''immer''' als '''Broadcast''' verschicken.
+=== Dynamisches Routing ===
-:Die Devices müssen dann selbst entscheiden, ob die Nachrichten für sie relevant sind. Ein Beispiel
-:hierfür sind Multicastgruppen.
+Beim dynamischen Routing kann ein Router zur Laufzeit bestimmen, welche Adressen über welche Devices
-:Achtung: Wenn innerhalb desselben Transportmediums mehrere parallele Verbindungen (wie z.B. TCP-IP Streams)
+* Adressierbar/Broadcast only<br/>Bei '''Adressierbaren Verbindungen''' kann jedes an das Segment angeschlossene Device einzeln addressiert werden. Alle Devices haben eine '''gemeinsame Broadcastadresse'''. Ein Beispiel hierfür wäre eine Verbindung die auf Broadcasts im lokalen Netz aufbaut. Der Vorteil der Adressierung ist das nicht adressierte Knoten auch nicht belastet werden.<br/><br/>Im Gegensatz dazu gibt es Segmente die ihre Nachrichten '''immer''' als '''Broadcast''' verschicken. Die Devices müssen dann selbst entscheiden, ob die Nachrichten für sie relevant sind. Ein Beispiel hierfür sind Multicastgruppen.<br/><br/>Achtung: Wenn innerhalb desselben Transportmediums mehrere parallele Verbindungen (wie z.B. TCP-IP Streams) existieren, die keinen gemeinsamen Broadcast teilen, dann sind diese Verbindungen auf Schicht 1 verschiedene Segmente, obwohl sie physisch ein Kommunikationsmedium teilen.
-:existieren, die keinen gemeinsamen Broadcast teilen, dann sind diese Verbindungen auf Schicht 1
-:verschiedene Segmente, obwohl sie physisch ein Kommunikationsmedium teilen.
 * Device Listing
@@ Zeile 50: / Zeile 84: @@
@@ Zeile 109: / Zeile 108: @@
 übernimmt und Clientprogramme bequem über ein einziges Kommunikationsprotokoll (auf
 Schicht 0) auf das Netz zugreifen können.