الخلاصة

  • يحدد RFC 5332 عنوان الوجهة متعدد البث لـ MPLS بصيغة 01-00-5e-8v-wx-yz. يمكن أن تكون vwxyz صفراً أو قيمة وسم؛ وإذا تعددت الوسوم فالثاني هو الافتراضي مع جواز اختيار غيره بالإعداد.
  • الطريقتان صحيحتان ويجب أن تتوافقا. لا تثبت اللاحقة هوية المتلقي أو عضوية المجموعة أو قبول الحزمة أو تسليم الخدمة، ولا يجوز رفض كل القيم الصفرية أو كل القيم غير الصفرية.

الرقم القريب من المتلقي ليس المتلقي

لنتصور تقريراً يجمع عناوين MAC من منفذ مشترك. يرى 01-00-5e-8a-bc-de فيسجل abcde باعتباره «مجموعة العملاء». بعد ذلك يضاعف العدد عند تغير اللاحقة ويعلن اتساع نطاق الأثر.

لكن RFC 5332 لا يضع هوية عميل في هذه البتات. إذا اختار المرسل طريقة الاشتقاق، فقد تكون اللاحقة قيمة الوسم الثاني في المكدس. وإذا اختار الطريقة الأخرى تكون صفراً. أما عضوية Ethernet multicast، وقرار LSR، ومدخل NHLFE، والنسخ إلى المخارج، والاستقبال النهائي فهي حالات أخرى.

القرب البصري لا ينشئ علاقة. اللاحقة تقع داخل عنوان الوجهة، لكنها لا تختصر جميع الجهات التي قد تستقبل أو تقبل أو تستخدم الحزمة.

هناك سياستان معياريتان لا صيغة واحدة مثالية

يجوز للـ LSR ضبط vwxyz على صفر. ويجوز له نسخ قيمة وسم من المكدس. عند وجود وسمين أو أكثر، يستخدم الوسم الثاني افتراضياً، ويمكن للإعداد اختيار وسم آخر. عند وجود وسم واحد يستخدم ذلك الوسم.

يجب أن تعمل الأجهزة التي تختار الطريقتين معاً. لا يجوز للجهاز أن يرشح كل الحزم ذات اللاحقة الصفرية، ولا أن يرفض بلا تمييز كل لاحقة غير صفرية. المعيار يحمي التوافق بين خيارين محليين.

إذا درّب مرشح نفسه على شكل واحد ثم سمّى الآخر «شاذاً»، فالمشكلة ليست دليلاً على سوء المرسل. إنها سياسة محلية لم تحفظ مساحة التوافق التي أوجبها RFC.

0x8848 لم يعد يعني ما يوحي به اسمه القديم

وصف RFC 3032 قيمتين في طبقة الوصلة على أنهما MPLS أحادي البث ومتعدد البث. يبين RFC 5332 أن استعمال قيمة متعدد البث لم يُنشر وأن التطور اللاحق احتاج إلى تمييز آخر، لذلك أُلغي المعنى القديم.

يمكن أن تحمل 0x8847 و0x8848 حزم MPLS متعددة البث. في إطار Ethernet متعدد البث، تستخدم 0x8847 عندما يكون الوسم الأعلى معيناً من جهة downstream، وتستخدم 0x8848 عندما يكون معيناً upstream.

صفة متعدد البث تنشأ من دلالة NHLFE داخل سياق معين: المدخل يطلب النسخ إلى مجموعة next hops. حتى إن كان للمجموعة عضو واحد حالياً، تبقى الدلالة نسخاً إلى جميع الأعضاء. codepoint يخبر عن منشأ تعيين الوسم، لا عن جمهور كامل.

منشأ التعيين يفتح سؤال السياق

في تعيين downstream ينشئ المستقبل الربط بين الوسم وFEC ثم يعلنه للمرسل. في تعيين upstream ينشئه المرسل أو طرف ثالث. قد لا يعيش الوسم upstream في مساحة الوسوم نفسها، ولذلك يقدم RFC 5331 قواعد السياق اللازمة لتفسيره.

وجود 0x8848 الصحيح لا يثبت أن المستقبل اختار السياق الصحيح. كما لا يثبت أن الطرف downstream يدعم الميزة. RFC 5332 يجعل upstream assignment اختيارياً ويمنع استعماله دون معرفة الدعم، لكنه يترك طريقة اكتساب هذه المعرفة خارج نطاقه.

