الخلاصة

  • خصص RFC 3429 القيمة المحجوزة 14 في MPLS لوسم OAM Alert كي يعرّف حزم OAM في مستوى المستخدم، من دون أن يجعل هذا التخصيص بديلاً عن وظائف التوصية Y.1711.
  • في حالة PHP التي يغطيها النص، تزيل العقدة قبل الأخيرة الوسم الأعلى المعتاد لكنها تمرر وسم OAM وحمولته إلى مخرج MPLS يدعم OAM. أما العقدة التي لا تستطيع معالجة الوسوم فهي حالة مختلفة لم تكن وظائف Y.1711 آنذاك تغطيها.
  • يساعد TTSI داخل الحزمة على تحديد موجّه LSR عند الدخول الذي أرسلها؛ لكنه لا يثبت سلامة LSP أو وصول بيانات العميل أو معالجة إنذار.

الوسم الضمني الفارغ (implicit-null، القيمة 3) لا يظهر في الحزمة. إنه إشارة في مستوى التحكم تطلب من موجّه LSR قبل الأخير أن يزيل الوسم الأعلى بدلاً من استبداله. تسمح هذه العملية، المعروفة باسم PHP، لمخرج MPLS بتجنب بحث إضافي. لكن إزالة الوسم لا تضمن أن العقدة النهائية ستعرف معنى كل ما تبقى في المكدس.

جاء RFC 3429 بقيمة مختلفة تؤدي وظيفة التعريف داخل الحزمة نفسها: الرقم 14 من القيم المحجوزة في RFC 3032 أصبح OAM Alert Label. يستطيع هذا الوسم تمييز حزم MPLS OAM في مستوى المستخدم عن الحزم العادية. لكنه ليس آلية مراقبة كاملة، ولا يحدد وحده كل وظيفة تحملها الحمولة، ولا يلزم كل موجّه بتطبيقه.

ثلاثة أدوار لا تؤديها وثيقة واحدة

توزّع الوثائق العمل. تحدد توصية ITU-T Y.1711 وظائف OAM وبنية الحمولة. يشرح RFC 3031 معمارية MPLS وآلية PHP. ويخصص RFC 3429 رقماً في فضاء الوسوم يساعد على تصنيف الحزمة عند وصولها. هذه واجهات متكاملة، وليست إثباتاً واحداً لسلامة شبكة أو خدمة.

في الحالة الأولى التي يصفها RFC 3429، تظل العقدة النهائية موجّه LSR يدعم مستويي التحكم والبيانات، لكنها تطلب PHP لأنها لا تستطيع تنفيذ بحثين للوسوم بسرعة الخط. تنزع العقدة قبل الأخيرة الوسم الأعلى، وتترك وسم OAM والحمولة سليمتين. إذا كان المخرج يدعم MPLS OAM، فإنه يرى الوسم 14 في أعلى المكدس المتبقي ويفهم أن عليه معالجة حزمة صيانة.

يحمل محتوى OAM أيضاً معرّف TTSI (معرّف مصدر إنهاء المسار)، الذي يعرّف موجّه الدخول الذي أنشأ الحزمة وفق الآلية الموضحة. لذلك لا يختفي مرجع المصدر عندما يزيل PHP وسم التوجيه الأعلى. لكن المعرّف لا يخبر المشغّل بأن كل قفزة مرّت بلا خطأ، ولا أن مسار العودة يعمل، ولا أن تطبيقاً بعيداً تلقى بيانات المستخدم. تحديد أصل الفحص ليس مرادفاً لنتيجته.

طلب PHP لا يعني قدرة موحدة عند النهاية

في الحالة الثانية، لا تملك العقدة النهائية قدرة البحث عن وسوم MPLS أو معالجتها، ولا تتعرف إلى الحزم الموسومة. يمكنها أيضاً طلب implicit-null وPHP، لكن هذا الطلب لا يحولها إلى طرف OAM. ينص RFC 3429 على أن وظائف Y.1711 المتاحة آنذاك تنطبق على الحالة الأولى فقط، وأن تطبيقها على الحالة الثانية يحتاج إلى دراسة إضافية. وترك النص كذلك سيناريوهات carrier supporting carrier لأعمال لاحقة.

إذا وصل OAM إلى موجّه LSR نهائي لا يدعم MPLS OAM، يذكر RFC 3429 أن الحزمة تُسقط. وهذا يخلق نقصاً في الرؤية، لكنه لا يبرر تفسير الصمت على أنه صحة للمسار أو دليل على أن PHP هو سبب الخلل. ويحذر RFC 3031 من إزالة وسم غير معروف بلا تحقق ثم تمرير الباقي كحزمة IP عادية؛ فقد يحمل الوسم معنى توجيهياً لا يمكن استنتاجه من ترويسة IP. الإسقاط قد يكون أكثر أماناً من تخمين المعنى، لكنه يترك فجوة مراقبة.

سجل الأرقام لا يثبت التطبيق

ما زال سجل IANA لقيم وسوم MPLS يربط القيمة 14 بوسم OAM Alert ويشير إلى RFC 3429. يحفظ السجل هذا المعنى المشترك بين المواصفات، لكنه لا يسرد الموجّهات التي تطبق Y.1711 اليوم، ولا يبيّن أي مسار يستخدم PHP، ولا يشرح كيف تسجل منصة بعينها إسقاط الحزمة.

RFC 3429 وثيقة معلوماتية نشرت في نوفمبر 2002، وليست تقريراً عن الانتشار أو الأداء. أهميتها التاريخية أنها تصل بين آلية OAM في توصية ITU-T، وتخصيص رقم MPLS لدى IETF، وحدود قدرة مخرج المسار بعد PHP. التخصيص يتيح التعرف المتوافق؛ ولا ينفذ المراقبة نيابة عن الجهاز.

يتطلب تقييم مسار فعلي أدلة منفصلة: الوسم الذي أعلنه المخرج، عملية PHP التي نفذتها العقدة قبل الأخيرة، مكدس الوسوم المستلم، دعم OAM في الطرف النهائي، مطابقة TTSI مع موجّه الدخول، ونتيجة وظيفة OAM المحددة. كما يحتاج وصول بيانات العميل إلى دليل مستقل. تسجيل الوسم 14، وتمكين OAM، وظهور LSP بحالة نشطة ليست عبارات مختلفة للقول إن العميل تلقى الخدمة.

المصادر