Ethernet çerçeveleri için MTU boyutu neden 1500 bayt olarak hesaplandı?


38

Bu sayıya ulaşmak için yapılan belirli bir hesaplama var mı ve bu hesaplama için dikkate alınan faktörler nelerdi?


2
IEEE çalışanları standarda 9k eklemeye direniyorlar çünkü FCS'nin bugün 1.5k'da getirdiği matematiksel garantiler 9k'da artık doğru olmayacak
27'de

5
@ytti, bu> 1500 kareyi onaylamaya karşı çıkan argümanlardan sadece bir tanesi. Geoff Thomson'ın mektubunun tam metni (jumbo çerçevelerin standartlaştırılmasına yönelik IEEE itirazlarını içeren) taslak-ietf-isis-ext-eth-01 Ek 1’dedir . İtirazlar "Düşünceler" sözcüğü ile başlar
Mike Pennington

Herhangi bir cevap size yardımcı oldu mu? eğer öyleyse, cevabı kabul etmelisin ki soru sonsuza kadar ortaya çıkmayacak, cevap arayacaksın. Alternatif olarak, kendi cevabınızı verebilir ve kabul edebilirsiniz.
Ron Maupin

Yanıtlar:


27

Cevap taslak-ietf-isis-ext-eth-01 , Bölüm 3-5'te verilmiştir. Ethernet, Ethernet II (DIX) ve 802.3 kapsüllemelerinde aynı iki bayt farklı yolu kullanır:

  • Ethernet II, bir Tür için Ethernet kaynağı mac adresinden sonraki ilk iki baytı kullanır
  • 802.3, aynı iki baytı bir Uzunluk alanı için kullanır .

Çakışan baytların ethernet başlığında tam olarak nerede olduğunu gösteren her çerçeve türünün altında açıklamalı bir diyagram ekliyorum:

  • RFC 894 (genellikle Ethernet II çerçeveleri olarak bilinir) bu baytları Tip için kullanır.

       +----+----+------+------+-----+
       | 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)
    
  • 802.2 LLC / SNAP (Spanning-Tree, ISIS tarafından kullanılan) ile IEEE 802.3 bu baytları Uzunluk için kullanır

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

Hem Ethernet II hem de 802.3 kapsülleme aynı bağlantıda bulunabilmelidir. IEEE Ethernet yüklerinin 1536 baytı (0x600 hex) aşmasına izin verirse, büyük 802.3 LLC veya SNAP çerçevelerini Ethernet II çerçevelerinden ayırt etmek mümkün olmazdı; ethernet'in Tip değerleri 0x600 hex de başlıyor.

DÜZENLE:

Herkesin ilgisini çekmesi durumunda , Ethernet Versiyon 1 spesifikasyonunun pdf kopyalarına ve Ethernet Versiyon 2 spesifikasyonunun bağlantısını da ekliyorum ...



2
Eh, Ethernet II çerçeveleri kendi alanlarını 0x0600'de (IEEE 802.3x-1997 spesifikasyonundan itibaren) başlar, çünkü maksimum maksimum 802.3 uzunluğu bunun altındaydı. Yani bu sadece bir sonuç, sebep değil.
nos

1
@ nos, bunun bir neden yerine bir etkisi olduğunu iddia etmek, nedenini ispatlayabileceğinizi öngörür ... önerilen nedeniniz için yetkili kanıtlar sunabilir misiniz? 1980'de yayınlanan orijinal Ethernet Versiyon 1 spesifikasyonu halihazırda Tip alanını kullanmaktadır ve 1984'te IP protokolü Ethertype 0x0800 kullanılarak belirtilmiştir
Mike Pennington

2
Aslında, ethernet I ve II spesifikasyonu zaten bir tür alana sahipti (o zamanlar hiçbir kısıtlama yoktu) ve zaten 1500 maksimum veri uzunluğunu belirledi - o zaman 802.3 çerçeve yoktu. Bu nedenle tür sınırlaması nedeniyle 1500 sınırının sonraki bir spekada eklendiği sonucuna varılamaz.
nos

