Warum wurde die MTU-Größe für Ethernet-Frames mit 1500 Byte berechnet?


38

Gibt es eine spezifische Berechnung, die durchgeführt wurde, um zu dieser Zahl zu gelangen, und welche Faktoren wurden für diese Berechnung berücksichtigt?


2
IEEE-Leute wehren sich dagegen, 9.000 zum Standard hinzuzufügen, weil mathematische Garantien, die FCS heute bei 1,5.000 bringt, bei 9.000 nicht mehr alle zutreffen würden.
Ytti

5
@ytti, das ist nur eines der Argumente gegen das Indossieren von> 1500 Frames. Der vollständige Text des Briefes von Geoff Thomson (der die IEEE-Einwände gegen die Standardisierung von Jumbo-Frames enthält) ist in Anhang 1 des Entwurfs-ietf-isis-ext-eth-01 enthalten . Die Einwände beginnen mit dem Wort "Gegenleistung"
Mike Pennington

Hat Ihnen eine Antwort geholfen? In diesem Fall sollten Sie die Antwort akzeptieren, damit die Frage nicht für immer auftaucht und nach einer Antwort sucht. Alternativ können Sie auch Ihre eigene Antwort eingeben und annehmen.
Ron Maupin

Antworten:


27

Die Antwort ist im Entwurf-ietf-isis-ext-eth-01 , Abschnitte 3-5. Ethernet verwendet dieselben zwei Bytes auf unterschiedliche Weise in den Ethernet II (DIX) - und 802.3-Kapselungen:

  • Ethernet II verwendet die ersten zwei Bytes nach der Ethernet-Quell-Mac-Adresse für einen Typ
  • 802.3 verwendet das gleiche zwei Bytes für eine Länge Feld.

Ich füge ein kommentiertes Diagramm unter jedem Rahmentyp hinzu, das genau zeigt, wo sich die widersprüchlichen Bytes im Ethernet-Header befinden:

  • RFC 894 (allgemein als Ethernet II-Frames bezeichnet) verwendet diese Bytes für Type

       +----+----+------+------+-----+
       | DA | SA | Type | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^
    
       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Type    Protocol Type           (2 bytes: >= 0x0600 or 1536 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)
    
  • IEEE 802.3 mit 802.2 LLC / SNAP (verwendet von Spanning-Tree, ISIS) verwendet diese Bytes für die Länge

       +----+----+------+------+-----+
       | DA | SA | Len  | Data | FCS |
       +----+----+------+------+-----+
                 ^^^^^^^^
    
       DA      Destination MAC Address (6 bytes)
       SA      Source MAC Address      (6 bytes)
       Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
       Data    Protocol Data           (46 - 1500 bytes)
       FCS     Frame Checksum          (4 bytes)
    

Sowohl Ethernet II- als auch 802.3-Kapselungen müssen auf derselben Verbindung vorhanden sein. Wenn IEEE zulässt, dass Ethernet-Nutzdaten 1536 Byte (0x600 hex) überschreiten, ist es unmöglich, große 802.3 LLC- oder SNAP-Frames von Ethernet II-Frames zu unterscheiden. Die Werte für den Typ des Ethernets beginnen bei 0x600 hex.

BEARBEITEN:

Ich füge einen Link zu PDF-Kopien der Ethernet-Version 1-Spezifikation und der Ethernet-Version 2-Spezifikation hinzu , falls jemand interessiert ist ...



2
Nun, bei Ethernet II-Frames beginnt das Typfeld bei 0x0600 (ab der IEEE 802.3x-1997-Spezifikation), da die maximale Länge von 802.3 knapp darunter lag. Das ist also nur eine Wirkung, keine Ursache.
Nr.

1
@nos, um zu behaupten, dass dies eine Auswirkung anstelle einer Ursache ist, müssen Sie die Ursache nachweisen. Können Sie einen maßgeblichen Beweis für die vorgeschlagene Ursache erbringen? Die 1980 veröffentlichte ursprüngliche Spezifikation für Ethernet Version 1 verwendet bereits das Feld Typ, und 1984 wurde das IP-Protokoll mit Ethertype 0x0800
Mike Pennington,

