Ethernet/Flow Control: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen VersionsunterschiedZum nächsten Versionsunterschied →
VisuellWikitext
Keine Bearbeitungszusammenfassung
Zeile 1: Zeile 1:
'''topic''' - Kurzbeschreibung
'''topic''' - Kurzbeschreibung
Technik zur Unterbrechung der Übertragung, um Staus zu vermeiden
== Beschreibung ==
== Beschreibung ==
[[Datei:EthernetPauseFrame.jpg|right|thumb|Wireshark Screenshot eines Ethernet "Pause" Frames|500px]]
'''Ethernet Flow Control''' ist ein Mechanismus zur vorübergehenden Unterbrechung der Datenübertragung in [[Ethernet]]-Familien [[Computernetzwerke]]n. Ziel dieses Mechanismus ist es, [[Paketverluste]] bei einer [[Netzwerküberlastung]] zu vermeiden.
Der erste Flusskontrollmechanismus, der '''Pausenrahmen''', wurde durch die Norm '''IEEE 802.3x''' definiert. Die nachfolgende '''prioritätsbasierte Flusskontrolle''', die im '''IEEE 802.1Qbb'''-Standard definiert ist, bietet einen Flusskontrollmechanismus auf Verbindungsebene, der unabhängig für jede [[Dienstklasse]] (CoS) gesteuert werden kann, wie von [[IEEE P802.1p]] definiert, und ist für [[Data Center Bridging]]-Netzwerke (DCB) anwendbar und ermöglicht die Priorisierung von Voice-over-IP (VoIP), Video-over-IP und Datenbanksynchronisierungsverkehr gegenüber Standarddatenverkehr und Massendatentransfers.
==Beschreibung==
Eine sendende Station (Computer oder [[Netzwerk-Switch]]) überträgt möglicherweise Daten schneller, als das andere Ende der Verbindung sie annehmen kann. Mit Hilfe der [[Flusskontrolle (Daten)|Flusskontrolle]] kann die empfangende Station dem Sender signalisieren, dass die Übertragungen unterbrochen werden sollen, bis der Empfänger aufholt. Die Flusskontrolle bei Ethernet kann auf der [[Datenübertragungsschicht]] implementiert werden.
Der erste Flusskontrollmechanismus, der ''Pausenrahmen'', wurde von der Arbeitsgruppe des [[Institute of Electrical and Electronics Engineers]] (IEEE) definiert, die die [[Vollduplex]]-Segmente Ethernet-Verbindungssegmente definierte. Der IEEE-Standard 802.3x wurde 1997 veröffentlicht.<ref name="ieeexplore.ieee.org">{{cite book |title= IEEE Standards for Local and Metropolitan Area Networks: Supplements to Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Specification for 802.3 Full Duplex Operation and Physical Layer Specification for 100 Mb/s Operation on Two Pairs of Category 3 Or Better Balanced Twisted Pair Cable (100BASE-T2) |year= 1997 |publisher= [[Institute of Electrical and Electronics Engineers]] |isbn= 978-1-55937-905-2 |doi=10.1109/IEEESTD.1997.95611 |url= http://ieeexplore.ieee.org/servlet/opac?punumber=9536 }}</ref>
===Pause frame===
Ein überlasteter Netzknoten kann einen Pausenrahmen senden, der die Übertragung des Senders für eine bestimmte Zeitspanne unterbricht. Ein [[Media Access Control]] (MAC) [[Ethernet-Frame|frame]] ([[EtherType]] 0x8808) wird verwendet, um den Pause-Befehl zu übertragen, wobei der Control Opcode auf 0x0001 ([[hexadezimal]]) gesetzt ist.<ref name="ieeexplore.ieee.org"/> Nur Stationen, die für Vollduplex-Betrieb konfiguriert sind, können PAUSE-Frames senden. Wenn eine Station das andere Ende einer Verbindung anhalten möchte, sendet sie einen Pausenrahmen entweder an die eindeutige 48-[[Bit]]-Zieladresse dieser Verbindung oder an die reservierte 48-Bit-[[Multicast-Adresse]] von {{no wrap|01-80-C2-00-00-01}}.<ref name="802.3-2018">{{Cite book
| url = https://ieeexplore.ieee.org/servlet/opac?punumber=8457467
| title = IEEE Std 802.3-2018 - IEEE Standard für Ethernet
| date = 2018-08-31 | access-date = 2022-11-29
| publisher = IEEE Standards Association | website = ieee.org
| format = PDF | doi=10.1109/IEEESTD.2018.8457469
| isbn = 978-1-5044-5090-4
}}</ref>{{rp|Anhang 31B.3.3}} Die Verwendung einer bekannten Adresse macht es für eine Station unnötig, die Adresse der Station am anderen Ende der Verbindung zu ermitteln und zu speichern.
Ein weiterer Vorteil der Verwendung dieser Multicast-Adresse ergibt sich aus der Verwendung der Flusskontrolle zwischen Netzwerk-Switches. Die verwendete Multicast-Adresse wird aus einer Reihe von Adressen ausgewählt, die durch den [[IEEE 802.1D]]-Standard reserviert wurden, der den Betrieb von Switches für [[Bridging (Networking)|Bridging]] spezifiziert. Normalerweise wird ein an einen Switch gesendeter Rahmen mit einem Multicast-Ziel an alle anderen Ports des Switches weitergeleitet. Dieser Bereich von Multicast-Adressen ist jedoch speziell und wird von einem 802.1D-kompatiblen Switch nicht weitergeleitet. Stattdessen werden Frames, die an diesen Bereich gesendet werden, als Frames verstanden, die nur innerhalb des Switches bearbeitet werden sollen.
Ein Pausenrahmen enthält die angeforderte Pausenzeit in Form einer vorzeichenlosen [[Ganzzahl]] mit zwei [[Byte]] (16 Bit) (0 bis 65535). Diese Zahl ist die angeforderte Dauer der Pause. Die Pausenzeit wird in Einheiten von Pausen-"Quanten" gemessen, wobei jede Einheit 512 [[Bitzeit]]en entspricht.
Bis 1999 unterstützten mehrere Anbieter den Empfang von Pausenrahmen, aber nur wenige den Versand.<ref>{{Cite news |title= Switch Vendors pass interoperability tests |work= Network World |date= September 13, 1999 |pages= 81-82 |author1= Ann Sullivan |author2= Greg Kilmartin |author3= Scott Hamilton |url= https://books.google.com/books? id=0Q4EAAAAMBAJ&pg=PA82 |access-date= 10. Mai 2011}}</ref><ref name="vendor99">{{Cite news |title= Hersteller zur Flusskontrolle |work= Network World Fusion |date= 13. September 1999 |url= http://www.networkworld.com/netresources/0913flow2.html |archive-url=https://web.archive.org/web/20120207133926/http://www.networkworld.com/netresources/0913flow2.html |archive-date=2012-02-07}} Kommentare der Hersteller zur Flusskontrolle im Test von 1999.</ref>
===Probleme===
Eine ursprüngliche Motivation für den Pausenrahmen war der Umgang mit [[Netzwerkschnittstellen-Controller]]n (NICs), die nicht über genügend Puffer für den Empfang mit voller Geschwindigkeit verfügten. Mit den Fortschritten bei den Busgeschwindigkeiten und Speichergrößen ist dieses Problem nicht mehr so häufig. Ein wahrscheinlicheres Szenario ist eine [[Netzwerküberlastung]] innerhalb eines Switches. Beispielsweise kann ein Datenstrom über einen Link mit höherer Geschwindigkeit in einen Switch eintreten, als er ihn verlässt, oder es können mehrere Datenströme über zwei oder mehr Links eintreten, die insgesamt die Bandbreite eines Ausgangslinks übersteigen. In diesen Fällen ist der Puffer des Switches irgendwann erschöpft. Die Blockierung des sendenden Links führt jedoch dazu, dass alle Ströme über diesen Link verzögert werden, auch diejenigen, die keine Überlastung verursachen. Diese Situation ist ein Fall von [[Head-of-Line-Blocking]] (HOL) und kann in [[Kernnetz]]-Switches aufgrund der großen Anzahl von Flüssen, die im Allgemeinen aggregiert werden, häufiger auftreten. Viele Switches verwenden eine Technik namens [[virtuelle Ausgangswarteschlangen|virtuelle Ausgangswarteschlangen]], um die HOL-Blockierung intern zu beseitigen, so dass niemals Pausenrahmen gesendet werden.<ref name="vendor99"/>
==Nachfolgende Bemühungen==
===Überlastungsmanagement===
Eine weitere Anstrengung begann im März 2004, und im Mai 2004 wurde daraus die IEEE P802.3ar Congestion Management Task Force. Im Mai 2006 wurden die Ziele der Task Force überarbeitet, um einen Mechanismus zur Begrenzung der übertragenen Datenrate mit einer Granularität von etwa 1 % zu spezifizieren. Der Antrag wurde zurückgezogen und die Task Force wurde 2008 aufgelöst.<ref>{{cite web |title= IEEE P802.3ar Congestion Management Task Force |date= December 18, 2008 |url= http://grouper.ieee.org/groups/802/3/ar/ |access-date= May 10, 2011 }}</ref>
===Prioritätsflusskontrolle===
Die Ethernet-Flusskontrolle stört die Ethernet-Dienstklasse (definiert in [[IEEE 802.1p]]), da die Daten aller Prioritäten angehalten werden, um die vorhandenen Puffer zu leeren, die auch aus Daten niedriger Priorität bestehen können. Um dieses Problem zu lösen, hat [[Cisco Systems]] eine eigene Erweiterung des Standardprotokolls zur Prioritätsflusskontrolle definiert. Dieser Mechanismus verwendet 14 Byte der 42-Byte-Polsterung in einem normalen Pausenrahmen. Der MAC-Kontroll-Opcode für einen Prioritäts-Pausenrahmen ist 0x0101. Anders als bei der ursprünglichen Pause wird bei der Prioritätspause die Pausenzeit in Quanten für jede der acht Prioritätsklassen separat angegeben.<ref>{{cite web |title= Priority Flow Control: Build Reliable Layer 2 Infrastructure |publisher= Cisco Systems |work= White Paper |date= June 2009 |url= http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-542809.pdf |access-date= May 10, 2011 }}</ref> Die Erweiterung wurde anschließend vom Projekt Priority-based Flow Control (PFC) standardisiert, das am 27. März 2008 als IEEE 802.1Qbb genehmigt wurde.<ref>[http://www.ieee802.org/1/pages/802.1bb.html IEEE 802.1Qbb]</ref> Draft 2.3 wurde am 7. Juni 2010 vorgeschlagen. Claudio DeSanti von Cisco war Herausgeber.<ref>{{cite web |title= IEEE 802.1Q Priority-based Flow Control |publisher= Institute of Electrical and Electronics Engineers |date= June 7, 2010 |url= http://www.ieee802.org/1/pages/802.1bb. html |access-date= May 10, 2011 }}</ref> Das Projekt war Teil der [[Data Center Bridging]]-Task Group, die [[Fibre Channel over Ethernet]] entwickelte.<ref>{{cite web |title= Data Center Bridging Task Group |publisher= Institute of Electrical and Electronics Engineers |date= June 7, 2010 |url= http://www.ieee802.org/1/pages/dcbridges.html |access-date= May 10, 2011 }}</ref>
== Installation ==
== Installation ==
== Anwendungen ==
== Anwendungen ==
Zeile 14: Zeile 55:


== Siehe auch ==
== Siehe auch ==
# [[Explicit Congestion Notification]]
=== Dokumentation ===
=== Dokumentation ===
==== RFC ====
==== RFC ====
Zeile 21: Zeile 64:
==== Einzelnachweise ====
==== Einzelnachweise ====
<references />
<references />
==== Projekt ====
==== Projekt ====
==== Weblinks ====
==== Weblinks ====
==External links==
# {{Cite web |title=Ethernet Media Access Control - PAUSE Frames |work=TechFest Ethernet Technical Summary |year= 1999 |url=http://www.techfest.com/networking/lan/ethernet3.htm#3.2.1 |access-date=May 10, 2011 |archive-url=https://web.archive.org/web/20120204103034/http://www.techfest.com/networking/lan/ethernet3.htm |archive-date=February 2012}}
# {{cite web |title= When Flow Control is not a Good Thing |date= November 7, 2007  |author= Tim Higgins |work= Small Net Builder |url= https://www.smallnetbuilder.com/lanwan/lanwan-features/30212-when-flow-control-is-not-a-good-thing |access-date= January 6, 2020}}
# [http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/#flow-ctrl Linux Tool for generating flow control PAUSE frames]
# [https://github.com/archjeb/pfctest Python Tool to Generate PFC Frames]
# {{Cite journal |title=Ethernet Flow Control |journal=Topics in High-Performance Messaging |url=http://www.29west.com/docs/THPM/thpm.html#ETHERNET-FLOW-CONTROL |archive-url=https://web.archive.org/web/20071208094516/http://www.29west.com/docs/THPM/thpm.html#ETHERNET-FLOW-CONTROL |archive-date=2007-12-08 }}


== Testfragen ==
== Testfragen ==
Zeile 45: Zeile 95:
<div class="mw-collapsible-content">'''Antwort5'''</div>
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>
</div>
= Wikipedia =
[[Datei:EthernetPauseFrame.jpg|right|thumb|Wireshark Screenshot eines Ethernet "Pause" Frames|500px]]
'''Ethernet Flow Control''' ist ein Mechanismus zur vorübergehenden Unterbrechung der Datenübertragung in [[Ethernet]]-Familien [[Computernetzwerke]]n. Ziel dieses Mechanismus ist es, [[Paketverluste]] bei einer [[Netzwerküberlastung]] zu vermeiden.
Der erste Flusskontrollmechanismus, der '''Pausenrahmen''', wurde durch die Norm '''IEEE 802.3x''' definiert. Die nachfolgende '''prioritätsbasierte Flusskontrolle''', die im '''IEEE 802.1Qbb'''-Standard definiert ist, bietet einen Flusskontrollmechanismus auf Verbindungsebene, der unabhängig für jede [[Dienstklasse]] (CoS) gesteuert werden kann, wie von [[IEEE P802.1p]] definiert, und ist für [[Data Center Bridging]]-Netzwerke (DCB) anwendbar und ermöglicht die Priorisierung von Voice-over-IP (VoIP), Video-over-IP und Datenbanksynchronisierungsverkehr gegenüber Standarddatenverkehr und Massendatentransfers.
==Beschreibung==
Eine sendende Station (Computer oder [[Netzwerk-Switch]]) überträgt möglicherweise Daten schneller, als das andere Ende der Verbindung sie annehmen kann. Mit Hilfe der [[Flusskontrolle (Daten)|Flusskontrolle]] kann die empfangende Station dem Sender signalisieren, dass die Übertragungen unterbrochen werden sollen, bis der Empfänger aufholt. Die Flusskontrolle bei Ethernet kann auf der [[Datenübertragungsschicht]] implementiert werden.
Der erste Flusskontrollmechanismus, der ''Pausenrahmen'', wurde von der Arbeitsgruppe des [[Institute of Electrical and Electronics Engineers]] (IEEE) definiert, die die [[Vollduplex]]-Segmente Ethernet-Verbindungssegmente definierte. Der IEEE-Standard 802.3x wurde 1997 veröffentlicht.<ref name="ieeexplore.ieee.org">{{cite book |title= IEEE Standards for Local and Metropolitan Area Networks: Supplements to Carrier Sense Multiple Access With Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications - Specification for 802.3 Full Duplex Operation and Physical Layer Specification for 100 Mb/s Operation on Two Pairs of Category 3 Or Better Balanced Twisted Pair Cable (100BASE-T2) |year= 1997 |publisher= [[Institute of Electrical and Electronics Engineers]] |isbn= 978-1-55937-905-2 |doi=10.1109/IEEESTD.1997.95611 |url= http://ieeexplore.ieee.org/servlet/opac?punumber=9536 }}</ref>
===Pause frame===
Ein überlasteter Netzknoten kann einen Pausenrahmen senden, der die Übertragung des Senders für eine bestimmte Zeitspanne unterbricht. Ein [[Media Access Control]] (MAC) [[Ethernet-Frame|frame]] ([[EtherType]] 0x8808) wird verwendet, um den Pause-Befehl zu übertragen, wobei der Control Opcode auf 0x0001 ([[hexadezimal]]) gesetzt ist.<ref name="ieeexplore.ieee.org"/> Nur Stationen, die für Vollduplex-Betrieb konfiguriert sind, können PAUSE-Frames senden. Wenn eine Station das andere Ende einer Verbindung anhalten möchte, sendet sie einen Pausenrahmen entweder an die eindeutige 48-[[Bit]]-Zieladresse dieser Verbindung oder an die reservierte 48-Bit-[[Multicast-Adresse]] von {{no wrap|01-80-C2-00-00-01}}.<ref name="802.3-2018">{{Cite book
| url = https://ieeexplore.ieee.org/servlet/opac?punumber=8457467
| title = IEEE Std 802.3-2018 - IEEE Standard für Ethernet
| date = 2018-08-31 | access-date = 2022-11-29
| publisher = IEEE Standards Association | website = ieee.org
| format = PDF | doi=10.1109/IEEESTD.2018.8457469
| isbn = 978-1-5044-5090-4
}}</ref>{{rp|Anhang 31B.3.3}} Die Verwendung einer bekannten Adresse macht es für eine Station unnötig, die Adresse der Station am anderen Ende der Verbindung zu ermitteln und zu speichern.
Ein weiterer Vorteil der Verwendung dieser Multicast-Adresse ergibt sich aus der Verwendung der Flusskontrolle zwischen Netzwerk-Switches. Die verwendete Multicast-Adresse wird aus einer Reihe von Adressen ausgewählt, die durch den [[IEEE 802.1D]]-Standard reserviert wurden, der den Betrieb von Switches für [[Bridging (Networking)|Bridging]] spezifiziert. Normalerweise wird ein an einen Switch gesendeter Rahmen mit einem Multicast-Ziel an alle anderen Ports des Switches weitergeleitet. Dieser Bereich von Multicast-Adressen ist jedoch speziell und wird von einem 802.1D-kompatiblen Switch nicht weitergeleitet. Stattdessen werden Frames, die an diesen Bereich gesendet werden, als Frames verstanden, die nur innerhalb des Switches bearbeitet werden sollen.
Ein Pausenrahmen enthält die angeforderte Pausenzeit in Form einer vorzeichenlosen [[Ganzzahl]] mit zwei [[Byte]] (16 Bit) (0 bis 65535). Diese Zahl ist die angeforderte Dauer der Pause. Die Pausenzeit wird in Einheiten von Pausen-"Quanten" gemessen, wobei jede Einheit 512 [[Bitzeit]]en entspricht.
Bis 1999 unterstützten mehrere Anbieter den Empfang von Pausenrahmen, aber nur wenige den Versand.<ref>{{Cite news |title= Switch Vendors pass interoperability tests |work= Network World |date= September 13, 1999 |pages= 81-82 |author1= Ann Sullivan |author2= Greg Kilmartin |author3= Scott Hamilton |url= https://books.google.com/books? id=0Q4EAAAAMBAJ&pg=PA82 |access-date= 10. Mai 2011}}</ref><ref name="vendor99">{{Cite news |title= Hersteller zur Flusskontrolle |work= Network World Fusion |date= 13. September 1999 |url= http://www.networkworld.com/netresources/0913flow2.html |archive-url=https://web.archive.org/web/20120207133926/http://www.networkworld.com/netresources/0913flow2.html |archive-date=2012-02-07}} Kommentare der Hersteller zur Flusskontrolle im Test von 1999.</ref>
===Probleme===
Eine ursprüngliche Motivation für den Pausenrahmen war der Umgang mit [[Netzwerkschnittstellen-Controller]]n (NICs), die nicht über genügend Puffer für den Empfang mit voller Geschwindigkeit verfügten. Mit den Fortschritten bei den Busgeschwindigkeiten und Speichergrößen ist dieses Problem nicht mehr so häufig. Ein wahrscheinlicheres Szenario ist eine [[Netzwerküberlastung]] innerhalb eines Switches. Beispielsweise kann ein Datenstrom über einen Link mit höherer Geschwindigkeit in einen Switch eintreten, als er ihn verlässt, oder es können mehrere Datenströme über zwei oder mehr Links eintreten, die insgesamt die Bandbreite eines Ausgangslinks übersteigen. In diesen Fällen ist der Puffer des Switches irgendwann erschöpft. Die Blockierung des sendenden Links führt jedoch dazu, dass alle Ströme über diesen Link verzögert werden, auch diejenigen, die keine Überlastung verursachen. Diese Situation ist ein Fall von [[Head-of-Line-Blocking]] (HOL) und kann in [[Kernnetz]]-Switches aufgrund der großen Anzahl von Flüssen, die im Allgemeinen aggregiert werden, häufiger auftreten. Viele Switches verwenden eine Technik namens [[virtuelle Ausgangswarteschlangen|virtuelle Ausgangswarteschlangen]], um die HOL-Blockierung intern zu beseitigen, so dass niemals Pausenrahmen gesendet werden.<ref name="vendor99"/>
==Nachfolgende Bemühungen==
===Überlastungsmanagement===
Eine weitere Anstrengung begann im März 2004, und im Mai 2004 wurde daraus die IEEE P802.3ar Congestion Management Task Force. Im Mai 2006 wurden die Ziele der Task Force überarbeitet, um einen Mechanismus zur Begrenzung der übertragenen Datenrate mit einer Granularität von etwa 1 % zu spezifizieren. Der Antrag wurde zurückgezogen und die Task Force wurde 2008 aufgelöst.<ref>{{cite web |title= IEEE P802.3ar Congestion Management Task Force |date= December 18, 2008 |url= http://grouper.ieee.org/groups/802/3/ar/ |access-date= May 10, 2011 }}</ref>
===Prioritätsflusskontrolle===
Die Ethernet-Flusskontrolle stört die Ethernet-Dienstklasse (definiert in [[IEEE 802.1p]]), da die Daten aller Prioritäten angehalten werden, um die vorhandenen Puffer zu leeren, die auch aus Daten niedriger Priorität bestehen können. Um dieses Problem zu lösen, hat [[Cisco Systems]] eine eigene Erweiterung des Standardprotokolls zur Prioritätsflusskontrolle definiert. Dieser Mechanismus verwendet 14 Byte der 42-Byte-Polsterung in einem normalen Pausenrahmen. Der MAC-Kontroll-Opcode für einen Prioritäts-Pausenrahmen ist 0x0101. Anders als bei der ursprünglichen Pause wird bei der Prioritätspause die Pausenzeit in Quanten für jede der acht Prioritätsklassen separat angegeben.<ref>{{cite web |title= Priority Flow Control: Build Reliable Layer 2 Infrastructure |publisher= Cisco Systems |work= White Paper |date= June 2009 |url= http://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-542809.pdf |access-date= May 10, 2011 }}</ref> Die Erweiterung wurde anschließend vom Projekt Priority-based Flow Control (PFC) standardisiert, das am 27. März 2008 als IEEE 802.1Qbb genehmigt wurde.<ref>[http://www.ieee802.org/1/pages/802.1bb.html IEEE 802.1Qbb]</ref> Draft 2.3 wurde am 7. Juni 2010 vorgeschlagen. Claudio DeSanti von Cisco war Herausgeber.<ref>{{cite web |title= IEEE 802.1Q Priority-based Flow Control |publisher= Institute of Electrical and Electronics Engineers |date= June 7, 2010 |url= http://www.ieee802.org/1/pages/802.1bb. html |access-date= May 10, 2011 }}</ref> Das Projekt war Teil der [[Data Center Bridging]]-Task Group, die [[Fibre Channel over Ethernet]] entwickelte.<ref>{{cite web |title= Data Center Bridging Task Group |publisher= Institute of Electrical and Electronics Engineers |date= June 7, 2010 |url= http://www.ieee802.org/1/pages/dcbridges.html |access-date= May 10, 2011 }}</ref>
==See also==
* [[Explicit Congestion Notification]]
==External links==
* {{Cite web |title=Ethernet Media Access Control - PAUSE Frames |work=TechFest Ethernet Technical Summary |year= 1999 |url=http://www.techfest.com/networking/lan/ethernet3.htm#3.2.1 |access-date=May 10, 2011 |archive-url=https://web.archive.org/web/20120204103034/http://www.techfest.com/networking/lan/ethernet3.htm |archive-date=February 2012}}
* {{cite web |title= When Flow Control is not a Good Thing |date= November 7, 2007  |author= Tim Higgins |work= Small Net Builder |url= https://www.smallnetbuilder.com/lanwan/lanwan-features/30212-when-flow-control-is-not-a-good-thing |access-date= January 6, 2020}}
*[http://www.tux.org/pub/sites/www.zip.com.au/%257Eakpm/linux/#flow-ctrl Linux Tool for generating flow control PAUSE frames]
*[https://github.com/archjeb/pfctest Python Tool to Generate PFC Frames]
* {{Cite journal |title=Ethernet Flow Control |journal=Topics in High-Performance Messaging |url=http://www.29west.com/docs/THPM/thpm.html#ETHERNET-FLOW-CONTROL |archive-url=https://web.archive.org/web/20071208094516/http://www.29west.com/docs/THPM/thpm.html#ETHERNET-FLOW-CONTROL |archive-date=2007-12-08 }}


[[Category:IEEE 802]]
[[Category:IEEE 802]]
[[Category:Ethernet standards]]
[[Category:Ethernet standards]]
[[Category:Flow control (data)]]
[[Category:Flow control (data)]]

Version vom 23. März 2023, 22:24 Uhr

topic - Kurzbeschreibung

Technik zur Unterbrechung der Übertragung, um Staus zu vermeiden

Beschreibung

Wireshark Screenshot eines Ethernet "Pause" Frames

Ethernet Flow Control ist ein Mechanismus zur vorübergehenden Unterbrechung der Datenübertragung in Ethernet-Familien Computernetzwerken. Ziel dieses Mechanismus ist es, Paketverluste bei einer Netzwerküberlastung zu vermeiden.

Der erste Flusskontrollmechanismus, der Pausenrahmen, wurde durch die Norm IEEE 802.3x definiert. Die nachfolgende prioritätsbasierte Flusskontrolle, die im IEEE 802.1Qbb-Standard definiert ist, bietet einen Flusskontrollmechanismus auf Verbindungsebene, der unabhängig für jede Dienstklasse (CoS) gesteuert werden kann, wie von IEEE P802.1p definiert, und ist für Data Center Bridging-Netzwerke (DCB) anwendbar und ermöglicht die Priorisierung von Voice-over-IP (VoIP), Video-over-IP und Datenbanksynchronisierungsverkehr gegenüber Standarddatenverkehr und Massendatentransfers.

Beschreibung

Eine sendende Station (Computer oder Netzwerk-Switch) überträgt möglicherweise Daten schneller, als das andere Ende der Verbindung sie annehmen kann. Mit Hilfe der Flusskontrolle kann die empfangende Station dem Sender signalisieren, dass die Übertragungen unterbrochen werden sollen, bis der Empfänger aufholt. Die Flusskontrolle bei Ethernet kann auf der Datenübertragungsschicht implementiert werden.

Der erste Flusskontrollmechanismus, der Pausenrahmen, wurde von der Arbeitsgruppe des Institute of Electrical and Electronics Engineers (IEEE) definiert, die die Vollduplex-Segmente Ethernet-Verbindungssegmente definierte. Der IEEE-Standard 802.3x wurde 1997 veröffentlicht.[1]

Pause frame

Ein überlasteter Netzknoten kann einen Pausenrahmen senden, der die Übertragung des Senders für eine bestimmte Zeitspanne unterbricht. Ein Media Access Control (MAC) frame (EtherType 0x8808) wird verwendet, um den Pause-Befehl zu übertragen, wobei der Control Opcode auf 0x0001 (hexadezimal) gesetzt ist.[1] Nur Stationen, die für Vollduplex-Betrieb konfiguriert sind, können PAUSE-Frames senden. Wenn eine Station das andere Ende einer Verbindung anhalten möchte, sendet sie einen Pausenrahmen entweder an die eindeutige 48-Bit-Zieladresse dieser Verbindung oder an die reservierte 48-Bit-Multicast-Adresse von Vorlage:No wrap.[2]Vorlage:Rp Die Verwendung einer bekannten Adresse macht es für eine Station unnötig, die Adresse der Station am anderen Ende der Verbindung zu ermitteln und zu speichern.

Ein weiterer Vorteil der Verwendung dieser Multicast-Adresse ergibt sich aus der Verwendung der Flusskontrolle zwischen Netzwerk-Switches. Die verwendete Multicast-Adresse wird aus einer Reihe von Adressen ausgewählt, die durch den IEEE 802.1D-Standard reserviert wurden, der den Betrieb von Switches für Bridging spezifiziert. Normalerweise wird ein an einen Switch gesendeter Rahmen mit einem Multicast-Ziel an alle anderen Ports des Switches weitergeleitet. Dieser Bereich von Multicast-Adressen ist jedoch speziell und wird von einem 802.1D-kompatiblen Switch nicht weitergeleitet. Stattdessen werden Frames, die an diesen Bereich gesendet werden, als Frames verstanden, die nur innerhalb des Switches bearbeitet werden sollen.

Ein Pausenrahmen enthält die angeforderte Pausenzeit in Form einer vorzeichenlosen Ganzzahl mit zwei Byte (16 Bit) (0 bis 65535). Diese Zahl ist die angeforderte Dauer der Pause. Die Pausenzeit wird in Einheiten von Pausen-"Quanten" gemessen, wobei jede Einheit 512 Bitzeiten entspricht.

Bis 1999 unterstützten mehrere Anbieter den Empfang von Pausenrahmen, aber nur wenige den Versand.[3][4]

Probleme

Eine ursprüngliche Motivation für den Pausenrahmen war der Umgang mit Netzwerkschnittstellen-Controllern (NICs), die nicht über genügend Puffer für den Empfang mit voller Geschwindigkeit verfügten. Mit den Fortschritten bei den Busgeschwindigkeiten und Speichergrößen ist dieses Problem nicht mehr so häufig. Ein wahrscheinlicheres Szenario ist eine Netzwerküberlastung innerhalb eines Switches. Beispielsweise kann ein Datenstrom über einen Link mit höherer Geschwindigkeit in einen Switch eintreten, als er ihn verlässt, oder es können mehrere Datenströme über zwei oder mehr Links eintreten, die insgesamt die Bandbreite eines Ausgangslinks übersteigen. In diesen Fällen ist der Puffer des Switches irgendwann erschöpft. Die Blockierung des sendenden Links führt jedoch dazu, dass alle Ströme über diesen Link verzögert werden, auch diejenigen, die keine Überlastung verursachen. Diese Situation ist ein Fall von Head-of-Line-Blocking (HOL) und kann in Kernnetz-Switches aufgrund der großen Anzahl von Flüssen, die im Allgemeinen aggregiert werden, häufiger auftreten. Viele Switches verwenden eine Technik namens virtuelle Ausgangswarteschlangen, um die HOL-Blockierung intern zu beseitigen, so dass niemals Pausenrahmen gesendet werden.[4]

Nachfolgende Bemühungen

Überlastungsmanagement

Eine weitere Anstrengung begann im März 2004, und im Mai 2004 wurde daraus die IEEE P802.3ar Congestion Management Task Force. Im Mai 2006 wurden die Ziele der Task Force überarbeitet, um einen Mechanismus zur Begrenzung der übertragenen Datenrate mit einer Granularität von etwa 1 % zu spezifizieren. Der Antrag wurde zurückgezogen und die Task Force wurde 2008 aufgelöst.[5]

Prioritätsflusskontrolle

Die Ethernet-Flusskontrolle stört die Ethernet-Dienstklasse (definiert in IEEE 802.1p), da die Daten aller Prioritäten angehalten werden, um die vorhandenen Puffer zu leeren, die auch aus Daten niedriger Priorität bestehen können. Um dieses Problem zu lösen, hat Cisco Systems eine eigene Erweiterung des Standardprotokolls zur Prioritätsflusskontrolle definiert. Dieser Mechanismus verwendet 14 Byte der 42-Byte-Polsterung in einem normalen Pausenrahmen. Der MAC-Kontroll-Opcode für einen Prioritäts-Pausenrahmen ist 0x0101. Anders als bei der ursprünglichen Pause wird bei der Prioritätspause die Pausenzeit in Quanten für jede der acht Prioritätsklassen separat angegeben.[6] Die Erweiterung wurde anschließend vom Projekt Priority-based Flow Control (PFC) standardisiert, das am 27. März 2008 als IEEE 802.1Qbb genehmigt wurde.[7] Draft 2.3 wurde am 7. Juni 2010 vorgeschlagen. Claudio DeSanti von Cisco war Herausgeber.[8] Das Projekt war Teil der Data Center Bridging-Task Group, die Fibre Channel over Ethernet entwickelte.[9]

Installation

Anwendungen

Fehlerbehebung

Syntax

Optionen

Parameter

Umgebungsvariablen

Exit-Status

Konfiguration

Dateien

Sicherheit

Siehe auch

  1. Explicit Congestion Notification

Dokumentation

RFC

Man-Pages

Info-Pages

Links

Einzelnachweise

  1. ↑ 1,0 1,1 Vorlage:Cite book
  2. ↑ Vorlage:Cite book
  3. ↑ Vorlage:Cite news
  4. ↑ 4,0 4,1 Vorlage:Cite news Kommentare der Hersteller zur Flusskontrolle im Test von 1999.
  5. ↑ Vorlage:Cite web
  6. ↑ Vorlage:Cite web
  7. ↑ IEEE 802.1Qbb
  8. ↑ Vorlage:Cite web
  9. ↑ Vorlage:Cite web

Projekt

Weblinks

External links

  1. Vorlage:Cite web
  2. Vorlage:Cite web
  3. Linux Tool for generating flow control PAUSE frames
  4. Python Tool to Generate PFC Frames
  5. Vorlage:Cite journal

Testfragen

Testfrage 1

Antwort1

Testfrage 2

Antwort2

Testfrage 3

Antwort3

Testfrage 4

Antwort4

Testfrage 5

Antwort5
Abgerufen von „https://wiki.foxtom.de/index.php?title=Ethernet/Flow_Control&oldid=59555“