KNX/EIB ACK und Wiederholung beim IP-Router

[tbi]

Hallo,

mich plagt die Frage, ob ein IP-Router im KNX-Bus sich als Endgerät verhält oder nur als Gateway.

Fall A: Endgerät:

Beim Empfang (KNX -> IP) wird jede GA, die weitergeleitet wird, mit ACK bestätigt.
Beim Senden (IP -> KNX) wird der Empfang überwacht und wenn kein ACK zurückkommt, wird das Senden der GA wiederholt.

Fall B: Gateway:

Der IP Router verhält sich neutral und schickt keine ACK und Wiederholt auch nicht. Die Geräte in der IP-Welt schicken das ACK bei empfangenen GA und überwachen auch den Erhalt beim Empfänger. Wenn dann kein ACK vom Empfänger der GA (im KNX) zurückgeschickt wurde, schickt das IP-Gerät eine Wiederholung los.

Heute habe ich Fall A eingestellt. Es geht soweit. Die Frage ist, wie ist der KNX Standard definiert ??

Gruß Tbi

[makki]

AFAIK schickt der IP-Router aufs TP schon ein Ack. Aber leider unabhängig vom Erfolg der Weiterleitung (wie sollte er es bei Multicast und einer unbekannten Anzahl an Empfängern auch prüfen)
Ohne jetzt auszuscheifen: Fazit, im KNXnet/IP Routing gibts defakto keine wirksame Telegrammwiederholung, ein kleines Designproblem. Meine Meinung..

Makki

[tbi]

Hallo Makki,

ich habe im blauen Forum Antwort von kompetenter Stelle (KNX) erhalten.

Link: ACK und Wiederholung beim IP-Router - KNX-Professionals Deutschland e.V. Forum

Danach sollte der IP-Router für Packete die er aus dem KNX (TP) erhalten hat und selber weiterleitet, ein ACK in den KNX-Bus zurücksenden.

Wenn der IP-Router Packete von IP nach KNX sendet soll er auch den Erhalt auf der KNX Seite überwachen, also kontrollieren, ob der Empfänger ein ACK zurückgesendet hat. Wenn nicht, ggf. das "Telegram senden" wiederholen.

Das mit dem Multicast ist mir schon klar, dass das schwierig ist. Mir ging es zuerst einmal darum, was stellt man hier nach KNX eigentlich am besten ein. Die zweite Frage ist, warum man hier Parameter hat, die dann doch immer so eingestellt werden sollten.

Als einziges Szenario kann ich mir vorstellen, dass man zwei IP-Router als Linienkoppler verwendet und den Geräten in den Linien voll die Kontrolle überläßt, (ACK und Wiederholungen). Dann könnte man bei beiden IP-Routern ACK und Wiederholung ausschalten. Telegramme nach IP (an die Visu oder HS) würden dann aber nicht bestätigt werden.

Gruß Tbi

[meudenbach]

ja wie...

wie sollen die Geräte das denn selbst verwalten ??? Die Wiederholungen werden wenn dann immer vom Sender eingeleitet. Von IP ---> KNX kann das nun mal immer nur der Koppler sein.

Im übrigen generiert der Koppler das ACK auch nur, wenn die Filtertabelle aktiv ist, also geladen wurde.

Um dies zB zu übergehen gibt es dann zB entsprechende Einstellungen, die auch sinnvoll sind. Man kann denn Koppler zB auch dazu verwenden, dass er permanent ein -ACK generiert. Was ich zB bevorzuge... Hierbei lasse ich ihn allerdings auch nur einmal wiederholen. Sollte das nicht ausreichen herrschen andere Probleme in der Anlage.

Es ist auch wichtig zu wissen was man tut und entsprechend sind auch die korrekten Einstellungen zu wählen. Z.b. kann es sein, dass Statusobjekte nicht unbedingt mit anderen Teilnehmern verbunden sind und nur auf ein übergeordnetes System (Visu) aufschlagen. Hier kann es dann zu einer Häufung an Wiederholungen kommen, die dann auch Telegrammverluste hervorrufen. Ein entsprechend eingestellter Koppler beugt diesem vor.