2
In der Tat hatten die Ethernet I- und II-Spezifikationen bereits ein Typfeld (das zu diesem Zeitpunkt keine Einschränkungen aufwies) und spezifizierten bereits die maximale Datenlänge von 1500 - zu diesem Zeitpunkt gab es keine 802.3-Frames. Man kann also nicht schlussfolgern, dass das Limit von 1500 in einer späteren Spezifikation aufgrund des Typfelds hinzugefügt wurde.
Nr.

2
Ich bin nicht einverstanden, Ethernet II musste mit dem bereits existierenden Standard koexistieren. Außerdem wurde die Verwendung desselben Felds definiert, um sowohl als Typfeld in der vorherigen Norm als auch als Längenfeld in der neuen Norm zu fungieren. Da es keine Verwechslungsmöglichkeit zwischen den beiden Standards geben darf, die im selben Netzwerk existieren müssen, ist jede Länge, die wie ein existierender Typ aussehen könnte, nicht zulässig. Als existierende Typenliste musste 0x600eine Nummer kleiner gewählt werden. Damit der Standard nicht weiter erweitert werden konnte, musste im Bedarfsfall noch ein Band verfügbar sein.

14

Am anderen Ende des Bereichs - 1500 Byte - gab es zwei Faktoren, die zur Einführung dieses Grenzwerts führten. Erstens, wenn die Pakete zu lang sind, führen sie über das Ethernet-Kabel zu zusätzlichen Verzögerungen für anderen Datenverkehr. Der andere Faktor war eine Sicherheitsvorrichtung, die in die frühen gemeinsam genutzten Kabeltransceiver eingebaut war. Diese Sicherheitsvorrichtung war ein Anti-Babble-System.Wenn das an einen Transceiver angeschlossene Gerät einen Fehler aufweist und mit der kontinuierlichen Übertragung beginnt, wird die Verwendung dieses Ethernet-Kabelsegments durch anderen Verkehr effektiv blockiert. Um dies zu verhindern, wurden die frühen Transceiver so konzipiert, dass sie sich automatisch abschalten, wenn die Übertragung etwa 1,25 Millisekunden überschreitet. Dies entspricht einem Dateninhalt von etwas mehr als 1500 Bytes. Da der Transceiver jedoch einen einfachen analogen Timer verwendete, um die Übertragung zu unterbrechen, wenn ein Geplapper festgestellt wurde, wurde die Grenze von 1500 als sichere Annäherung an die maximale Datengröße gewählt, die die Sicherheitseinrichtung nicht auslösen würde.

Quelle: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1


5
Hi @ user1171: Der bevorzugte Stil von StackExchange ist, das Antwortmaterial hier einzuschließen und als Referenz zu verlinken. Auf diese Weise ist die Antwort immer noch nützlich, wenn der Link irgendwann verrottet.
Craig Constantine

Die Jabber-Funktion erforderte, dass die MAU nach 20 bis 150 ms für 10 Mbit / s herunterfährt (IEEE 802.3, Abschnitt 8.2.1.5), 40 bis 75 kbit für Fast Ethernet (Abschnitt 27.3.2.1.4) und das Doppelte für Gigabit Ethernet. weit über die Rahmenlänge. Der Yahoo-Beitrag ist falsch.
Zac67

10

Als Ethernet ursprünglich als gemeinsames Medium oder Bus mit 10Base5 und 10Base2 entwickelt wurde, kam es häufig zu Frame-Kollisionen, die als Teil des Designs erwartet wurden. Im Gegensatz zu heute, wo fast alles mit separaten Kollisionsdomänen geschaltet wird und Vollduplex ausgeführt wird, bei dem niemand erwartet, Kollisionen zu sehen.

Der Mechanismus zum Teilen des "Ethers" verwendete CMSA / CD (Carrier Sense Multiple Access / Collision Detection)

Carrier Sense bedeutete, dass ein Sender, der senden möchte, die Leitung abhören muss - das Trägersignal abfühlen -, um sicherzustellen, dass niemand anderes spricht, da es sich auf diesem Medium um einen Mehrfachzugriff handelt. Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time. Je mehr Bytes in einem Frame übertragen werden, desto länger müssen alle anderen Stationen warten, bis diese Übertragung abgeschlossen ist. Mit anderen Worten, kürzere Bursts oder kleinere MTUs bedeuteten, dass andere Sender mehr Übertragungsmöglichkeiten und einen faireren Anteil hatten. Je langsamer die Rate des Übertragungsmediums (10 Mbit / s) ist, desto länger würde die Übertragungsverzögerung dauern, wenn die MTU zunimmt (wenn 1500 überschritten werden dürfen).

