Perché la dimensione MTU per i frame Ethernet è stata calcolata come 1500 byte?

38

Esiste un calcolo specifico che è stato fatto per arrivare a questo numero e quali sono stati i fattori presi in considerazione per quel calcolo?

ethernet mtu protocol-theory

— Padmaraj
fonte

2

Le persone IEEE resistono all'aggiunta di 9k allo standard perché le garanzie matematiche che FCS offre oggi a 1.5k non sarebbero più vere a 9k.

— ytti,

5

@ytti, questo è solo uno degli argomenti contro l'approvazione di> 1500 frame. Il testo completo della lettera di Geoff Thomson (contenente le obiezioni dell'IEEE alla standardizzazione dei frame jumbo) è nella bozza-ietf-isis-ext-eth-01 Appendice 1 . Le obiezioni iniziano con la parola "Considerazione"

— Mike Pennington,

Qualche risposta ti è stata d'aiuto? in tal caso, dovresti accettare la risposta in modo che la domanda non continui a comparire per sempre, alla ricerca di una risposta. In alternativa, potresti fornire e accettare la tua risposta.

— Ron Maupin

27

La risposta è in draft-ietf-isis-ext-eth-01 , sezioni 3-5. Ethernet utilizza gli stessi due byte in modi diversi negli incapsulamenti Ethernet II (DIX) e 802.3:

Ethernet II utilizza i primi due byte dopo l'indirizzo mac di origine Ethernet per un tipo
802.3 utilizza gli stessi due byte per un campo Lunghezza .

Sto includendo un diagramma annotato sotto di ogni tipo di frame, che mostra esattamente dove si trovano i byte in conflitto nell'intestazione Ethernet:

RFC 894 (comunemente noto come frame Ethernet II) usa questi byte per Tipo

   +----+----+------+------+-----+
   | 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 con 802.2 LLC / SNAP (utilizzato da Spanning-Tree, ISIS) utilizzano questi byte per Lunghezza

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

Entrambi gli incapsulamenti Ethernet II e 802.3 devono poter esistere sullo stesso collegamento. Se IEEE consentisse ai payload Ethernet di superare i 1536 byte (0x600 hex), sarebbe impossibile distinguere i frame 802.3 LLC o SNAP di grandi dimensioni dai frame Ethernet II; I valori Tipo di Ethernet iniziano da 0x600 hex.

MODIFICARE:

Includo un link alle copie pdf delle specifiche Ethernet versione 1 e Ethernet versione 2 , nel caso qualcuno fosse interessato ...

— Mike Pennington
fonte

2

A proposito, i valori tra maxValidFrame (1500) e "1536 decimal" non sono definiti nello standard Ethernet. Il comportamento dell'attrezzatura a questi valori non è specificato e non può essere dipendente da

— Mike Pennington

2

Bene, i frame Ethernet II hanno il loro campo di tipo a partire da 0x0600 (dalle specifiche IEEE 802.3x-1997) perché la lunghezza massima massima di 802.3 era appena inferiore a quella. Quindi questo è solo un effetto, non una causa.

— nn.

1

@nos, affermare che questo è un effetto anziché una causa presuppone che tu possa dimostrarne la causa ... puoi fornire prove autorevoli per la tua causa proposta? La specifica Ethernet Versione 1 pubblicata nel 1980 utilizza già il campo Tipo e nel 1984 il protocollo IP è stato specificato utilizzando Ethertype 0x0800

— Mike Pennington,

2

In effetti, le specifiche Ethernet I e II avevano già un campo di tipo (che a quel tempo non aveva restrizioni) e già specificavano la lunghezza massima dei dati di 1500 - a quel tempo non c'erano frame 802.3. Quindi non si può concludere che il limite di 1500 sia stato aggiunto in una specifica successiva a causa del campo del tipo.

— nn.

2

@nos Non sono d'accordo, Ethernet II ha dovuto coesistere con lo standard preesistente. E ha anche definito l'uso dello stesso campo per agire sia come campo di tipo nello standard precedente sia come campo di lunghezza nel nuovo standard. Dato che NON DEVE ESSERE alcuna possibilità di confusione tra i due standard, che devono coesistere nella stessa rete, qualsiasi lunghezza che potrebbe apparire come un tipo esistente non sarebbe consentita. Poiché l'elenco di tipi esistenti è iniziato con 0x600un numero inferiore a quello che si doveva scegliere. Per non consentire ulteriori espansioni allo standard, doveva essere disponibile una banda disponibile nel caso fosse necessario.

14

All'altra estremità dell'intervallo - 1500 byte, c'erano due fattori che hanno portato all'introduzione di questo limite. Innanzitutto, se i pacchetti sono troppo lunghi, introducono ulteriori ritardi nell'altro traffico utilizzando il cavo Ethernet. L'altro fattore era un dispositivo di sicurezza integrato nei primi ricetrasmettitori di cavi condivisi. Questo dispositivo di sicurezza era un sistema anti-vibrazione.Se il dispositivo collegato a un ricetrasmettitore sviluppa un errore e inizia a trasmettere in modo continuo, bloccherebbe efficacemente qualsiasi altro traffico derivante dall'utilizzo di quel segmento di cavo Ethernet. Per proteggersi da ciò, i primi ricetrasmettitori sono stati progettati per spegnersi automaticamente se la trasmissione superava circa 1,25 millisecondi. Ciò equivale a un contenuto di dati di poco più di 1500 byte. Tuttavia, poiché il ricetrasmettitore utilizzava un semplice timer analogico per interrompere la trasmissione se veniva rilevata una vibrazione, il limite 1500 veniva selezionato come un'approssimazione sicura della dimensione massima dei dati che non avrebbe innescato il dispositivo di sicurezza.

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