Auf IP Seite verstehe ich auch nicht, warum man noch immer nicht von dem Multicast "Müll" Abstand genommen hat. Bei vielen IP Kopplern kann dann ganz schnell die gewünschte Bandbreite wieder in die Knie gehen, da ich mir ungemein "Overhead" und Telegrammverkehr aufbaue. Man denkt vermutlich noch an Infrastrukturen die mit "Hub's" aufgebaut wurden.

Hier wäre ein UDP Broadcast erheblich zielführender. eine "Weltenkopplung" dann entsprechend über einen TCP Tunnel....

LG

[tbi]

Hallo Mike

ja wie...

wie sollen die Geräte das denn selbst verwalten ??? Die Wiederholungen werden wenn dann immer vom Sender eingeleitet. Von IP ---> KNX kann das nun mal immer nur der Koppler sein.

Es hätte ja theoretisch sein können, das Das Gerät auf der IP Seite dies macht. Aber das ist ja nicht so. Das wissen wir ja nun.

Im übrigen generiert der Koppler das ACK auch nur, wenn die Filtertabelle aktiv ist, also geladen wurde.

Die Filtertabellen hast Du ja nur beim Betrieb als "Koppler" und nicht als "IP-Router" (also nur Schnittstelle). Bei mir ist er als Schnittstelle eingesetzt, also gibt es keine Filtertabellen. Damit ich programmieren kann, muß auch das ACK & Wiederholung gesetzt werden. Sonst hängt es sich auf.

Um dies zB zu übergehen gibt es dann zB entsprechende Einstellungen, die auch sinnvoll sind. Man kann denn Koppler zB auch dazu verwenden, dass er permanent ein -ACK generiert. Was ich zB bevorzuge... Hierbei lasse ich ihn allerdings auch nur einmal wiederholen. Sollte das nicht ausreichen herrschen andere Probleme in der Anlage.

Senden kann nur einer, empfangen ja viele. Dementsprechend können auch viele ACKs zurück zum Sender kommen. Wenn aber keins kommt, wird wiederholt gesenden. Das wird damit verhindert. Verstanden.

Es ist auch wichtig zu wissen was man tut und entsprechend sind auch die korrekten Einstellungen zu wählen. Z.b. kann es sein, dass Statusobjekte nicht unbedingt mit anderen Teilnehmern verbunden sind und nur auf ein übergeordnetes System (Visu) aufschlagen. Hier kann es dann zu einer Häufung an Wiederholungen kommen, die dann auch Telegrammverluste hervorrufen. Ein entsprechend eingestellter Koppler beugt diesem vor.

Dies ist eine Anwendung dieses Falls. Eine andere ist die Programmierung von Geräten. Diese erfordert ein ACK beim Gerät, sonst hängt es halt. Da ist ja sonst keiner der auf diese Telegramme sonst ein ACK senden würde.

Auf IP Seite verstehe ich auch nicht, warum man noch immer nicht von dem Multicast "Müll" Abstand genommen hat. Bei vielen IP Kopplern kann dann ganz schnell die gewünschte Bandbreite wieder in die Knie gehen, da ich mir ungemein "Overhead" und Telegrammverkehr aufbaue. Man denkt vermutlich noch an Infrastrukturen die mit "Hub's" aufgebaut wurden.

Ich glaube, dann hast Du was falsch gemacht.

Ein Router der IGMP kann schickt die IP Packete nur an die, die sich sich an die Multicast Adresse/port angemeldet haben. Router/Switches die nicht IGMP können, schicken die Packete an alle ports des Routers/Switches. So ist es jedenfalls bei meinem Switch. Da ist es wie ein Broadcast. Schlecht, aber beim EFH geht es.