Eine interessante Folgefrage wäre, warum die minimale Framegröße von 64 Bytes? Frames wurden in "Slots" übertragen, die 512 Bit umfassen und 51,2 us für die Umlaufsignalausbreitung im Medium benötigten. Ein Sender muss nicht nur hören, wann er mit dem Sprechen beginnen soll, indem er die IFG (Interframe Gap von 96 Bit) abtastet, sondern auch auf Kollisionen mit anderen Frames achten. Die Kollisionserkennung geht von einer maximalen Ausbreitungsverzögerung aus und verdoppelt diese (aus Sicherheitsgründen), damit keine etwa zeitgleich beginnende Übertragung am anderen Ende des Kabels oder eine Signalreflexion der eigenen Übertragung verpasst wird, wenn jemand den Abschlusswiderstand am hat Kabelenden. Die Station darf das Senden ihrer Daten nicht abschließen, bevor eine Kollision erkannt wird. Warten auf 512 Bit oder 64 Byte garantiert dies.


2

Ursprünglich max. Die Nutzlast wurde in 802.3 als 1500 Byte definiert. Ethernet v2 unterstützt eine Frame-Länge von> = 1536, und dies wird von IP-Implementierungen verwendet. Die meisten Anbieter der Carrier-Klasse unterstützen heutzutage etwa 9000 Bytes ("Jumbo-Frames"). Da 1500 Byte der Standard sind, den alle Ethernet-Implementierungen unterstützen müssen, wird dies normalerweise auf allen Schnittstellen als Standard festgelegt.


Sie sollten maxValidFrame googeln, es wurde von IEEE definiert; Infolgedessen sind die heute gebräuchlichen 9-KB-Jumbo-Frame-Implementierungen nicht offiziell mit Ethernet kompatibel, funktionieren aber für Ethernet-II-Nutzdaten recht gut
Mike Pennington,

Streng genommen nicht 802.3-konform. IP verwendet jedoch Ethernet v2, sodass ich nicht einmal an 802.3 denke ...

5
Jumbos sind nach der Ratifizierung von 802.3x nicht mit Ethernet II oder 802.3 kompatibel. 802.3x-Klausel 4.2.7.1 definiert maxValidFrame bei 1500B-Nutzdaten. Daher ist nach 1997 jede Nutzlast, die 1500 Bytes überschreitet, nicht konform. Weitere Informationen finden Sie in dem Brief, den der IEEE 802.3-Vorsitzende zu diesem Thema an die IETF gesendet hat . Kurz gesagt, 802.3 ist weit mehr als ein Frame-Standard. Es definiert sowohl die Anforderungen an das Framing als auch an die Hardware. Dies bedeutet, dass die Hardware-Implementierungen von der Einhaltung des Frame-Formats abhängen. Half Duplex mit CSMA-CD benötigt <= 1500B Nutzdaten.
Mike Pennington

-1

Der minimale Ethernet-Frame basiert auf der Ethernet-Slot-Zeit, die 512 Bit (64 Byte) für 10M-Ethernet beträgt. Nach dem Subtrahieren von 18 Bytes für den Ethernet-Header und die CRC erhalten Sie 46 Bytes Nutzlast.

Die Ethernet-Slot-Zeit wurde angegeben, damit CSMA / CD ordnungsgemäß funktioniert. Es ist darauf zu achten, dass die minimale Baugröße die maximal mögliche Kabellänge nicht überschreitet; Andernfalls wäre eine deterministische Kollisionserkennung nicht möglich. Nach der Kollisionserkennung bei maximaler Kabellänge benötigen Sie das Kollisionserkennungssignal, um zum Absender zurückzukehren.


3
Ich habe Probleme zu verstehen, wie der Mechanismus zum Bestimmen der minimalen Ethernet-Frame-Größe mit dem aktuellen maximalen Defacto-Standard von 1500 Byte zu tun hat. Bitte erläutern Sie!
Stuggi

2
@Stuggi Tut es nicht.
Ken Sharp
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.