يجب أن يحمل سجل القرار هوية الطرف، ودليل قدرته ووقته، وعقد التعيين، ومفتاح السياق، والمكدس الخام، ونتيجة lookup. من دون ذلك يصبح codepoint الصحيح غطاءً لقرار غير مثبت.

الوسائط الأخرى لا تعطي البت نفسه

في PPP تكون قيمة Protocol دائماً 0x0281 عند نقل MPLS. في التغليف المباشر داخل IP تكون قيمة Protocol Number أو Next Header دائماً 137 سواء حملت MPLS دلالة متعدد البث أم لا.

في GRE مع وجهة IP أحادية تستخدم 0x8847 دائماً. مع وجهة متعددة تستخدم 0x8847 للوسم المعين downstream و0x8848 للوسم المعين upstream. وإذا أثبت عقد خارجي أن النفق المتعدد يتطلب upstream، فإن 0x8847 يصبح خطأ ويجب إسقاط الحزمة.

مخطط بيانات واحد لا يجوز أن يدعي أن جميع الوسائط تقدم معلومة assignment نفسها. عليه أن يفرق بين observed وcontract-derived وdefaulted وunknown.

إسقاط الحزمة لا يثبت من تضرر

قاعدة MUST discard تحدد ما ينبغي للمستقبل فعله في تركيبة GRE معينة. لا تثبت أن الحزمة وصلت إلى ذلك المستقبل، أو أن إصدار البرنامج نفذ القاعدة، أو أن مساراً بديلاً لم يوجد، أو أن خدمة فقدت تسليماً.

وبالمثل يحذر RFC من أن تغيير codepoint بسوء نية قد يسبب فقداً أو misrouting، لكنه يقول إن تغيير codepoint وحده من دون تغيير الوسم لا يعطي أثراً متوقعاً. تغيير MAC DA قد يرسل الحزمة إلى طرف ثالث، لكنه لا يثبت أن الطرف استلمها.

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

العنوان المسجل لا يحكم العضوية

حجزت IANA المجال من 01-00-5e-80-00-00 إلى 01-00-5e-8f-ff-ff لاستخدام Ethernet متعدد البث مع MPLS multicast، وهو صالح مع 0x8847 و0x8848. هذا تنسيق ضروري حتى لا تتصادم الاستخدامات.

لكن الحجز لا يقرر أعضاء المجموعة ولا سياسة التصفية ولا ملكية الخدمة. السجل المشترك ينسق الرمز؛ التنفيذ المحلي يقرر ضمن الحدود؛ والرصد يثبت ما وقع.

تحويل السجل إلى دليل جمهور يكرر خطأ أوسع: اعتبار السجل مؤلفاً للواقع بدلاً من كونه شاهداً محدوداً عليه. السلطة التقنية هنا رفيعة ومقصودة، ولا ينبغي تضخيمها.

سجل التحويل الدلالي يحمي الماضي

قيم EtherType بقيت، لكن معناها تغير بين RFC 3032 وRFC 5332. لذلك يحتاج كل parser إلى semantic version يحدد الوثيقة والشروط والمعنى القديم الملغى والمعنى الحالي والتركيبات غير الصالحة.

يجب الاحتفاظ بالإطار الخام مع medium، outer address، codepoint، label stack، عقد assignment، proof of peer support، context، NHLFE، اشتقاق MAC، filter decision، replication، reception وservice result.

عند تحديث parser ينبغي تشغيل العينات نفسها قبل وبعد التغيير، ومعرفة أي قواعد وdashboards تعتمد على الاسم القديم. إذا حُذفت البتات الأصلية، يصبح التصحيح مستحيلاً ويظل وصف قديم هو التاريخ الوحيد.

نطاق الأثر يبدأ بعد اللاحقة لا داخلها

لقياس أثر خلل في MAC DA، نحتاج معرفة منافذ layer 2 التي تلقت الإطار، والأجهزة التي قبلته، والـlabel lookup الذي جرى، والمخارج التي نُسخ إليها، والتدفقات والخدمات التي كانت تعتمد عليه، والنتيجة في نافذة زمنية محددة.

قد تزيد لاحقة واحدة نطاق layer 2 من دون أن يقبل أي LSR الحزمة. وقد تقبلها عقدة ولا تحمل خدمة. وقد يكون للعميل مسار بديل. لهذا لا يتحول عدد عناوين أو suffixes إلى عدد عملاء.

القرار القيادي الجيد لا يقلل من أهمية الحقل. بل يبقيه دقيقاً حتى لا تفقد التحقيقات ثقتها بكل المنصة عندما ينكشف أول استنتاج زائد.

المصادر