เหตุใดขนาด MTU สำหรับเฟรมอีเทอร์เน็ตจึงคำนวณเป็น 1500 ไบต์

38

มีการคำนวณเฉพาะใด ๆ ที่ทำเพื่อให้ถึงจำนวนนี้และอะไรคือปัจจัยที่นำมาพิจารณาในการคำนวณนั้น

ethernet mtu protocol-theory

2

คน IEEE กำลังต่อต้านการเพิ่ม 9k ลงในมาตรฐานเนื่องจากการรับประกันทางคณิตศาสตร์ FCS นำมาซึ่งวันนี้ที่ 1.5k จะไม่เป็นจริงอีกต่อไปที่ 9k

— ytti

5

@ytti นั่นเป็นเพียงหนึ่งในข้อโต้แย้งต่อการรับรอง> 1,500 เฟรม ข้อความเต็มรูปแบบของตัวอักษรเจฟฟ์ทอมสัน (ที่มีมาตรฐาน IEEE คัดค้านการสร้างมาตรฐานกรอบจัมโบ้) อยู่ในร่าง IETF-Isis-ต่อลำดับที่-01 ภาคผนวก 1 การคัดค้านเริ่มต้นด้วยคำว่า "การพิจารณา"

— Mike Pennington

คำตอบใดช่วยคุณได้บ้าง ถ้าเป็นเช่นนั้นคุณควรยอมรับคำตอบเพื่อที่คำถามจะไม่โผล่ขึ้นมาเรื่อย ๆ โดยมองหาคำตอบ หรือคุณสามารถให้และยอมรับคำตอบของคุณเอง

— Ron Maupin

27

คำตอบอยู่ในdraft-ietf-isis-ext-eth-01 , ตอนที่ 3-5 Ethernet ใช้สองไบต์เดียวกันในวิธีที่แตกต่างกันในการห่อหุ้ม Ethernet II (DIX) และ 802.3:

Ethernet II ใช้สองไบต์แรกหลังจาก mac-address ของแหล่งอีเทอร์เน็ตสำหรับชนิด
802.3 ใช้สองไบต์เดียวกันนั้นสำหรับฟิลด์ความยาว

ฉันรวมไดอะแกรมที่มีคำอธิบายประกอบไว้ด้านล่างของแต่ละประเภทเฟรมซึ่งแสดงว่าไบต์ที่ขัดแย้งกันอยู่ในส่วนหัวของอีเธอร์เน็ต:

RFC 894 (หรือที่รู้จักกันทั่วไปว่าเป็นเฟรม Ethernet II) ใช้ไบต์เหล่านี้สำหรับประเภท

   +----+----+------+------+-----+
   | 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 พร้อม 802.2 LLC / SNAP (ใช้โดย Spanning-Tree, ISIS) ใช้ไบต์เหล่านี้สำหรับความยาว

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

การห่อหุ้มทั้ง Ethernet II และ 802.3 จะต้องมีอยู่ในลิงก์เดียวกัน หาก IEEE อนุญาตให้เพย์โหลดของอีเทอร์เน็ตมีขนาดเกิน 1536 ไบต์ (0x600 ฐานสิบหก) แสดงว่าเป็นไปไม่ได้ที่จะแยกแยะเฟรม 802.3 LLC หรือ SNAP ขนาดใหญ่จากเฟรม Ethernet II ขนาดใหญ่ ค่า Type ของอีเธอร์เน็ตเริ่มต้นที่ 0x600 hex

แก้ไข:

ฉันรวมลิงค์ไปยัง pdf สำเนาของข้อมูลจำเพาะ Ethernet รุ่น 1และข้อมูลจำเพาะ Ethernet รุ่น 2ในกรณีที่ทุกคนสนใจ ...

— ไมค์เพนนิงตัน
แหล่งที่มา

2

BTW ค่าระหว่าง maxValidFrame (1500) และ "1536 ทศนิยม" ไม่ได้กำหนดในมาตรฐานอีเธอร์เน็ต พฤติกรรมของอุปกรณ์ที่ค่าเหล่านี้ไม่ได้ระบุไว้และไม่สามารถขึ้นอยู่กับ

— Mike Pennington

2

