Mengapa ukuran MTU untuk frame ethernet dihitung sebagai 1500 byte?


38

Apakah ada perhitungan khusus yang dilakukan untuk sampai pada angka ini, dan apa faktor-faktor yang dipertimbangkan untuk perhitungan itu.


2
Orang-orang IEEE menolak menambahkan 9k ke standar karena jaminan matematika yang dibawa FCS hari ini pada 1,5k tidak akan semuanya benar lagi pada 9k.
ytti

5
@ytti, itu hanya salah satu argumen yang menentang pengesahan> 1500 frame. Teks lengkap surat Geoff Thomson (berisi keberatan IEEE untuk membakukan frame jumbo) ada di draft-ietf-isis-ext-eth-01 Lampiran 1 . Keberatan dimulai dengan kata "Pertimbangan"
Mike Pennington

Apakah ada jawaban yang membantu Anda? jika demikian, Anda harus menerima jawabannya sehingga pertanyaan tidak terus muncul selamanya, mencari jawaban. Atau, Anda bisa memberikan dan menerima jawaban Anda sendiri.
Ron Maupin

Jawaban:


27

Jawabannya ada dalam konsep-ietf-isis-ext-eth-01 , Bagian 3-5. Ethernet menggunakan dua byte yang sama cara yang berbeda dalam enkapsulasi Ethernet II (DIX) dan 802.3:

  • Ethernet II menggunakan dua byte pertama setelah sumber alamat mac-Ethernet untuk Type
  • 802.3 menggunakan dua byte yang sama untuk bidang Panjang .

Saya menyertakan diagram beranotasi di bawah ini untuk setiap jenis bingkai, yang menunjukkan dengan tepat di mana byte yang bertentangan berada di header ethernet:

  • RFC 894 (umumnya dikenal sebagai frame Ethernet II) menggunakan byte ini untuk 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 dengan 802.2 LLC / SNAP (digunakan oleh Spanning-Tree, ISIS) menggunakan byte ini untuk Panjang

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

Enkapsulasi Ethernet II dan 802.3 harus ada pada tautan yang sama. Jika IEEE memungkinkan muatan Ethernet melebihi 1536 byte (0x600 hex), maka tidak mungkin untuk membedakan frame 802,3 LLC atau SNAP yang besar dari frame Ethernet II; Nilai tipe ethernet mulai dari 0x600 hex.

EDIT:

Saya menyertakan tautan ke salinan pdf dari spesifikasi Ethernet Versi 1 dan spesifikasi Ethernet Versi 2 , jika ada yang tertarik ...



2
Nah, frame Ethernet II memiliki tipe field mulai dari 0x0600 (dari spec IEEE 802.3x-1997) karena panjang max max 802.3 tepat di bawah itu. Jadi itu hanya efek, bukan sebab.
no

1
@nos, untuk mengklaim bahwa ini adalah efek alih-alih suatu sebab mengandaikan bahwa Anda dapat membuktikan penyebabnya ... dapatkah Anda memberikan bukti otoritatif untuk tujuan yang Anda usulkan? Spesifikasi Ethernet Versi 1 asli yang diterbitkan pada tahun 1980 sudah menggunakan bidang Tipe, dan pada tahun 1984, protokol IP ditetapkan menggunakan Ethertype 0x0800
Mike Pennington

2
Memang, ethernet I dan II spec sudah memiliki tipe field (yang pada waktu itu tidak memiliki batasan), dan sudah menentukan panjang data maks 1500 - pada waktu itu tidak ada 802,3 frame. Jadi orang tidak dapat menyimpulkan bahwa batas 1500 ditambahkan dalam spesifikasi kemudian karena bidang tipe.
no

2
@ Inos saya tidak setuju, Ethernet II harus hidup berdampingan dengan standar yang sudah ada sebelumnya. Dan itu juga mendefinisikan penggunaan bidang yang sama untuk bertindak sebagai bidang tipe dalam standar sebelumnya dan bidang panjang dalam standar baru. Mengingat bahwa TIDAK ADA kemungkinan kebingungan antara kedua standar, yang harus hidup berdampingan dalam jaringan yang sama, panjang apa pun yang dapat terlihat seperti jenis yang ada tidak akan diizinkan. Karena daftar jenis yang ada mulai pada 0x600jumlah yang kurang dari yang harus dipilih. Agar tidak ada perluasan lebih lanjut ke standar, harus ada beberapa band yang tersisa jika diperlukan.

14

Di ujung lain kisaran - 1500 byte, ada dua faktor yang menyebabkan pengenalan batas ini. Pertama, jika paket terlalu panjang, mereka menyebabkan penundaan tambahan untuk lalu lintas lainnya menggunakan kabel Ethernet. Faktor lainnya adalah perangkat keamanan yang dibangun ke dalam transceiver kabel awal bersama. Perangkat keamanan ini adalah sistem anti-celoteh.Jika perangkat yang terhubung ke transceiver mengalami kesalahan dan mulai mentransmisikan terus menerus, maka secara efektif akan memblokir lalu lintas lain dari menggunakan segmen kabel Ethernet itu. Untuk melindungi dari hal ini, transceiver awal dirancang untuk mati secara otomatis jika transmisi melebihi 1,25 milidetik. Ini sama dengan konten data yang hanya lebih dari 1500 byte. Namun, karena transceiver menggunakan timer analog sederhana untuk mematikan transmisi jika celoteh terdeteksi, maka batas 1500 dipilih sebagai perkiraan aman untuk ukuran data maksimum yang tidak akan memicu perangkat keselamatan.

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


