Aus RN-Wissen.de
Wechseln zu: Navigation, Suche
LiFePO4 Speicher Test

K
 
K (Siehe auch)
 
(8 dazwischenliegende Versionen von einem anderen Benutzer werden nicht angezeigt)
Zeile 1: Zeile 1:
''Hier entsteht eine Seite zur RNcom Schicht 1 - work in progress''
+
== RNcom Schicht 1 - Übersicht ==
{{Baustelle|Ragnar}}
+
 
+
== RNcom Schicht 1 - eine Übersicht ==
+
  
 
[[Bild:Layer1.gif]]
 
[[Bild:Layer1.gif]]
 +
  
 
=== Allgemeines ===
 
=== Allgemeines ===
  
 
Die Schicht 1 weis nichts mehr von der konkreten Hardware. Sie kennt nur noch eine Menge an
 
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'''
+
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
+
 
 +
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
 
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
 +
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.
  
'''Anmerkung:''' Aus Sicht der Schicht 1 haben die Devices keine eigene Adresse.
+
Nach oben virtualisiert die Schicht die konkreten Übertragungspfade und stellt einen zusammenhängenden
 +
Raum adressierbarer Knoten zur Verfügung.  
  
  
=== Eigenschaften von Segmenten ===
+
=== Statisches Routing ===
Die Segmente können wie folgt klassifiziert werden.
+
  
* Adressierbar/Broadcast only
+
Woher weis nun ein Router, wohin eine Nachricht weitergeleitet werden muss?
: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 Zuordnung von Adressen zu Devices/Segmenten kann '''statisch konfiguriert''' werden. Bestimmte Adressen
:Die Devices müssen dann selbst entscheiden, ob die Nachrichten für sie relevant sind. Ein Beispiel
+
werden also immer an bestimmte Segmente weitergeleitet. Besonders bei uCs dürfte dies der Standardfall
:hierfür sind Multicastgruppen.
+
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.
  
:Achtung: Wenn innerhalb desselben Transportmediums mehrere parallele Verbindungen (wie z.B. TCP-IP Streams)
+
Nachteile:
:existieren, die keinen gemeinsamen Broadcast teilen, dann sind diese Verbindungen auf Schicht 1
+
* nicht flexibel (Routing muß extra konfiguriert werden)
:verschiedene Segmente, obwohl sie physisch ein Kommunikationsmedium teilen.
+
* Falsche (überflüssige) Weiterleitung von Nachrichten
 
+
Vorteile:
* Device Listing
+
* einfach zu realisieren
:'''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 ===
 
=== Dynamisches Routing ===
  
