الخلاصة

  • تحدد RFC 9892 حقل VID بطول 12 بت: تعني 0x000 تجاهل VLAN، وتحجز 0xFFF، وتنهي القيم الصريحة عند 0xFFE.
  • تلزم RFC 9895 بهذه المعالجة، لكنها تكتب في قسم الإدارة 0x0000 و0xFFFF والنطاق 0x00010xFFFE؛ ولم يعرض بحث RFC Editor تصحيحاً مطابقاً وقت المراجعة.

يمكن أن يوافق نظام الإدارة على قيمة، ويحفظها، ويعلن نجاح العملية، ثم يرسل الجهاز قيمة أخرى. لا يحتاج هذا الانفصال إلى عطل ظاهر؛ يكفي أن يقبل أحد المكونات 16 بت بينما لا يملك تنسيق الحزمة إلا 12.

تعرف RFC 9895 امتداد IEEE 802.1Q Aware Credit Window في DLEP. يقدم المودم إلى الموجّه تصنيفاً يربط وجهة DLEP وVLAN وPCP بنافذة رصيد منطقية، مشتركة أو مخصصة. ولا يرسل الموجّه حركة إلى المودم بلا رصيد كافٍ.

لا تنشئ الوثيقة صيغة تصنيف جديدة. فهي تعتمد RFC 9892 للتصنيف وRFC 9893 لنوافذ الرصيد. ومن يعلن Extension Type 5 يجب أن يدعم الرسائل وData Items والمعالجة ذات الصلة في الوثيقتين.

تقسم RFC 9892 كلمة من 16 بت إلى أربعة بتات لـNumPCPs و12 بت لـVID. ويوافق النص الرسم: الصفر 0x000 يلغي VID من شرط المطابقة، و0xFFF محجوز، والمدى الصريح من 0x001 إلى 0xFFE.

أما القسم 3 في RFC 9895 فيكتب الصفر 0x0000، ويحجز 0xFFFF، ويسمح من 0x0001 إلى 0xFFFE. تحتاج الحدود العليا إلى 16 بت. يظهر النص نفسه في HTML وXML الرسميين، فلا يتعلق بعرض صفحة واحدة. وأظهر بحث التصحيحات أنه لا توجد نتيجة مطابقة عند إعداد التقرير.

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

على السلك، توفر علاقة الاعتماد تفسيراً عملياً واضحاً. تلزم RFC 9895 بمعالجة RFC 9892، والأخيرة لا تملك مكاناً للبت الثالث عشر. لذلك ينبغي رفض أي VID صريح فوق 0xFFE قبل التسلسل، لا توسيع الحزمة ولا إسقاط البتات بصمت.

فالإسقاط قد ينتج قيمة صحيحة مختلفة. تتحول 0x1001 بعد قناع 12 بت إلى VLAN 1. وإذا احتفظت قاعدة البيانات بالقيمة الأصلية بينما ثبّت المودم الرقم المختصر، فسوف يصف سجل التدقيق نية مستحيلة ويطبق مستوى البيانات تصنيفاً حقيقياً آخر.

قد يرفض تنفيذ آخر القيمة عند التحديث، أو يعيد ضبط الجلسة، أو يحولها وفق نوع عددي في عتاد الشبكة. هذه احتمالات اختبار وليست حوادث معلنة. والهدف هو إثبات أول نقطة رفض ومنع أي تطبيع غير ظاهر.

تزيد أولوية المطابقة من الأثر. عندما يطابق الإطار تصنيف Ethernet وDiffserv معاً، تعطي RFC 9892 الأسبقية لـVLAN/PCP. وبذلك يمكن لقيمة Ethernet مختصرة أن تتغلب على نافذة DSCP صحيحة من RFC 9894.

كما قد تخفي القاعدة العامة المشكلة. تحذر RFC 9895 من أن wildcard لـVID أو PCP قد يلتقط تدفقات غير متوقعة أو جديدة بعد إعداد السياسة. فإذا فشل الشرط الصريح وتولت النافذة الافتراضية، تنجح تجربة الاتصال وتتغير العزلة وتوزيعات الرصيد.

ولا يحسم تفاوض الامتداد حدود واجهة الإدارة. يعلن الطرفان الدعم عند تهيئة DLEP. وقد يستخدم الموجّه مجموعة فرعية من النوافذ إذا تجاوز إعلان المودم قدرته، أو يعيد ضبط الجلسة، وينبغي إظهار عدم التطابق للمستخدم. يجب تطبيق المبدأ نفسه على VID مرفوض أو مقنّع.

يبدأ اختبار المطابقة بقبول 0x001 و0xFFE ورفض 0xFFF و0x1000 و0xFFFF والقيم السالبة والبتات العليا. لا يقبل الصفر إلا بمعنى تجاهل VID. ثم يقارن الطلب والحالة المخزنة والبايتات المرسلة وتحليل الطرف الآخر والقاعدة المثبتة والقراءة الراجعة.

ويجب اختبار اجتماع Ethernet وDSCP، والشرط الصريح مقابل wildcard، وإعادة الاتصال، وتقليل عدد النوافذ، ونفاد الرصيد. تجيب RFC 9893 عن إذن الإرسال نحو المودم؛ لا تصلح تصنيفاً خاطئاً ولا تثبت التسليم. وتفصل RFC 2475 كذلك بين التصنيف والتهيئة والسلوك عند كل قفزة والخدمة.

يسجل سجل IANA لـDLEP الرمز 5، لكنه لا يرى ما تقبله شاشة المورد. تعيد فكرة Lu Heng عن أولوية الشفرة العاملة الدليل إلى الانتقال المنفذ. وتحصر المواصفة الأولية الدنيا المشترك في قاعدة قابلة للفحص، بينما تمنع طبقات الواقع مكانة الوثيقة من الحلول محل نتيجة الجهاز.

لا تستطيع شفرة محلية تصحيح RFC سراً. تستطيع فرض حد 12 بت وتوثيق تفسيرها وتشغيل الاختبارات السلبية ورفع التناقض إلى مسار errata. والسؤال الإداري الحاسم هو: أين يُرفض البت الثالث عشر علناً قبل أن يتحول إلى VLAN آخر يعمل فعلاً؟

المصادر