5
Hai @ user1171: Gaya yang disukai StackExchange adalah untuk memasukkan bahan jawaban di sini, dan tautan keluar sebagai referensi. Dengan begitu, ketika tautan akhirnya membusuk, jawabannya tetap bermanfaat.
Craig Constantine

Fungsi jabber mengharuskan MAU untuk dimatikan setelah 20 hingga 150 ms selama 10 Mbit / s (IEEE 802.3 Klausul 8.2.1.5), 40 hingga 75 kbit untuk Fast Ethernet (Klausul 27.3.2.1.4) dan dua kali lipat untuk Gigabit Ethernet, jauh melebihi panjang bingkai. Pos Yahoo salah.
Zac67

10

Ketika Ethernet awalnya dikembangkan sebagai media atau bus bersama dengan 10Base5 dan 10Base2, tabrakan frame sering terjadi dan diharapkan sebagai bagian dari desain. Bandingkan hal ini dengan hari ini ketika sebagian besar semuanya diaktifkan dengan domain tabrakan terpisah dan menjalankan dupleks-penuh di mana tidak ada yang mengharapkan untuk melihat tabrakan.

Mekanisme untuk berbagi "ether" menggunakan CMSA / CD (Carrier Sense Multiple Access / Collision Detection)

Carrier Sense berarti bahwa stasiun yang ingin mentransmisikan harus mendengarkan kawat - merasakan sinyal pembawa - untuk memastikan tidak ada orang lain yang berbicara karena itu Akses Berganda pada media itu. 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. Semakin banyak byte yang ditransmisikan dalam sebuah bingkai, semakin lama semua stasiun lain harus menunggu sampai transmisi tersebut selesai. Dengan kata lain, ledakan yang lebih pendek atau MTU yang lebih kecil berarti stasiun lain mendapat lebih banyak kesempatan untuk mengirimkan dan berbagi yang lebih adil. Semakin lambat kecepatan medium transmisi (10Mb / dtk), stasiun akan memiliki waktu transmisi yang lebih lama karena MTU meningkat (jika diizinkan melebihi 1500).

Pertanyaan wajar yang menarik adalah mengapa ukuran frame minimum 64 byte? Frame ditransmisikan dalam "slot" yang 512 bit dan mengambil 51.2us untuk propagasi sinyal bolak-balik dalam medium. Sebuah stasiun tidak hanya harus mendengarkan kapan harus mulai berbicara dengan merasakan IFG (celah antarfrekuensi 96 bit), tetapi juga untuk mendengarkan tabrakan dengan bingkai lain. Collision Detection mengasumsikan keterlambatan propagasi maksimum dan menggandakannya (agar aman) sehingga tidak melewatkan transmisi yang dimulai pada waktu yang sama dari ujung kabel atau refleksi sinyal dari transmisi sendiri ketika seseorang lupa resistor terminating di ujung kabel. Stasiun tidak boleh menyelesaikan pengiriman datanya sebelum merasakan tabrakan, jadi menunggu 512 bit atau 64 byte menjamin ini.


2

Awalnya, maks. payload didefinisikan sebagai 1500 byte dalam 802.3. Ethernet v2 mendukung panjang frame> = 1536 dan inilah yang digunakan oleh implementasi IP. Sebagian besar vendor kelas operator mendukung sekitar 9000 byte ("jumbo frames") akhir-akhir ini. Karena 1500 byte adalah standar yang harus didukung oleh semua implementasi Ethernet, inilah yang biasanya ditetapkan sebagai standar pada semua antarmuka.


Anda harus google maxValidFrame, itu didefinisikan oleh IEEE; akibatnya, implementasi kerangka jumbo 9KB yang umum saat ini tidak secara resmi sesuai dengan Ethernet, tetapi mereka bekerja cukup baik untuk muatan Ethernet II
Mike Pennington

Sebenarnya, tidak sesuai 802.3. IP menggunakan Ethernet v2, jadi saya cenderung tidak memikirkan 802.3 ...

5
Jumbo tidak sesuai dengan Ethernet II atau 802.3 setelah 802.3x disahkan. 802.3x Klausul 4.2.7.1 mendefinisikan maxValidFrame pada muatan 1500B. Jadi setelah 1997, muatan apa pun yang melebihi 1500 byte tidak sesuai. Lihat surat yang dikirimkan ketua IEEE 802.3 ke IETF tentang masalah ini . Singkatnya, 802.3 jauh lebih dari standar bingkai ... itu mendefinisikan persyaratan framing dan perangkat keras. Ini berarti implementasi perangkat keras tergantung pada kepatuhan dengan format frame. Setengah Dupleks dengan CSMA-CD membutuhkan <= 1500B payloads.
Mike Pennington

-1

Frame ethernet minimum didasarkan pada Ethernet Slot Time, yang panjangnya 512 bit (64 Bytes) untuk ethernet 10M. Setelah mengurangi 18 byte untuk header ethernet dan CRC, Anda mendapatkan 46 byte payload.

Waktu Slot Ethernet ditentukan agar CSMA / CD berfungsi dengan benar. Orang harus yakin bahwa ukuran bingkai minimum tidak melebihi panjang kabel terpanjang; jika itu dilakukan, deteksi tabrakan deterministik tidak mungkin dilakukan. Setelah deteksi tabrakan pada panjang maksimum kabel, Anda memerlukan sinyal deteksi tabrakan untuk kembali ke pengirim.


3
Saya mengalami kesulitan memahami bagaimana mekanisme untuk menentukan ukuran frame ethernet minimum ada hubungannya dengan standar defacto maksimum 1500 byte saat ini. Tolong jelaskan!
Stuggi

2
@Stuggi Tidak.
Ken Sharp
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.