2
@nos katılmıyorum, Ethernet II önceden var olan standarda eşlik etmek zorundaydı. Ayrıca aynı alanın hem önceki standartta bir tip alan hem de yeni standartta bir uzunluk alan olarak işlev görmesini tanımladı. Aynı ağda bir arada bulunması gereken iki standart arasında bir karışıklık ihtimalinin OLMAMASI nedeniyle, mevcut bir tip gibi görünebilecek herhangi bir uzunlukta izin verilmeyecektir. Mevcut tip listesinin 0x600bir sayıdan başlamasıyla, seçilmesi gerekenden daha az. Standarda daha fazla genişlemenin yapılmaması için, ihtiyaç duyulması halinde uygun bir bant olması gerekiyordu.

14

Aralığın diğer ucunda - 1500 bayt, bu sınırın girilmesine yol açan iki faktör vardı. İlk olarak, eğer paketler çok uzunsa, Ethernet kablosunu kullanarak diğer trafiğe ekstra gecikmeler yaşarlar. Diğer faktör ise, erken paylaşılan kablo alıcı-vericilere yerleştirilmiş bir güvenlik cihazıydı. Bu güvenlik cihazı, anti-babble bir sistemdi.Bir alıcı-vericiye bağlı cihaz bir arıza geliştirmiş ve sürekli olarak iletilmeye başlamışsa, o zaman diğer Ethernet trafiğini bu Ethernet kablo segmentini kullanmasını engeller. Bu durumdan korunmak için, ilk alıcı-vericiler, iletim yaklaşık 1.25 milisaniyeyi aştığında otomatik olarak kapanacak şekilde tasarlanmıştır. Bu sadece 1500 bayttan fazla veri içeriğine eşittir. Bununla birlikte, alıcı-verici, eğer babbling algılanırsa, iletimi kapatmak için basit bir analog zamanlayıcı kullandığından, 1500 limiti, güvenlik cihazını tetiklemeyen maksimum veri boyutuna güvenli bir yaklaşım olarak seçilmiştir.

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


5
Hi @ user1171: StackExchange tercih edilen stil, cevap malzemesini buraya eklemek ve referans olarak bağlamaktır. Bu şekilde, bağlantı sonunda çürüdüğünde, cevap hala yararlıdır.
Craig Constantine

Jabber işlevi , MAU’nun 10 Mbit / s (IEEE 802.3 Fıkra 8.2.1.5), 40 ila 75 kbit , Hızlı Ethernet (Fıkra 27.3.2.1.4) için 20 ila 150 msn sonra kapatmasını ve Gigabit Ethernet’in iki katı çerçeve uzunluğunu çok aştı. Yahoo yazısı yanlış.
Zac67

10

Ethernet başlangıçta 10Base5 ve 10Base2 ile paylaşılan bir ortam veya veri yolu olarak geliştirildiğinde, çerçevelerin çarpışmaları sık sık ve tasarımın bir parçası olarak bekleniyordu. Kimsenin çarpışma görmeyi beklemeyeceği, her şeyin ayrı çarpışma alanları ile değiştirildiği ve tam çift yönlü çalıştığı günümüzde bunun aksine.

"Eter" i paylaşan mekanizmada kullanılan CMSA / CD (Taşıyıcı Algı Çoklu Erişim / Çarpışma Tespiti)

