الخلاصة

  • حددت RFC 2516 قيمة MTU لبروتوكول PPP داخل PPPoE عند 1492 بايتاً: استهلكت ترويسة PPPoE ستة بايتات ومعرّف بروتوكول PPP بايتين من حمولة Ethernet البالغة 1500 بايت.
  • جعلت RFC 4638 قيمة MTU/MRU الأكبر قدرة اختيارية يجري التفاوض عليها. كان على العميل ومركّز الوصول وإعداد الواجهة المحلية ومقاطع Ethernet الوسيطة دعمها كي تنقل الجلسة البايتات الثمانية الإضافية.

1500 في جزء من الطريق، و1492 في آخره

في الرسم الذي تعرضه RFC 4638، تستخدم شبكة IPoE وحدة MTU من 1500 بايت، ثم تصل إلى بوابة منزلية وخادم BRAS يشكلان طرفي جلسة PPPoE ويتفاوضان على 1492. تصف الوثيقة النتيجة بأنها عدد كبير من الحزم المجزأة. في المسار نفسه صار للرقم حدّان؛ كل جهاز التزم بحده، وظلت الحزم تدفع ثمن الفرق.

تبدو حمولة Ethernet البالغة 1500 بايت كأنها تكفي لحزمة إنترنت بالحجم نفسه. لكن PPPoE يستهلك ثمانية بايتات قبل خروج الحزمة إلى السلك: ستة لترويسته وبايتين لمعرّف بروتوكول PPP. لذلك حددت RFC 2516، الصادرة في فبراير 1999، قيمة MTU لبروتوكول PPP عند 1492 بايتاً على مقطع Ethernet قياسي.

لم تكن عملية الطرح معقدة. السؤال الأصعب كان: لماذا يُبقي مزوّد النطاق العريض على PPP بعدما أصبحت أجهزة وصول المشترك تتحدث Ethernet؟

أراد النطاق العريض Ethernet وجلسة مستقلة لكل مشترك

قدمت RFC 2516 جواباً تشغيلياً. كان Ethernet وسيلة منخفضة التكلفة لربط عدة أجهزة خلف جسر في منزل المشترك، بينما أبقى PPP التحكم في الوصول والفوترة ونموذج الخدمة لكل مستخدم. تشارك الأجهزة المنزلية وسيطاً محلياً، ويحتفظ المزوّد بجلسة PPP منفصلة لكل مشترك.

فرض هذا الترتيب رسماً من ثمانية بايتات على كل حزمة. احتفظ المزوّد بحد الجلسة، وخسرت حزمة IP الخاصة بالمشترك ثمانية بايتات من المساحة المتاحة داخل حمولة Ethernet المعتادة البالغة 1500 بايت. كتبت RFC 2516 الحد صراحة بدلاً من ترك الأجهزة تخمّن إن كان الوصل التالي يملك مساحة إضافية.

ظهر الفرق عندما توقّع أحد الطرفين وحدة PPP بحجم 1500 بايت، بينما تفاوض الطرف الآخر على 1492. وتشرح مقدمة RFC 4638 الصادرة عام 2006 أن مسارات النطاق العريض ذات الأحجام المتباينة هذه قد تنتج أعداداً كبيرة من الحزم المجزأة. كان هدف الامتداد خفض هذا التجزؤ في شبكات النطاق العريض من الجيل التالي.

أصبحت البايتات الثمانية قدرة يجري التفاوض عليها

لم تجعل RFC 4638 كل جلسة PPPoE تتجاوز 1492 بايتاً. وبالنسبة إلى تصاميم النطاق العريض من الجيل التالي التي تصفها، تشترط أن يدعم BRAS العامل خادماً لـPPPoE التفاوض فوق هذه القيمة؛ ويحدد وسم PPP-Max-Payload الاختياري ما إذا كان عميل وخادم بعينهما يستطيعان استخدام الحجم الأكبر. وتشير قيمة الوسم ذات البايتين إلى أقصى حمولة PPP يستطيع العميل دعمها في اتجاهي الإرسال والاستقبال. يدرج العميل الذي يطلب أكثر من 1492 الوسم في PADI وPADR، ويعيده الخادم القادر على تلبية الطلب في PADO وPADS.

للخادم حدّه الخاص أيضاً. تسمح RFC 4638 بالتفاوض على MRU أكبر وفق الإعداد المحلي والحد الأقصى الذي يعلنه العميل. ويجب ألا تتجاوز القيمة المختارة الأصغر بين قيمة الوسم وMTU واجهة الخادم ناقص ثمانية بايتات. يستطيع الوسم بدء التفاوض؛ لكنه لا يوسّع الواجهة فعلياً ولا يغيّر إعداد مقطع وسيط.

وهكذا تحوّل رقم واحد إلى سلسلة قرارات. يستطيع العميل أن يطلب المزيد. ولا يرد مركّز الوصول إلا بما يدعمه. وتحتاج الواجهة المحلية إلى مساحة للتغليف. ويجب أن يحمل كل مقطع Ethernet في المسار الحزمة الناتجة. ظهور 1500 بايت على شاشة المشترك لا يثبت أن كل مبدّل بين المنزل والمركّز يقبل ذلك الحجم.

للمسار فرصة كي يرفض

تصف RFC 4638 اختباراً بعد بدء الجلسة. يستطيع طرف الإرسال تمرير طلب Echo-Request بحجم MRU عبر الطرف المستقبل ومعدات Ethernet الوسيطة. إذا لم يصل Echo-Reply للاختبار الأكبر، بينما وصل رد لاختبار 1492 بايتاً، فعلى المرسل ألا يرسل حزمًا أكبر في تلك الجلسة.

هذا الرجوع مهم. إذا لم يتبادل الطرفان الوسم، أو لم يملك أحدهما إعداداً أكبر، يظل حد RFC 2516 البالغ 1492 بايتاً سارياً. وإذا أخفق المسار في اختبار الحزمة الأكبر، يمكن للاتصال العودة إلى الحد الأصغر. يبقى الاتفاق القديم أرضية صالحة للعمل، وتستطيع المسارات المتوافقة التفاوض على ما فوقها.

نشر خيار لا يعني أن معيار Ethernet اتسع

RFC 4638 وثيقة معلوماتية. وتقول ملاحظة IESG المرفقة بها إنه وقت النشر لم يكن هناك معيار IEEE نافذ يدعم الإطارات العملاقة فوق MTU قدره 1500 بايت، وتحذر من أن موثوقية الامتدادات غير القياسية وقابليتها للتشغيل البيني غير مضمونة. تستطيع أطراف PPPoE اقتراح حجم أكبر، لكن على كل منفذ Ethernet أن يقبله فعلياً.

لذلك لا تحكي القصة انتقالاً آلياً من 1492 إلى 1500. أبقت RFC 4638 الحد القديم حيث يحتاجه المسار، وحددت تبادل القدرات، ومنحت التطبيقات طريقة لاختبار الحجم الأكبر. يستطيع البروتوكول صياغة العرض؛ أما الأجهزة المشاركة والمسار الفعلي فيقرران إن كان العرض ينجح.

تسجل الوثيقتان تصميم الامتداد وهدفه في تقليل التجزؤ، لكنهما لا تحددان شبكات الوصول التي فعّلت الوسم. ويتطلب إثبات نشره في شبكة بعينها إعداداً مؤرخاً لمركّز PPPoE أو التقاطاً فعلياً لرسائل الاكتشاف.

المصادر