ईथरनेट बाइट्स के लिए MTU आकार की गणना 1500 बाइट्स के रूप में क्यों की गई थी?

38

क्या कोई विशिष्ट गणना है जो इस संख्या पर पहुंचने के लिए की गई थी, और उस गणना के लिए किन कारकों पर ध्यान दिया गया था।

ethernet mtu protocol-theory

— Padmaraj
स्रोत

2

IEEE लोग मानक में 9k जोड़ने का विरोध कर रहे हैं क्योंकि गणितीय गारंटी FCS आज 1.5k पर लाती है और सभी अब 9k पर सही नहीं होंगे।

— ytti

5

@ytti, जो केवल १४०० तख्ते के समर्थन के तर्कों में से एक है। ज्योफ थॉमसन के पत्र का पूरा पाठ (जंबो फ्रेम को मानकीकृत करने के लिए आईईईई आपत्तियों से युक्त) ड्राफ्ट-आईटीएफ-आइसिस-एक्सट-एथ -01 एपेंडिक्स 1 में है । आपत्तियां "कंसीडरेशन" शब्द से शुरू होती हैं

— माइक पेनिंगटन

क्या किसी उत्तर ने आपकी मदद की? यदि हां, तो आपको उत्तर स्वीकार करना चाहिए ताकि प्रश्न हमेशा के लिए पॉपिंग न हो जाए, उत्तर की तलाश में है। वैकल्पिक रूप से, आप अपना स्वयं का उत्तर प्रदान कर सकते हैं और स्वीकार कर सकते हैं।

— रॉन Maupin

27

इसका उत्तर ड्राफ्ट-इत्तेफ-आइसिस-एक्सट-एथ -01 , धारा 3-5 में है। ईथरनेट दो अलग-अलग तरीकों से ईथरनेट II (DIX) और 802.3 एन्कैप्सुलेशन में समान बाइट्स का उपयोग करता है:

ईथरनेट II एक प्रकार के लिए ईथरनेट स्रोत मैक-पता के बाद पहले दो बाइट्स का उपयोग करता है
802.3 लंबाई क्षेत्र के लिए उन्हीं दो बाइट्स का उपयोग करता है ।

मैं प्रत्येक फ़्रेम प्रकार के नीचे एक एनोटेट आरेख शामिल कर रहा हूं, जो दिखाता है कि ईथरनेट हेडर में परस्पर विरोधी बाइट्स कहां हैं:

RFC 894 (आमतौर पर ईथरनेट 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)

802.2 LLC / SNAP (स्पैनिंग-ट्री, ISIS द्वारा प्रयुक्त) के साथ IEEE 802.3 लंबाई के लिए इन बाइट्स का उपयोग करता है

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

ईथरनेट II और 802.3 एनकैप्सुलेशन एक ही लिंक पर मौजूद होने में सक्षम होना चाहिए। यदि IEEE ने ईथरनेट पेलोड को 1536 बाइट्स (0x600 हेक्स) से अधिक करने की अनुमति दी, तो ईथरनेट 802 फ्रेम से बड़े 802.3 LLC या SNAP फ्रेम को भेदना असंभव होगा; ईथरनेट का टाइप मान 0x600 हेक्स से शुरू होता है।

संपादित करें:

मैं ईथरनेट संस्करण 1 कल्पना और ईथरनेट संस्करण 2 युक्ति की पीडीएफ प्रतियों की एक कड़ी शामिल हूं , अगर किसी को दिलचस्पी है ...

— माइक पेनिंगटन
स्रोत

2

BTW, अधिकतम मान के बीच मान (1500) और "1536 दशमलव" ईथरनेट मानक में अपरिभाषित हैं। इन मूल्यों पर उपकरणों का व्यवहार निर्दिष्ट नहीं है और इस पर निर्भर नहीं किया जा सकता है

— माइक पेनिंगटन

2

ठीक है, ईथरनेट II फ्रेम में अपने प्रकार का क्षेत्र 0x0600 से शुरू होता है (IEEE 802.3x-1997 कल्पना से) क्योंकि 802.3 की अधिकतम लंबाई इसके ठीक नीचे थी। तो यह सिर्फ एक प्रभाव है, एक कारण नहीं है।

— nos

1

@nos, यह दावा करने के लिए कि यह एक कारण के बजाय एक प्रभाव है जो यह बताता है कि आप कारण साबित कर सकते हैं ... क्या आप अपने प्रस्तावित कारण के लिए आधिकारिक प्रमाण प्रदान कर सकते हैं? 1980 में प्रकाशित मूल ईथरनेट संस्करण 1 युक्ति पहले से ही टाइप फ़ील्ड का उपयोग करता है, और 1984 में, आईपी प्रोटोकॉल Ethertype 0x0800 का उपयोग करके निर्दिष्ट किया गया था

— माइक पेनिंगटन

2