Woher weis nun ein Router, wohin eine Nachricht weitergeleitet werden muss?
+
Beim dynamischen Routing 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
* Statische Konfiguration
+
über sie direkt(lokal) und indirekt(durch Weiterleitung) erreichbar sind. Bei Netzwerken mit
{|{{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
 
Kreisstrukturen muss zusätzlich die Entfernung zum Ziel übertragen werden damit der Router nach der
Verbindung mit dem kürzesten Weg suchen kann.
+
Verbindung mit dem kürzesten Weg suchen kann.  
|}
+
  
 
'''Beispiel:'''
 
'''Beispiel:'''
Zeile 85: Zeile 58:
 
  (2.2, 2.3)
 
  (2.2, 2.3)
 
  (2.1)
 
  (2.1)
 +
 +
'''Kernprobleme beim dynamischen Routing'''
 +
* 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?
 +
 +
* 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.
 +
 +
* Wie kann eine eventuell vorhandene Broadcastmöglichkeit auf dem Medium ausgenutzt werden?
 +
 +
'''Vorteile:'''
 +
* dynamisch, flexibel
 +
* effizientes Routing
  
  
Zeile 93: Zeile 79:
 
* Verwerfen: dem Absender wird die Ungültigkeit der Adresse nicht mitgeteilt.
 
* Verwerfen: dem Absender wird die Ungültigkeit der Adresse nicht mitgeteilt.
  
* Statusrückmeldung (Ack/Nack)
+
* 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.
{|{{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 ==
+
Nachdem dieselbe Funktionalität auch durch Schicht 2 erreicht werden kann, werden vorerst keine Acks auf Schicht 1 definiert.
  
Auf Schicht 2 können auch eventuelle "Application Server" aufsetzen. Sie übernehmen
+
 
die eigentliche Anbindung der Hardware und habe keine lokalen Knoten. Stattdessen
+
=== Application Server ===
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  
+
Auf Schicht 1 können auch eventuelle "Application Server" aufsetzen. Sie übernehmen die  
übernimmt und Clientprogramme bequem über ein einziges Kommunikationsprotokoll (auf
+
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 und gleichzeitig über ein einziges Kommunikationsprotokoll (auf
 
Schicht 0) auf das Netz zugreifen können.
 
Schicht 0) auf das Netz zugreifen können.
  
 +
=== Anmerkungen ===
 +
 +
* 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.
 +
 +
* 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]]
 +
 +
* 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.
 +
 +
* 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.
 +
 +
 +
=== Allgemeiner Nachrichtenaufbau: ===
 +
 +
Wie deutlich wurde sind die Routingmöglichkeiten innerhalb der Schicht 1 vielfältig. Aus diesem Grund kann
 +
der Nachrichtenaufbau der Schicht 1 nicht ohne weiteres komplett definiert werden. Stattdessen ist eine
 +
flexible Struktur notwendig, die nicht nur die Übertragung von Daten der Schicht 2 sondern auch von Nachrichten
 +
zwischen den verschiedenen Routern ermöglicht.
 +
<br/>
 +
 +
Allgemeines Format aller Nachrichten:
 +
 +
{| {{Blaueschmaltabelle}}
 +
| Length
 +
| Länge des Datenpaketes
 +
|}
 +
 +
{|{{Blaueschmaltabelle}}
 +
| Byte 1
 +
| Type
 +
| Der Typ der Nachricht.<br/>0..127 = Schicht 1 Nachricht<br/>128..255 = Schicht 2 Nachricht
 +
|-
 +
| Byte 2
 +
| rowspan=4 colspan=2 | Datenpaket, Format abhängig von Typ
 +
|-
 +
| Byte 3
 +
|-
 +
|  ...
 +
|-
 +
| Byte n
 +
|-
 +
|}
 +
<br/>
 +
Für die Nachrichtentypen 0..127 können nun Nachrichten spezifiert werden mit denen die Router direkt
 +
miteinander kommunizieren. Diese Nachrichten werden nur innerhalb der Segmente ausgetauscht und nicht
 +
geroutet. Sie richten sich immer direkt an ein Device oder ein Segment und können z.B. zum Austausch
 +
von dynamischen Routinginformationen genutzt werden.
 +
 +
Die Nachrichten vom Typ 128..255 werden an die Schicht 2 weitergeleitet und müssen geroutet werden.
 +
Deshalb wird für diese Nachrichten das Format um die Ziel- und Absenderadresse erweitert.
 +
 +
{| {{Blaueschmaltabelle}}
 +
| Length
 +
| Länge des Datenpaketes, evtl abzüglich der bereits <br/>definierten Headerbytes (implementierungsabhängig)
 +
|}
 +
 +
{|{{Blaueschmaltabelle}}
 +
| Byte 1
 +
| Type
 +
| 128..255 = Schicht 2 Nachricht
 +
|-
 +
| Byte 2
 +
| Dest Net
 +
| Netznummer des Empfängers
 +
|-
 +
| Byte 3
 +
| Dest Node
 +
| Knotennummer des Empfängers
 +
|-
 +
| Byte 4
 +
| Src Net
 +
| Netznummer des Absenders
 +
|-
 +
| Byte 5
 +
| Src Node
 +
| Knotennummer des Absenders
 +
|-
 +
| Byte 6
 +
| rowspan=3 colspan=2 | Nutzdaten für Schicht 2
 +
|-
 +
|  ...
 +
|-
 +
| Byte n
 +
|-
 +
|}
 +
 +
Die bereits festgelegten Headerbytes müssen nicht zwingend als Teil des Datenpaketes übergeben werden.
 +
Stattdessen können die bereits definierten Daten auch als Parameter übergeben werden. Dies ist abhängig von
 +
der Implementierung. Aus Gründen der Verständlichkeit werden die Daten hier immer als ganzes Paket dargestellt.
 +
 +
 +
==Siehe auch==
 +
 +
* [[RNcom Schicht 0]]
 +
** [[RNcom Schicht 0 UART Spezifikation]]
 +
** [[RNcom Schicht 0 TCP-IP Stream Spezifikation]]
 +
** [[RNcom Schicht 0 IP-Multicast Spezifikation]]
 +
 +
* RNcom Schicht 1
 +
** [[RNcom Schicht 1 Einfaches Dynamisches Routing]]
 +
 +
* [[RNcom Schicht 2]]
 +
 +
und auch:
 +
*[[Network Controller/PC]]
 +
*[[Network Controller/PC Schichten]]
 +
*[[Network Controller/PC Spezifikationen]]
  
 
==Autor==
 
==Autor==

Aktuelle Version vom 12. März 2006, 14:42 Uhr

RNcom Schicht 1 - Übersicht

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 und die über ein Segment erreichbaren Kommunikationspartner Devices genannt.

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. Segmente weiter. Ziel dabei ist es die Netzlast 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.

Nach oben virtualisiert die Schicht die konkreten Übertragungspfade und stellt einen zusammenhängenden Raum adressierbarer Knoten zur Verfügung.


Statisches Routing

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

Die Zuordnung von Adressen zu Devices/Segmenten kann statisch konfiguriert werden. 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.

Nachteile:

  • nicht flexibel (Routing muß extra konfiguriert werden)
  • Falsche (überflüssige) Weiterleitung von Nachrichten

Vorteile:

  • einfach zu realisieren


Dynamisches Routing

Beim dynamischen Routing 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)

Kernprobleme beim dynamischen Routing

  • Welche anderen Devices sind erreichbar?
    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?
    Wie werden diese Informationen übertragen?
    Wie werden sie erneuert?
    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.
  • Wie kann eine eventuell vorhandene Broadcastmöglichkeit auf dem Medium ausgenutzt werden?

Vorteile:

  • dynamisch, flexibel
  • effizientes Routing


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)
    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 (auf Schicht 1) tragen.

Nachdem dieselbe Funktionalität auch durch Schicht 2 erreicht werden kann, werden vorerst keine Acks auf Schicht 1 definiert.


Application Server

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 der Application Server die Verwaltung und Konfiguration der Hardware übernimmt und Clientprogramme bequem und gleichzeitig über ein einziges Kommunikationsprotokoll (auf Schicht 0) auf das Netz zugreifen können.

Anmerkungen

  • 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.
  • 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
  • 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.
  • DHCP / Enumeration
    Ein Dienst der einem anderen Device einen Adressbereich für seine lokalen Knoten zuweisen kann könnte auf dieser Schicht angesiedelt sein.


Allgemeiner Nachrichtenaufbau:

Wie deutlich wurde sind die Routingmöglichkeiten innerhalb der Schicht 1 vielfältig. Aus diesem Grund kann der Nachrichtenaufbau der Schicht 1 nicht ohne weiteres komplett definiert werden. Stattdessen ist eine flexible Struktur notwendig, die nicht nur die Übertragung von Daten der Schicht 2 sondern auch von Nachrichten zwischen den verschiedenen Routern ermöglicht.

Allgemeines Format aller Nachrichten:

Length Länge des Datenpaketes
Byte 1 Type Der Typ der Nachricht.
0..127 = Schicht 1 Nachricht
128..255 = Schicht 2 Nachricht
Byte 2 Datenpaket, Format abhängig von Typ
Byte 3
...
Byte n


Für die Nachrichtentypen 0..127 können nun Nachrichten spezifiert werden mit denen die Router direkt miteinander kommunizieren. Diese Nachrichten werden nur innerhalb der Segmente ausgetauscht und nicht geroutet. Sie richten sich immer direkt an ein Device oder ein Segment und können z.B. zum Austausch von dynamischen Routinginformationen genutzt werden.

Die Nachrichten vom Typ 128..255 werden an die Schicht 2 weitergeleitet und müssen geroutet werden. Deshalb wird für diese Nachrichten das Format um die Ziel- und Absenderadresse erweitert.

Length Länge des Datenpaketes, evtl abzüglich der bereits
definierten Headerbytes (implementierungsabhängig)
Byte 1 Type 128..255 = Schicht 2 Nachricht
Byte 2 Dest Net Netznummer des Empfängers
Byte 3 Dest Node Knotennummer des Empfängers
Byte 4 Src Net Netznummer des Absenders
Byte 5 Src Node Knotennummer des Absenders
Byte 6 Nutzdaten für Schicht 2
...
Byte n

Die bereits festgelegten Headerbytes müssen nicht zwingend als Teil des Datenpaketes übergeben werden. Stattdessen können die bereits definierten Daten auch als Parameter übergeben werden. Dies ist abhängig von der Implementierung. Aus Gründen der Verständlichkeit werden die Daten hier immer als ganzes Paket dargestellt.


Siehe auch

und auch:

Autor


LiFePO4 Speicher Test