Dlaczego rozmiar MTU dla ramek Ethernet obliczono jako 1500 bajtów?

Czy istnieje jakieś konkretne obliczenie, które zostało wykonane, aby dojść do tej liczby, i jakie czynniki zostały wzięte pod uwagę przy tym obliczeniu.

Odpowiedź znajduje się w draft-ietf-isis-ext-eth-01 , sekcje 3-5. Ethernet wykorzystuje te same dwa bajty na różne sposoby w enkapsulacjach Ethernet II (DIX) i 802.3:

• Ethernet II używa pierwszych dwóch bajtów po źródłowym adresie MAC źródła Ethernet dla typu
• 802.3 używa tych samych dwóch bajtów dla pola Długość .

Poniżej zamieszczam diagram z adnotacjami dla każdego typu ramki, który pokazuje dokładnie, gdzie w nagłówku ethernetowym znajdują się sprzeczne bajty:

• RFC 894 (powszechnie znane jako ramki Ethernet II) używają tych bajtów dla typu

     +----+----+------+------+-----+
     | 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 z 802.2 LLC / SNAP (używane przez Spanning-Tree, ISIS) używają tych bajtów dla długości

     +----+----+------+------+-----+
     | 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)
  

Zarówno enkapsulacja Ethernet II, jak i 802.3 musi istnieć na tym samym łączu. Jeśli IEEE zezwoli na ładunki Ethernet przekraczające 1536 bajtów (0x600 hex), nie będzie możliwe odróżnienie dużych ramek LLC.33 lub SNAP od ramek Ethernet II; Wartości typu ethernet zaczynają się od 0x600 hex.

EDYTOWAĆ:

Podaję link do kopii pdf specyfikacji Ethernet w wersji 1 i Ethernet w wersji 2 , na wypadek, gdyby ktoś był zainteresowany ...

Na drugim końcu zakresu - 1500 bajtów, były dwa czynniki, które doprowadziły do ​​wprowadzenia tego limitu. Po pierwsze, jeśli pakiety są zbyt długie, wprowadzają dodatkowe opóźnienia w innym ruchu za pomocą kabla Ethernet. Innym czynnikiem było urządzenie bezpieczeństwa wbudowane we wczesne współdzielone nadajniki-odbiorniki kablowe. To urządzenie zabezpieczające było systemem zapobiegającym bełkotaniu.Jeśli urządzenie podłączone do urządzenia nadawczo-odbiorczego rozwinie się i zacznie nadawać w sposób ciągły, wówczas skutecznie zablokuje wszelki inny ruch przed użyciem tego segmentu kabla Ethernet. Aby zabezpieczyć się przed tym zjawiskiem, wczesne urządzenia nadawczo-odbiorcze zostały zaprojektowane tak, aby wyłączały się automatycznie, jeśli transmisja przekroczyła około 1,25 milisekundy. Odpowiada to zawartości danych nieco ponad 1500 bajtów. Ponieważ jednak nadajnik-odbiornik użył prostego analogowego timera do wyłączenia transmisji, jeśli wykryto bełkotanie, limit 1500 został wybrany jako bezpieczne przybliżenie maksymalnego rozmiaru danych, który nie uruchomiłby urządzenia zabezpieczającego.

Źródło: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

Kiedy Ethernet został pierwotnie opracowany jako wspólny nośnik lub magistrala z 10Base5 i 10Base2, kolizje ramek były częste i oczekiwano w ramach projektu. Porównaj to do dnia dzisiejszego, kiedy większość wszystkiego jest przełączana z oddzielnymi domenami kolizyjnymi i działającym w trybie pełnego dupleksu, gdzie nikt nie spodziewa się zobaczyć kolizji.

W mechanizmie udostępniania „eteru” zastosowano CMSA / CD (Carrier Sense Multiple Access / Collision Detection)

Sense Carrier oznaczało, że stacja chcąca nadawać musi słuchać drutu - wyczuwać sygnał nośny - aby upewnić się, że nikt inny nie mówi, ponieważ był to wielokrotny dostęp na tym medium. 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. Im więcej bajtów przesyłanych jest w ramce, tym dłużej wszystkie inne stacje muszą czekać na zakończenie transmisji. Innymi słowy, krótsze impulsy lub mniejsze MTU oznaczały, że inne stacje miały więcej możliwości nadawania i bardziej sprawiedliwy podział. Im wolniejsza prędkość medium transmisyjnego (10 Mb / s), stacje będą miały dłuższe opóźnienia w transmisji wraz ze wzrostem MTU (jeśli pozwolą na przekroczenie 1500).

Ciekawym następczym pytaniem byłoby, dlaczego minimalny rozmiar ramki to 64 bajty? Ramki były transmitowane w „szczelinach”, które mają 512 bitów i zajmowały 51,2us dla propagacji sygnału w obie strony w medium. Stacja musi nie tylko słuchać, kiedy zacząć mówić, wykrywając IFG (przerwa między ramkami 96 bitów), ale także słuchać kolizji z innymi ramkami. Wykrywanie kolizji zakłada maksymalne opóźnienie propagacji i podwaja to (dla bezpieczeństwa), aby nie przegapić transmisji rozpoczynającej się mniej więcej w tym samym czasie z drugiego końca drutu lub odbicia sygnału własnej transmisji, gdy ktoś zapomniał rezystor końcowy na końce kabla. Stacja nie może zakończyć wysyłania swoich danych przed wykryciem kolizji, dlatego czekanie 512 bitów lub 64 bajtów to gwarantuje.

Pierwotnie maks. ładunek został zdefiniowany jako 1500 bajtów w 802.3. Ethernet v2 obsługuje długość ramki> = 1536 i tego właśnie używają implementacje IP. Większość dostawców klasy operatorskiej obsługuje obecnie około 9000 bajtów („duże ramki”). Ponieważ 1500 bajtów jest standardem, który muszą obsługiwać wszystkie implementacje Ethernet, jest to zwykle ustawienie domyślne dla wszystkich interfejsów.

Minimalna ramka ethernetowa oparta jest na czasie szczeliny Ethernet, który wynosi 512 bitów (64 bajty) dla 10M ethernet. Po odjęciu 18 bajtów dla nagłówka Ethernet i CRC, otrzymujesz 46 bajtów ładunku.

Czas szczeliny Ethernet został określony, aby CSMA / CD działał poprawnie. Trzeba mieć pewność, że minimalny rozmiar ramy nie przekracza najdłuższej możliwej długości kabla; gdyby tak było, deterministyczne wykrywanie kolizji byłoby niemożliwe. Po wykryciu kolizji na maksymalnej długości kabla potrzebny jest sygnał wykrycia kolizji, aby powrócić do nadawcy.