Also ein professionelles Netz das mehrere IP-Router beinhaltet, sollte immer ein IGMP fähigiges IP Netz haben (Switches/Router).

Bei IGMP gibt es auch V1, V2 und V3. Soweit ich weiß ist das V3 am besten in der Effizienz.

Eine weitere Möglichkeit besteht darin, die IP-Router in verschiedene Multicastgruppen (IP/Port) aufzuteilen. Dann kann man den IP-Verkehr trennen. Das hängt aber stark davon ab, ob das in der Anlage möglich ist. Ist eine Zentrale Visu dran, muß sie ja alles "hören".

Hier wäre ein UDP Broadcast erheblich zielführender. eine "Weltenkopplung" dann entsprechend über einen TCP Tunnel....

Ein Tunnel ist immer Punkt zu Punkt. Wenn dann der HS dran hängt, kann ich nicht mehr programmieren. Nein, auf Multicast will ich nicht verzichten.

Viele Grüsse

Tbi

[meudenbach]

Also das kann ich so ganz nicht stehen lassen...

Die Filtertabellen hast Du ja nur beim Betrieb als "Koppler" und nicht als "IP-Router" (also nur Schnittstelle). Bei mir ist er als Schnittstelle eingesetzt, also gibt es keine Filtertabellen. Damit ich programmieren kann, muß auch das ACK & Wiederholung gesetzt werden. Sonst hängt es sich auf.

Betrieb als Koppler ist "Routing" !! In Funktion als "Schnittstelle" musst Du gar nix setzen. Bei der Programmierung befindest Du Dich auch auf einem ganz anderem Layer wie bei der Gruppenkommunikation...

Senden kann nur einer, empfangen ja viele. Dementsprechend können auch viele ACKs zurück zum Sender kommen

Falsch... es kann eigentlich immer nur ein -ACK kommen. Wäre auch schlimm, wenn es so wäre.

Dies ist eine Anwendung dieses Falls. Eine andere ist die Programmierung von Geräten....

Dann solltest Du mal klarstellen über welches Layer wir uns unterhalten sollen, evtl. hab ich ja auch was überlesen... das sind zwei völlig unterschiedliche Dinge...

Ich glaube, dann hast Du was falsch gemacht.

Glaube ich nicht ...

Man überlege... 200 IP Router im Netz über eine Multicast Gruppe und einem Zentralbefehl, oder umgekehrt wie zB. Wetterdaten, die in jede Linie übertragen werden müssen... Da mag IGMP hilfreich sein aber sicherlich nicht zielführend.

Ein Tunnel ist immer Punkt zu Punkt.

Natürlich ist er das.... Evtl. habe ich mich nicht deutlich ausgedrückt. Ich schrieb von UDP Broadcast. Die bekommst nicht über den Router, also keine "Weltenvernetzung". In diesem Zusammenhang brachte ich den "Tunnel" zu Sprache...

Ein Tunnel ist immer Punkt zu Punkt. Wenn dann der HS dran hängt, kann ich nicht mehr programmieren

Die Aussage verstehe ich gar nicht... der HS wird immer über ROUTING angebunden. Ergo, kannst Du immer noch einen Tunnel aufbauen... Und die ETS unterstützt auch beides, also wo ist das Problem ??

LG

[tbi]

Halo Mike,

ich setzte den IP-Router als Schnittstelle ein und dabei wird "IP-Routing" als Protokoll verwendet. Also mit Multicasting. x.y.z mit jeweils y,x,z UNGLEICH NULL. Also nicht als Koppler.

Da hängt die ETS und der HS dran.

Dann muß ich ACK und Wiederholung einstellen, sonst bricht die Programmierung ab.

Falsch... es kann eigentlich immer nur ein -ACK kommen. Wäre auch schlimm, wenn es so wäre.