Taşıyıcı Algısı, iletmek isteyen bir istasyonun, o ortamdaki Çoklu Erişim olduğundan başka kimsenin konuşmamasını sağlamak için kabloyu - taşıyıcı sinyalini algılamak - dinlemesi gerektiği anlamına geliyordu. 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. Bir çerçevede ne kadar çok bayt iletilirse, diğer tüm istasyonların o iletim tamamlanana kadar beklemesi gerekir. Başka bir deyişle, daha kısa patlamalar veya daha küçük MTU, diğer istasyonların daha fazla yayın ve daha adil bir paylaşım fırsatı elde ettiği anlamına geliyordu. İletim ortamının hızı (10 Mb / sn) ne kadar yavaş olursa, istasyonlar MTU arttıkça (1500'ü aşmasına izin verilirse) iletmek için daha uzun gecikmeler olacaktır.

İlginç bir soru sorusu neden minimum 64 byte kare büyüklüğünde olabilir? Çerçeveler, 512 bit olan "yuvalarda" iletildi ve ortam içerisinde gidiş-dönüş sinyali yayılması için 51.2us aldı. Bir istasyon, IFG'yi (96 bitlik kareler arası boşluk) algılayarak ne zaman konuşmaya başlaması gerektiğini değil, diğer karelerle çarpışmaları da dinlemelidir. Çarpışma Tespiti, maksimum yayılma gecikmesi olduğunu varsayar ve bunu iki katına çıkarır (güvenli olması için), telin diğer ucundan yaklaşık aynı saatte başlayan bir iletimi veya bir iletimin sonlandırma direncini unuttuğu zaman kendi iletiminin bir sinyal yansımasını kaçırmaz kablonun uçları. İstasyon, bir çarpışmayı algılamadan önce verilerinin gönderilmesini tamamlamamalıdır, bu nedenle 512 bit veya 64 bayt beklemek bunu garanti eder.


2

Aslen, maks. faydalı yük 802.3'te 1500 bayt olarak tanımlandı. Ethernet v2,> = 1536 kare uzunluğunu destekler ve IP uygulamalarında kullanılan budur. Çoğu taşıyıcı sınıfı satıcıları bugünlerde yaklaşık 9000 baytı ("jumbo çerçeveler") desteklemektedir. 1500 bayt, tüm Ethernet uygulamalarının desteklemesi gereken standart olduğundan, normalde tüm arayüzlerde varsayılan olarak ayarlanan budur.


Google maxValidFrame google gerekir, IEEE tarafından tanımlandı; Sonuç olarak, bugün yaygın olan 9KB jumbo çerçeve uygulamaları Ethernet ile resmi olarak uyumlu değil, ancak Ethernet II yükleri için oldukça iyi çalışıyorlar
Mike Pennington

Kesinlikle, 802.3 uyumlu değil. IP, Ethernet v2 kullanıyor, bu yüzden

5
Jumbos, 802.3x onaylandıktan sonra Ethernet II veya 802.3 ile uyumlu değildir. 802.3x Madde 4.2.7.1, 1500B yüklerinde maxValidFrame öğesini tanımlar. Bu nedenle 1997'den sonra, 1500 baytı aşan herhangi bir veri yükü uyumlu değildir. Bu konuda IEEE 802.3 başkanının IETF'e gönderdiği mektuba bakın . Kısacası, 802.3 bir çerçeve standardından çok daha fazlası ... hem çerçevelemeyi hem de donanım gereksinimlerini tanımlar. Bu, donanım uygulamalarının çerçeve formatına uygunluğa bağlı olduğu anlamına gelir. Yarım Dubleks w / CSMA-CD <= 1500B yük kapasitesine ihtiyaç duyar.
Mike Pennington

-1

Asgari ethernet çerçevesi, 10M ethernet için 512 bit uzunluk (64 Bayt) olan Ethernet Slot Zamanına dayanır. Ethernet başlığı ve CRC için 18 bayt çıkardıktan sonra, 46 baytlık bir yük elde edersiniz.

Ethernet Yuvası Süresi, CSMA / CD'nin doğru çalışması için belirlenmiştir. Asgari çerçeve boyutunun mümkün olan en uzun kablo uzunluğunu aşmadığından emin olunmalıdır; deterministik çarpışma tespiti yapması mümkün olmazdı. Maksimum kablo uzunluğunda çarpışma tespitinden sonra, gönderene geri dönmek için çarpışma algılama sinyaline ihtiyacınız vardır.


3
Minimum ethernet çerçeve boyutunu belirleme mekanizmasının mevcut 1500 byte maksimum defacto standardı ile ne alakası olduğunu anlamakta güçlük çekiyorum. Lütfen detaylandırın!
Stuggi

2
@Stuggi Yapmaz.
Ken Sharp,
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.