เฟรม Ethernet II มีเขตข้อมูลชนิดเริ่มต้นที่ 0x0600 (จากมาตรฐาน IEEE 802.3x-1997) เนื่องจากความยาวสูงสุดสูงสุดของ 802.3 ต่ำกว่านั้น นั่นเป็นเพียงผลกระทบไม่ใช่สาเหตุ

— nos

1

@ ไม่ได้ที่จะอ้างว่านี่เป็นผลกระทบแทนการคาดการณ์สาเหตุที่คุณสามารถพิสูจน์สาเหตุได้ ... คุณสามารถให้หลักฐานที่เชื่อถือได้สำหรับสาเหตุที่เสนอของคุณหรือไม่? ข้อมูลจำเพาะเกี่ยวกับอีเทอร์เน็ตเวอร์ชัน 1 ต้นฉบับที่เผยแพร่ในปี 1980 ได้ใช้ฟิลด์ Type แล้วและในปี 1984 ได้มีการระบุโปรโตคอล IP โดยใช้ Ethertype 0x0800

— Mike Pennington

2

แท้จริงแล้วอีเธอร์เน็ต I และ II นั้นมีฟิลด์ชนิด (ซึ่งในเวลานั้นไม่มีข้อ จำกัด ) และระบุความยาวข้อมูลสูงสุดที่ 1500 - ในเวลานั้นไม่มีเฟรม 802.3 ดังนั้นจึงไม่สามารถสรุปได้ว่ามีการเพิ่มขีด จำกัด 1500 ในข้อมูลจำเพาะในภายหลังเนื่องจากฟิลด์ประเภท

— เลขที่

2

@ ไม่ฉันไม่เห็นด้วย Ethernet II ต้องอยู่ร่วมกับมาตรฐานก่อนหน้านี้ และยังกำหนดให้ใช้เขตข้อมูลเดียวกันเพื่อทำหน้าที่เป็นทั้งเขตข้อมูลชนิดในมาตรฐานก่อนหน้าและเขตข้อมูลความยาวในมาตรฐานใหม่ เนื่องจากต้องไม่มีความสับสนระหว่างสองมาตรฐานที่จะต้องอยู่ร่วมกันในเครือข่ายเดียวกันความยาวใด ๆ ที่อาจมีลักษณะเหมือนแบบที่มีอยู่จะไม่ได้รับอนุญาต เป็นรายการประเภทที่มีอยู่เริ่มต้นที่0x600จำนวนน้อยกว่าที่จะต้องเลือก เพื่อไม่ให้มีการขยายตัวต่อไปอีกต้องมีวงดนตรีที่เหลืออยู่หากจำเป็นต้องใช้

14

ที่ปลายอีกด้านของช่วง - 1500 ไบต์มีสองปัจจัยที่นำไปสู่การเปิดตัวขีด จำกัด นี้ ขั้นแรกหากแพ็กเก็ตยาวเกินไปพวกเขาจะนำเสนอความล่าช้าเป็นพิเศษสำหรับการรับส่งข้อมูลอื่น ๆ โดยใช้สายอีเธอร์เน็ต ปัจจัยอีกประการหนึ่งคืออุปกรณ์ความปลอดภัยที่สร้างไว้ในตัวรับส่งสัญญาณเคเบิลที่ใช้ร่วมกันในช่วงต้น อุปกรณ์ความปลอดภัยนี้เป็นระบบต่อต้านการพูดพล่ามหากอุปกรณ์ที่เชื่อมต่อกับตัวรับส่งสัญญาณเกิดความผิดพลาดและเริ่มส่งสัญญาณอย่างต่อเนื่องอุปกรณ์จะป้องกันการรับส่งข้อมูลอื่น ๆ จากการใช้สายเคเบิลอีเธอร์เน็ต เพื่อป้องกันเหตุการณ์นี้ตัวรับส่งสัญญาณเริ่มต้นได้รับการออกแบบให้ปิดโดยอัตโนมัติหากการส่งสัญญาณมีค่าเกิน 1.25 มิลลิวินาที ซึ่งเท่ากับเนื้อหาข้อมูลที่มีขนาดเกิน 1,500 ไบต์ อย่างไรก็ตามในขณะที่ตัวรับส่งสัญญาณใช้ตัวจับเวลาแบบอะนาล็อกอย่างง่ายเพื่อปิดการส่งหากตรวจพบการพูดพล่ามดังนั้นขีด จำกัด 1500 ถูกเลือกเป็นการประมาณที่ปลอดภัยกับขนาดข้อมูลสูงสุดที่จะไม่เรียกอุปกรณ์ความปลอดภัย