— user1171
fonte

5

Ciao @ user1171: lo stile preferito di StackExchange è includere qui il materiale di risposta e collegarlo come riferimento. In questo modo, quando alla fine il collegamento marcisce, la risposta è ancora utile.

— Craig Constantine,

La funzione jabber richiedeva lo spegnimento della MAU dopo 20 a 150 ms per 10 Mbit / s (IEEE 802.3 clausola 8.2.1.5), da 40 a 75 kbit per Fast Ethernet (clausola 27.3.2.1.4) e due volte quella per Gigabit Ethernet, superando di gran lunga la lunghezza del telaio. Il post di Yahoo è sbagliato.

— Zac67,

10

Quando Ethernet è stata originariamente sviluppata come supporto condiviso o bus con 10Base5 e 10Base2, le collisioni di frame erano frequenti e prevedibili come parte del progetto. Confrontalo con oggi quando la maggior parte di tutto viene commutata con domini di collisione separati e in esecuzione full-duplex dove nessuno si aspetta di vedere le collisioni.

Il meccanismo per condividere "etere" impiegava CMSA / CD (Carrier Sense Multiple Access / Collision Detection)

Carrier Sense significava che una stazione che voleva trasmettere doveva ascoltare il filo - percepire il segnale del portatore - per assicurarsi che nessun altro stesse parlando poiché era Accesso multiplo su quel supporto. 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. Più byte vengono trasmessi in un frame, più a lungo tutte le altre stazioni devono attendere fino al completamento della trasmissione. In altre parole, scoppi più brevi o MTU più piccoli significavano che altre stazioni avevano più opportunità di trasmettere e una quota più equa. Più lenta è la velocità del mezzo di trasmissione (10 Mb / s), le stazioni avrebbero ritardi più lunghi da trasmettere all'aumentare dell'MTU (se consentito superare i 1500).

Una domanda corollaria interessante sarebbe perché la dimensione minima del frame di 64 byte? I frame sono stati trasmessi in "slot" di 512 bit e hanno impiegato 51.2us per la propagazione del segnale di andata e ritorno nel mezzo. Una stazione deve non solo ascoltare quando iniziare a parlare rilevando l'IFG (interframe gap di 96 bit), ma anche ascoltare le collisioni con altri frame. Collision Detection presuppone il massimo ritardo di propagazione e raddoppia (per sicurezza) in modo da non perdere una trasmissione che inizia all'incirca nello stesso momento dall'altra estremità del filo o un riflesso del segnale della sua stessa trasmissione quando qualcuno ha dimenticato la resistenza terminale al estremità del cavo. La stazione non deve completare l'invio dei suoi dati prima di rilevare una collisione, quindi attendere 512 bit o 64 byte lo garantisce.

— generalnetworkerror
fonte

2

In origine, max. il payload è stato definito come 1500 byte in 802.3. Ethernet v2 supporta una lunghezza dei frame> = 1536 e questo è ciò che usano le implementazioni IP. La maggior parte dei fornitori di classe carrier al momento supporta circa 9000 byte ("frame jumbo"). Poiché 1500 byte è lo standard che tutte le implementazioni Ethernet devono supportare, questo è ciò che viene normalmente impostato come predefinito su tutte le interfacce.

Dovresti google maxValidFrame, è stato definito da IEEE; di conseguenza, le implementazioni di frame jumbo da 9 KB che sono comuni oggi non sono ufficialmente conformi a Ethernet, ma funzionano abbastanza bene per i payload Ethernet II

— Mike Pennington

A rigor di termini, non conforme allo standard 802.3. L'IP usa però Ethernet v2, quindi tendo a non pensare nemmeno allo standard 802.3 ...

5

I jumbos non sono conformi a Ethernet II o 802.3 dopo la ratifica di 802.3x. La clausola 4.2.3.1 802.3x definisce maxValidFrame con payload di 1500B. Pertanto, dopo il 1997, qualsiasi carico utile superiore a 1500 byte non è conforme. Vedere la lettera che il presidente IEEE 802.3 ha inviato all'IETF in merito a questo problema . In breve, 802.3 è molto più di uno standard di frame ... definisce sia i requisiti di frame che hardware. Ciò significa che le implementazioni hardware dipendono dalla conformità con il formato del frame. Half Duplex con CD CSMA richiede <= 1500 B di payload.

— Mike Pennington,

-1

Il frame Ethernet minimo si basa sul tempo di slot Ethernet, che è di 512 bit (64 byte) per Ethernet 10M. Dopo aver sottratto 18 byte per l'intestazione Ethernet e CRC, si ottengono 46 byte di payload.

Il tempo di slot Ethernet è stato specificato in modo che CSMA / CD funzionasse correttamente. Bisogna essere sicuri che la dimensione minima del telaio non superi la lunghezza più lunga possibile del cavo; se lo facesse, il rilevamento deterministico delle collisioni sarebbe impossibile. Dopo il rilevamento delle collisioni alla massima lunghezza del cavo, è necessario il segnale di rilevamento delle collisioni per tornare al mittente.

— Pooja Khatri
fonte

3

Sto riscontrando problemi nel capire come il meccanismo per determinare la dimensione minima del frame Ethernet abbia qualcosa a che fare con l'attuale standard massimo di 1500 byte. Per favore, elabora!

— Stuggi,

2

@Stuggi Non lo fa.

— Ken Sharp,