वास्तव में, ईथरनेट I और II युक्ति में पहले से ही एक प्रकार का फ़ील्ड था (जो उस समय कोई प्रतिबंध नहीं था), और पहले से ही अधिकतम डेटा लंबाई 1500 निर्दिष्ट करता है - उस समय कोई 802.3 फ्रेम नहीं था। इसलिए कोई यह निष्कर्ष नहीं निकाल सकता है कि प्रकार की फ़ील्ड के कारण बाद की कल्पना में 1500 की सीमा जोड़ी गई थी।

— nos

2

@nos I असहमत है, ईथरनेट II को preexisting मानक के साथ मिलकर काम करना था। और यह उसी क्षेत्र के उपयोग को परिभाषित करता है जो पूर्व मानक में एक प्रकार का क्षेत्र और नए मानक में लंबाई क्षेत्र दोनों के रूप में कार्य करता है। यह देखते हुए कि दोनों मानकों के बीच भ्रम की कोई संभावना नहीं है, कि एक ही नेटवर्क में सह-अस्तित्व होना चाहिए, किसी भी प्रकार जो किसी मौजूदा प्रकार की तरह दिख सकता है, की अनुमति नहीं होगी। जैसा कि मौजूदा प्रकार की सूची 0x600से कम संख्या में शुरू किया गया था, जिसे चुना जाना था। मानक के आगे विस्तार के लिए अनुमति देने के लिए कुछ बैंड को उपलब्ध होना चाहिए था जिसे इसकी आवश्यकता होनी चाहिए।

14

सीमा के दूसरे छोर पर - 1500 बाइट्स, दो कारक थे जो इस सीमा की शुरूआत की ओर ले जाते हैं। सबसे पहले, यदि पैकेट बहुत लंबे हैं, तो वे ईथरनेट केबल का उपयोग करके अन्य ट्रैफ़िक के लिए अतिरिक्त देरी का परिचय देते हैं। अन्य कारक एक सुरक्षा उपकरण था जिसे शुरुआती साझा केबल ट्रांससीवर्स में बनाया गया था। यह सुरक्षा उपकरण एक एंटी-बबल सिस्टम था।यदि एक ट्रांसीवर से जुड़ा डिवाइस में एक खराबी विकसित हुई और लगातार प्रसारण शुरू हो गया, तो यह प्रभावी रूप से किसी अन्य ट्रैफ़िक को उस ईथरनेट केबल सेगमेंट का उपयोग करने से रोक देगा। ऐसा होने से बचाने के लिए, प्रारंभिक ट्रांससीवर्स को स्वचालित रूप से बंद करने के लिए डिज़ाइन किया गया था यदि ट्रांसमिशन लगभग 1.25 मिलीसेकंड से अधिक हो। यह सिर्फ 1500 बाइट्स की डेटा सामग्री के बराबर है। हालांकि, जैसा कि ट्रांसीवर ने ट्रांसमिशन को बंद करने के लिए एक सरल एनालॉग टाइमर का उपयोग किया था यदि बबलिंग का पता चला था, तो 1500 सीमा को अधिकतम डेटा आकार के लिए एक सुरक्षित सन्निकटन के रूप में चुना गया था जो सुरक्षा उपकरण को ट्रिगर नहीं करेगा।

स्रोत: http://answers.yahoo.com/question/index?qid=20120729102755AAn892

— user1171
स्रोत

5

Hi @ user1171: StackExchange पसंदीदा शैली यहाँ उत्तर सामग्री को शामिल करना है, और संदर्भ के रूप में लिंक करना है। इस तरह, जब लिंक अंततः घूमता है, तो उत्तर अभी भी उपयोगी है।

— क्रेग कॉन्स्टेंटाइन

जैबर फंक्शन के लिए MAU को 10 Mbit / s (IEEE 802.3 क्लाज 8.2.1.5) के लिए 20 से 150 ms के बाद बंद करने की आवश्यकता थी , फास्ट ईथरनेट के लिए 40 से 75 kbit (क्लाज 27.3.2.1.4) और दो बार गिगाबिट ईथरनेट के लिए, दूर फ्रेम लंबाई से अधिक है। याहू पोस्ट गलत है।

— Zac67

10

जब ईथरनेट मूल रूप से 10Base5 10Base2 के साथ एक साझा माध्यम या बस के रूप में विकसित किया गया था, तो फ्रेम के टकराव अक्सर और डिजाइन के भाग के रूप में अपेक्षित थे। इसके विपरीत आज तक जब अधिकांश सब कुछ अलग-अलग टकराव डोमेन के साथ स्विच किया जाता है और पूर्ण-द्वैध चलता है, जहां कोई भी टकराव देखने की उम्मीद नहीं करता है।

"ईथर" को साझा करने का तंत्र CMSA / CD (कैरियर सेंस मल्टीपल एक्सेस / कोलिशन डिटेक्शन) को साझा करता है