ที่มา: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

— user1171
แหล่งที่มา

5

สวัสดี @ user1171: สไตล์ที่ต้องการของ StackExchange คือการรวมเนื้อหาคำตอบไว้ที่นี่และเชื่อมโยงเป็นข้อมูลอ้างอิง ด้วยวิธีนี้เมื่อลิงก์สิ้นสุดลงในที่สุดคำตอบก็ยังมีประโยชน์

— Craig Constantine

ฟังก์ชั่น jabber ต้องการ MAU เพื่อปิดเครื่องหลังจาก20 ถึง 150 msสำหรับ 10 Mbit / s (IEEE 802.3 ข้อ 8.2.1.5), 40 ถึง 75 kbitสำหรับ Fast Ethernet (ข้อ 27.3.2.1.4) และสองเท่าสำหรับ Gigabit Ethernet ไกลเกินความยาวกรอบ โพสต์ Yahoo ผิด

— Zac67

10

เมื่ออีเธอร์เน็ตได้รับการพัฒนาเป็นสื่อกลางที่ใช้ร่วมกันหรือบัสด้วย 10Base5 10Base2 การชนกันของเฟรมเป็นประจำและคาดว่าเป็นส่วนหนึ่งของการออกแบบ เปรียบเทียบสิ่งนี้กับทุกวันนี้เมื่อทุกอย่างถูกสลับกับโดเมนการชนกันที่แยกต่างหากและรัน full-duplex โดยที่ไม่มีใครคาดว่าจะเห็นการชน

กลไกการแบ่งปัน "ether" ที่ใช้CMSA / CD (การตรวจจับผู้ให้บริการการเข้าถึงหลายรายการ / การตรวจสอบการชนกันของข้อมูล)

Carrier Sense หมายความว่าสถานีที่ต้องการส่งสัญญาณจะต้องฟังสัญญาณรับ - ส่งสัญญาณสัญญาณของผู้ให้บริการเพื่อให้แน่ใจว่าไม่มีใครพูดเพราะมันเป็น Multiple Access บนสื่อนั้น 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. ยิ่งมีการส่งไบต์ในเฟรมมากสถานีอื่น ๆ ทั้งหมดจะต้องรอจนกว่าการส่งนั้นจะเสร็จสมบูรณ์ กล่าวอีกอย่างหนึ่งการปะทุที่สั้นลงหรือ MTU ที่เล็กลงหมายถึงสถานีอื่น ๆ มีโอกาสมากขึ้นในการส่งและแบ่งปันที่ยุติธรรม ยิ่งอัตราของสื่อการส่งสัญญาณช้าลง (10Mb / s) สถานีจะมีความล่าช้าในการส่งสัญญาณนานขึ้นเมื่อ MTU เพิ่มขึ้น (หากอนุญาตให้เกิน 1500)

คำถามควันหลงที่น่าสนใจน่าจะเป็นเพราะเหตุใดขนาดเฟรมขั้นต่ำ 64 ไบต์? เฟรมถูกส่งใน "สล็อต" ที่ 512 บิตและใช้ 51.2us สำหรับการแพร่กระจายสัญญาณไปกลับในสื่อ สถานีต้องไม่เพียงฟังเมื่อเริ่มพูดด้วยการตรวจจับ IFG (ช่องว่างระหว่างเฟรม 96 บิต) แต่เพื่อฟังการชนกับเฟรมอื่น การตรวจจับการชนกันถือว่าการหน่วงเวลาการแพร่กระจายสูงสุดและเพิ่มเป็นสองเท่า (เพื่อความปลอดภัย) ดังนั้นจึงไม่พลาดการส่งสัญญาณที่เริ่มต้นในเวลาเดียวกันจากปลายอีกด้านหนึ่งของสายไฟหรือการสะท้อนสัญญาณของการส่งสัญญาณของตัวเอง ปลายของสายเคเบิล สถานีต้องไม่ทำการส่งข้อมูลก่อนที่จะตรวจพบการชนดังนั้นการรอ 512 บิตหรือ 64 ไบต์จะรับประกันได้