Wie oft kommt das ACK dann im KNX-Bus. Nur das erste mal ? Es können doch viele die GA empfangen ? Wo ist mein Denkfehler ? Oder gibt es das ACK nur bei physikalischer Addressierung ?

Nachtrag: Ja, ein ACK oder NACK gibt es nur bei physikalischer Programmierung. Mit "immer NACK auf phys. Telegramme senden" kann man explizit die Programmierung damit unmöglich machen. siehe auch KNXGuard: http://www.bb-steuerungstechnik.de/cms/knxguard.html Der Verkehr der GAs ist davon nicht betroffen.
Wieder was gelernt

Die Aussage verstehe ich gar nicht... der HS wird immer über ROUTING angebunden. Ergo, kannst Du immer noch einen Tunnel aufbauen... Und die ETS unterstützt auch beides, also wo ist das Problem ??

Wenn der IP-Router auf "IP-Routing" prametriert ist, spricht er doch mit der IP Welt mit Multicasting z.B. mit dem HS. Wenn ich dann die ETS starte, kann ich doch nicht mit "IP-Tunneling" über diesen IP-Router programmieren, oder ? Der IP-Router kann doch nicht beides gleichzeitig, oder doch ?

Gruß Tbi

[swenga]

Hallo zusammen,

sehr interessantes Thema, muss auch mal meine 2cents zu loswerden....

Auf IP Seite verstehe ich auch nicht, warum man noch immer nicht von dem Multicast "Müll" Abstand genommen hat......Hier wäre ein UDP Broadcast erheblich zielführender. eine "Weltenkopplung" dann entsprechend über einen TCP Tunnel....

Also Multicast ist deutlich ausgereifter und bandbreitensparender als ein Broadcast (Speziell wenn IGMP-fähige Switche zum Einsatz kommen). Ausserdem kann Multicast auch Segmentübergreifend (also im Routing) eingesetzt werden, während ein Broadcast-Paket am Gateway aufhört. Das ist schon sehr schlank und durchaus ein geeigneter Kompromiss für Echtzeitdaten im Point-to-Multipoint-Verfahren. UDP-Broadcast-Daten über IP-Router drueberzuschauefeln geht nicht ohne entsprechende Vergewaltigung der Router....

Mein IP-Router (Weinzierl 750) unterstützt problemlos Filtertabellen, wenn die Filteroptionen auf "Filtern" stehen und keine Tabelle geladen, dann kommen da keine GA's drueber. Daher in der ETS im IP-Bereich ein Dummy-Device angelegt und schon werden die entsprechenden Filtertabellen erzeugt.

Filtertabellen haben (natuerlich und das ist auch gut so) jedoch keine Anwendung für das parallel vorhandene Tunneling-Interface.

Mein Vorschlag für die ACK-Problematik over IP (als Gedankenmodell): Da es ja nur um die Bestätigung für Geräte-adressierte Pakete geht, wäre es denkbar, im Router ein ACK over IP zu aktivieren für alle Geräte seines TP-Segmentes (Müsste er aus seiner KNX-Adresse ableiten können). Alle anderen IP-Router schweigen dann still, nur der zugehörige überträgt das ACK. Der sendende Router muss halt dann auch über IP das ACK-Processing/Resending implementieren.

mfg Swen

[meudenbach]

Evtl. etwas Begriffsduselei...

Ein IP Router, spricht bekanntlich beide Protokolle, also Routing und Tunneling. Wobei der Router natürlich auch Koppler ist, da eben das Routing Protokoll über Multicast zwingend dafür benötigt wird.

Ein IP Interface kann nur Tunneling, also keine Funktion als Koppler, aber eben programmieren oder Gruppenkommunikation.

Wenn Du also einen Router einsetzt als Schnittstelle kann die Verbindung über Routing oder Tunneling hergestellt werden. Und der Router könnte auch beides parallel. Einschränkung: natürlich nur eine Tunnelverbindung