कैरियर सेंस का मतलब था कि एक स्टेशन जो संचारित करना चाहता है उसे तार - वाहक संकेत को सुनना चाहिए - यह सुनिश्चित करने के लिए कि कोई और बात नहीं कर रहा था क्योंकि यह उस माध्यम पर मल्टीपल एक्सेस था। 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 लिया। एक स्टेशन को न केवल यह सुनना होता है कि कब आईएफजी (96 बिट्स की इंटरफ़्रेम गैप) को समझकर बात करना शुरू करना है, बल्कि अन्य फ़्रेमों के साथ टकराव के लिए सुनना है। टकराव का पता लगाने से अधिकतम प्रसार में देरी होती है और यह (सुरक्षित होने के लिए) दोगुना हो जाता है, इसलिए यह तार के दूसरे छोर से उसी समय शुरू होने वाले ट्रांसमिशन को याद नहीं करता है या अपने स्वयं के ट्रांसमिशन का सिग्नल रिफ्लेक्शन करता है जब कोई व्यक्ति रोकनेवाला को भूल जाता है। केबल के छोर। टकराव को महसूस करने से पहले स्टेशन को अपना डेटा भेजना पूरा नहीं करना चाहिए, इसलिए 512 बिट्स या 64 बाइट्स की प्रतीक्षा करना इस बात की गारंटी देता है।

— generalnetworkerror
स्रोत

2

मूल रूप से, अधिकतम। 802.3 में पेलोड को 1500 बाइट के रूप में परिभाषित किया गया था। ईथरनेट v2> = 1536 की फ्रेम लंबाई का समर्थन करता है और यह वही है जो आईपी कार्यान्वयन का उपयोग करता है। अधिकांश वाहक-श्रेणी के विक्रेता इन दिनों लगभग 9000 बाइट्स ("जंबो फ्रेम") का समर्थन करते हैं। चूंकि 1500 बाइट मानक है जो सभी ईथरनेट कार्यान्वयन का समर्थन करना चाहिए, यह वही है जो आम तौर पर सभी इंटरफेस पर डिफ़ॉल्ट रूप से सेट किया गया है।

आपको Google को अधिकतमValidFrame चाहिए, यह IEEE द्वारा परिभाषित किया गया था; नतीजतन, 9KB जंबो फ्रेम कार्यान्वयन जो आज आम हैं, आधिकारिक तौर पर ईथरनेट के अनुरूप नहीं हैं, लेकिन वे ईथरनेट II पेलोड के लिए काफी अच्छी तरह से काम करते हैं

— माइक पेनिंगटन

कड़ाई से बोलना, 802.3-आज्ञाकारी नहीं। IP हालांकि ईथरनेट v2 का उपयोग करता है, इसलिए मैं 802.3 के बारे में भी नहीं सोचता हूं ...

5

802.3x की पुष्टि के बाद जुंबोस ईथरनेट II या 802.3 के अनुरूप नहीं हैं। 802.3x क्लॉज 4.2.7.1 अधिकतम 1500 बी पेलोड पर विलीफ्रेड को परिभाषित करता है। इस प्रकार 1997 के बाद, 1500 बाइट से अधिक का कोई भी पेलोड आज्ञाकारी नहीं है। इस मुद्दे के बारे में आईईईटी 802.3 के अध्यक्ष को IETF को भेजे गए पत्र को देखें । संक्षेप में, 802.3 एक फ्रेम मानक से बहुत अधिक है ... यह फ्रेमिंग और हार्डवेयर आवश्यकताओं दोनों को परिभाषित करता है। इसका अर्थ है कि हार्डवेयर कार्यान्वयन फ्रेम प्रारूप के अनुपालन पर निर्भर करता है। हाफ डुप्लेक्स डब्ल्यू / सीएसएमए-सीडी की जरूरत है <= 1500B पेलोड।

— माइक पेनिंगटन

-1

न्यूनतम ईथरनेट फ्रेम ईथरनेट स्लॉट टाइम पर आधारित है, जो 10M ईथरनेट के लिए 512 बिट लंबाई (64 बाइट्स) है। ईथरनेट हेडर और सीआरसी के लिए 18 बाइट्स घटाने के बाद, आपको पेलोड के 46 बाइट्स मिलते हैं।

ईथरनेट स्लॉट का समय निर्दिष्ट किया गया था ताकि CSMA / CD सही ढंग से कार्य कर सके। एक को यह सुनिश्चित करना चाहिए कि न्यूनतम फ्रेम का आकार केबल की सबसे लंबी संभव लंबाई से अधिक नहीं है; यदि यह नियतात्मक टकराव का पता लगाता है तो असंभव होगा। केबल की अधिकतम लंबाई पर टक्कर का पता लगाने के बाद, आपको प्रेषक को वापस जाने के लिए टकराव का पता लगाने वाले संकेत की आवश्यकता होती है।

— पूजा खत्री
स्रोत

3

मुझे यह समझने में परेशानी हो रही है कि न्यूनतम ईथरनेट फ्रेम आकार के निर्धारण के लिए तंत्र का मौजूदा 1500 बाइट अधिकतम डिफैक्टो मानक के साथ क्या करना है। कृपया विस्तार से बताएं!

— स्टुग्गी

2

@Stuggi यह नहीं है।

— केन शार्प