— generalnetworkerror
แหล่งที่มา

2

เดิมทีแล้ว เพย์โหลดถูกกำหนดเป็น 1500 ไบต์ใน 802.3 Ethernet v2 รองรับความยาวของเฟรม> = 1536 และนี่คือสิ่งที่การใช้งาน IP ใช้ ผู้ขายระดับผู้ให้บริการส่วนใหญ่รองรับประมาณ 9000 ไบต์ ("jumbo frames") ในปัจจุบัน เนื่องจาก 1,500 ไบต์เป็นมาตรฐานที่การใช้งานอีเธอร์เน็ตทั้งหมดต้องสนับสนุนนี่คือสิ่งที่ตั้งเป็นค่าเริ่มต้นตามปกติในทุกอินเตอร์เฟส

คุณควร google maxValidFrame มันถูกกำหนดโดย IEEE; ดังนั้นการใช้งานเฟรมจัมโบ้ขนาด 9KB ที่ใช้กันทั่วไปในปัจจุบันไม่สอดคล้องกับอีเทอร์เน็ตอย่างเป็นทางการ แต่มันทำงานได้ดีสำหรับการรับส่งข้อมูล Ethernet II

— Mike Pennington

พูดอย่างเคร่งครัดไม่ใช่ตามมาตรฐาน 802.3 แม้ว่า IP ใช้ Ethernet v2 ดังนั้นฉันมักจะไม่คิด 802.3 ...

5

Jumbos ไม่สอดคล้องกับ Ethernet II หรือ 802.3 หลังจาก 802.3x ได้รับการยอมรับ 802.3x ข้อ 4.2.7.1 กำหนด maxValidFrame ที่อัตรา 1500B ดังนั้นหลังจากปี 1997 ส่วนของข้อมูลที่เกิน 1500 ไบต์จะไม่เข้ากัน ดูจดหมายที่ประธาน IEEE 802.3 ส่งถึง IETF เกี่ยวกับปัญหานี้ ในระยะสั้น 802.3 เป็นมากกว่ามาตรฐานเฟรม ... มันกำหนดทั้งข้อกำหนดการทำเฟรมและฮาร์ดแวร์ ซึ่งหมายความว่าการใช้งานฮาร์ดแวร์ขึ้นอยู่กับความสอดคล้องกับรูปแบบเฟรม Half Duplex w / CSMA-CD ต้องการ <= 1500B เพย์โหลด

— Mike Pennington

-1

เฟรมอีเธอร์เน็ตขั้นต่ำขึ้นอยู่กับเวลาสล็อตอีเธอร์เน็ตซึ่งมีความยาว 512 บิต (64 ไบต์) สำหรับ 10M อีเธอร์เน็ต หลังจากลบ 18 ไบต์สำหรับส่วนหัวอีเธอร์เน็ตและ CRC คุณจะได้รับข้อมูลจำนวน 46 ไบต์

ระบุเวลาอีเธอร์เน็ตสล็อตเพื่อให้ CSMA / CD ทำงานได้อย่างถูกต้อง ต้องแน่ใจว่าขนาดเฟรมขั้นต่ำไม่เกินความยาวของสายเคเบิลที่ยาวที่สุด ถ้ามันทำการตรวจสอบการชนกันของข้อมูลที่กำหนดจะเป็นไปไม่ได้ หลังจากการตรวจจับการชนกันที่ความยาวสูงสุดของสายเคเบิลคุณต้องมีสัญญาณการตรวจจับการชนกันเพื่อกลับไปยังผู้ส่ง

— Pooja Khatri
แหล่งที่มา

3

ฉันมีปัญหาในการทำความเข้าใจว่ากลไกในการกำหนดขนาดเฟรมอีเธอร์เน็ตขั้นต่ำนั้นเกี่ยวข้องกับมาตรฐาน defacto สูงสุด 1500 ไบต์ในปัจจุบันอย่างไร กรุณาอธิบายอย่างละเอียด!

— Stuggi

2

@Stuggi มันไม่ได้

— เคนคม