In Deinem Fall stellt der HS eine Routing Verbindung zum IP Device her. Wenn Du zur Programmierung nun aber den HS verwendest benutzt Du weder Routing noch Tunneling, sondern den iETS Server des HS. Das ist wieder ganz was anderes...

Selbstverständlich kannst Du aber über die ETS auch den IP Router über den Tunnel ansprechen. Du hast ja entsprechende Auswahl im ETS Connection Manager. Da aber der HS, wie bereits erwähnt, sich über das Routing Protokoll verbindet, sollte/muss auch der Zugriff der ETS über KNXnet/IP Routing parallel möglich sein. Hierbei ist natürlich die "Schnittstellenadresse" der ETS wichtig, damit auch das richtige IP Device angesprochen werden kann und das "Ziel" gefunden wird.

Bei einem Tunnel hingegen wird das Device direkt angesprochen und stellt den Zugriff direkt auf der TP Seite zur Verfügung. Ob hierüber nun eine linienübergreifende Programmierung möglich wäre, also quasi zurück durch den Router und via Routing Protokoll in die nächste Linie..., dass müßte ich selbst mal testen...

Was Du offensichtlich verwechselst sind die "Betriebsarten" also Programmieren oder Kommunikation, die grundlegend verschieden sind. Beim Programmieren wird quasi eine Punkt zu Punkt Verbindung zum Teilnehmer aufgebaut wobei Sender und Empfänger eindeutig sind. Hier muss auch jedes Paket vom Empfänger bestätigt werden, bevor der Sender ein weiteres Paket auf die Reise schickt. Das kann/muss im Fall einer linienübergreifenden Programmierung dann auch ein Koppler sein.

Gruppenkommunikation ist quasi Broadcast, also einer sendet, alle hören.
Klar wollen alle Teilnehmer, die etwas empfangen haben, ein ACK senden und das tun sie auch... ABER.. nun muss man sich das Protokoll anschauen und wissen, wie es funktioniert. Das ACK wird innerhalb einer Linie nach Empfang quasi Zeitgleich auf dem BUS abgesetzt. Da es hierbei zu keiner Kollision kommt (alle Teilnehmer senden ja gleichen Wertinhalt), wurde das ACK für den Teilnehmer gesendet, der Clou... es wurde aber in Summe nur ein Telegramm generiert.

Sonst wäre ja auch die Hölle los auf dem Bus

Wenn der IP-Router auf "IP-Routing" prametriert ist, spricht er doch mit der IP Welt mit Multicasting z.B. mit dem HS.

Richtig... nur ist der HS quasi Client. Du sagst dem HS ja, wo er die Multicast Welt zu finden hat, die der Router zur Verfügung stellt. Und, wie vor beschrieben, wenn Du über den HS programmierst ist das wieder etwas anderes !!

kann ich doch nicht mit "IP-Tunneling" über diesen IP-Router programmieren, oder ?

aber sicher das... aber warum IP-Tunneling ?? Routing würde auch funktionieren, warum auch nicht ?!

Der IP-Router kann doch nicht beides gleichzeitig, oder doch ?

Doch, er kann !!

LG

[meudenbach]

@Swen

Also Multicast ist deutlich ausgereifter und bandbreitensparender als ein Broadcast (Speziell wenn IGMP-fähige Switche zum Einsatz kommen).

Ich will das nicht bestreiten.... bleib jedoch noch anderer Meinung. Mit IGMP Switchen habe ich noch keine Erfahrungen in entsprechenden Größenordnungen sammeln können... Wir betreiben IP Netze ja schon vor "Verfügbarkeit" genannter Geräte.

Mein Entwickler predigt mir das auch immer und schafft es doch so langsam, mich vom Gegenteil zu überzeugen.

Das BC Problem hinsichtlich Gateway's ist logisch, da haben wir aber andere Mittel ohne eben den Router zu vergewaltigen.... bzw. verwenden entsprechende Geräte.

LG

Mike