الخلاصة

  • نقطة TTL المنتهية قد تكون مستجيباً وسيطاً، لا مخرج LSP؛ لذلك لا يحوّل الرد الناجح مساراً أمامياً إلى إثبات ثنائية الاتجاه.
  • سلطة الطالب هي تحديد الحزمة، وTTL، ونمط الرد، وطلب معلومات المسار العكسي؛ سلطة المستجيب تقتصر على الرد والدليل المحلي الذي يمكنه التحقق منه.
  • يجب على الطالب فحص الواجهة ومكدس التسميات وFEC المنطبق؛ وإذا ظهر Reverse-path Target FEC Stack TLV في الاستجابة، فيجب أيضاً التحقق منه. فشل التحقق يوجب إسقاط الرد وينبغي الإبلاغ عنه.

يتيح RFC 6426 تتبع المسار وفحص CV عند الطلب لـ MPLS-TP. في تشغيل IP، تحمل الحزمة عنواناً من 127/8 وUDP داخل مكدس MPLS. أما التشغيل غير المعتمد على IP فيستخدم ACH، فلا يحتاج إلى توجيه IP. ومع reply mode 4 في ACH غير IP، يجب أن يسلك الرد LSP العكسي عبر ACH ومن دون IP/UDP؛ وإذا لم تملك العقدة مسار العودة، فينبغي لها إسقاط الطلب، ولا يجوز اختراع نجاح من الصمت أو من رد بديل.

يفصل التصميم بين Requester وResponder. الطالب يختار FEC الهدف، والـTTL، والتغليف، ونمط الرد، وما إذا كان سيضع R flag لطلب معلومات FEC العكسي. لا يجوز وضع R في استجابة Echo. عندما يكون R موجوداً في الطلب، ينبغي للمستجيب إرفاق Reverse-path Target FEC Stack TLV. ولا يجوز افتراض أن LSPين مترافقين أو ثنائيين الاتجاه لهما FEC عكسي واحد؛ فقد يستخدم LSP العكسي المرتبط FEC مختلفاً. لذلك فإن وصول رد، أو غياب R في الرد، لا يثبت وحده FEC عكسياً.

على الطالب ربط هوية المصدر والوجهة، وSource Identifier TLV وDestination Identifier TLV، والـTTL، وواجهة الاستقبال، ومكدس التسميات، وTarget FEC، ونمط الرد. وإذا ظهر Reverse-path Target FEC Stack TLV في الاستجابة، فيجب أيضاً التحقق من مطابقته للعلاقة المتوقعة. وتفيد هذه القاعدة خصوصاً في LSP وPW FECs المهيأة ثابتاً وفي المسارات غير IP. عبر الحدود الإدارية يوصي RFC 6426 بمعرّفات مصدر تسمح بترشيح مصدر غير متوقع أو مجهول. أما GAL فهو وسيلة حمل OAM: يدخل في TLVs الخاصة بالواجهة ومكدس التسميات، لكنه ليس جزء FEC الذي يُتحقق منه، ولا يأخذ Nil FEC TLV، ولا يظهر في DSMAP/DDMAP؛ لا يجوز تحويله إلى FEC الهدف.

يستخدم تتبع الطريق DSMAP/DDMAP وتغيير TTL لتوجيه الطلب إلى نقاط بعينها على LSP. مثال تحقق عملي: أرسل طلباً بنمط reply mode 4 إلى FEC ثابت محدد، مع Source Identifier وDestination Identifier معروفين، ثم كرر TTL=1 وTTL=2 وTTL=3. سجّل نقطة انتهاء TTL، وعنوان أو هوية المصدر، وواجهة الإدخال، ومكدس التسميات، وTarget FEC، ووجود R في الطلب وReverse-path TLV في الرد، وتحقق من ACH أو IP/UDP 127/8 كما يقتضي التغليف. لا تقبل النتيجة لمجرد تطابق النص أو وصول UDP. في P2MP مع عناوين IP يجب دعم إجراءات RFC 6425؛ ومن دون عناوين IP تطبق إجراءات RFC 6426 غير المعتمدة على IP، مع ربط كل رد بالفرع والهوية المناسبين.

العقدة التي لا تدعم نمط الرد المطلوب أو لا تستطيع استخدامه يجب أن تسقط الطلب. ويحذر RFC 6426 من استخدام ACH on-demand CV مع ECMP، لأن ACH قد يغير التجزئة فيسلك مساراً مختلفاً عن حركة البيانات.

هذه أداة استجواب عند الطلب، لا ضماناً مستمراً مثل آليات المراقبة المستمرة. RFC 4379 يوفّر أساس LSP ping، وRFC 5586 يحدد حمل G-ACh، وRFC 5860 يضع متطلبات OAM لـMPLS-TP، وRFC 5884 يضع BFD في سياق MPLS. أما RFC 5920 فيتناول إطار الأمن، وRFC 5921 بنية ملف النقل، وRFC 6370 المعرّفات، وRFC 6371 إطار OAM وحدود السلطة. لا تضيف هذه الأدوار دليلاً غير موجود في RFC 6426، ولا تسمح باستنتاج انتشار أو تبنٍّ أو حادثة أو قياس فقد أو زمن أو نتيجة تجارية أو نتيجة عميل.

مسار قرار المشغّل

  1. حدّد LSP أو PW FEC الثابت، المصدر والوجهة، والواجهة المتوقعة، واختَر IP/UDP أو ACH وفق نوع المسار.
  2. اختر TTL وreply mode، وحدد هل تحتاج R وReverse-path Target FEC Stack TLV، وسمِّ معيار النجاح قبل الإرسال.
  3. افحص الهوية، وTTL، والتغليف، والواجهة، ومكدس التسميات، وTarget FEC، وDSMAP/DDMAP، وFEC العكسي عند وجوده.
  4. إذا كان الرد من TTL وسيط، فاعتبره دليلاً على ذلك الموضع فقط. إذا غاب LSP العكسي فتوقع الإسقاط أو الصمت. إذا فشل أي تحقق، أسقط الرد وأبلغ بالخلل.

المصادر