الخلاصة

  • يسمح مثال الترحيل في RFC 9689 للعقد القديمة بالاستمرار في LDP أو RSVP-TE، بينما تتلقى العقد الجديدة تعليمات مباشرة من PCECC، ويعمل المتحكم وكيلاً عند الحد الفاصل.
  • الوكيل يحقق التوافق ولا يخلق التزاماً شاملاً واحداً؛ لذلك يلزم ربط الهويات، وإيصالات كل عقدة، وتفويض التحويل عند المدخل، وحيازة الحالة اليتيمة، وإثبات التنظيف.

يصف RFC 9689 في الملحق A.1 ترحيلاً تدريجياً لا يفرض استبدال كل العقد دفعة واحدة. تعمل Node1 وNode2 وNode3 بالإشارات القديمة، ويمكن لـNode3 أن تؤدي وظيفة الوكيل. بعدها يبرمج PCECC مقطع الخروج في Node3، ومقطعي الدخول والخروج في Node4، ومقطع الدخول في Node5.

ما يبدو للحزمة مساراً واحداً يبقى في سجل التشغيل قصتين مختلفتين. على الجانب القديم توجد مجاورة LDP أو حجز RSVP-TE ورسائل وجداول محلية. وعلى الجانب الجديد توجد جلسات PCEP وتعليمات تحكم مركزية ومعرّفات CC-ID وتقارير PCRpt. الوكيل يربط القصتين؛ لا يحوّلهما إلى حالة واحدة.

ويجب عدم تجاوز حدود المصدر. RFC 9689 وثيقة معلوماتية، ويذكر الملحق أن هذه الحالات لم تكن قيد تطوير نشط عند النشر. المثال أداة تحليل معماري، لا دليلاً على تنفيذ منتج أو نجاح مشغل أو حادثة واقعية.

لكل جانب هوية زمنية مختلفة

يحدد RFC 9050 أن CC-ID فريد داخل جلسة PCEP، ويربط PLSP-ID والمصدر وتعريف LSP التعليمات الموزعة على العقد. لكن أياً من هذه الإحداثيات لا يعيد تلقائياً هوية حالة LDP أو RSVP-TE القديمة.

لهذا يحتاج الحد الفاصل إلى دفتر مطابقة قابل للتصدير: طلب التغيير، والخدمة، وهوية LSP القديمة، والعقدة والواجهة الحدّية، وما تلقاه الوكيل، وقاعدة التحويل، وما أرسله، وهوية PCE، والجلسة، وكل CC-ID، واتجاه التسمية، وجيل التغيير، وجيل الرجوع. يجب الاحتفاظ بالمدخل والقرار والمخرج منفصلة؛ فالفرق بينها هو الدليل على عمل الوكيل.

غياب هذا الدفتر لا يعني بالضرورة أن قيم التسميات خاطئة. قد تكون صحيحة كلها، لكن إحداها خصصها PCC محلياً، وأخرى فرضها PCE، بينما ما زال حجز قديم ينتظر الانتهاء. حالة «UP» لا تحدد من يحق له حذف كل جزء.

التقارير الفردية ليست تصويتاً ذرياً

يرسل PCE وفق RFC 9050 رسالة PCInitiate إلى كل PCC، وترد كل عقدة برسالة PCRpt. وإذا كانت التسمية خارج النطاق أو تعذر تنزيل التعليمة، يجب إرسال خطأ واضح. هذا إثبات مهم، لكنه إثبات محلي لعقدة وتعليمة وجلسة بعينها.

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

تكشف طريقة make-before-break المراحل: تثبيت التعليمات الجديدة، ثم طلب تحويل المدخل، ثم انتظار تقريره، ثم إزالة التعليمات القديمة. قبل التحويل قد تستهلك الحالة الجديدة موارد من دون أن تحمل الخدمة. وبعده وقبل التنظيف قد يتعايش جيلان. وحتى بعد تنظيف PCECC قد يبقى حجز أو ارتباط على الجانب القديم.

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

التعليمات اليتيمة لا تفقد أثرها

لا يزيل RFC 9050 تعليمات CCI فور سقوط PCE؛ يمكن أن تبقى حتى انتهاء State Timeout Interval، ويمكن لـPCE جديد أن يتولى التعليمات اليتيمة. يشرح RFC 8283 أيضاً أن مزامنة المتحكمات المتوازية مع عدم فقد تغييرات الشبكة مسألة معقدة.

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

يمكن لمزامنة الحالة أن تكشف اختلافاً بين رؤية PCE وتخصيصات PCC. لكنها لا تستخرج قراراً إدارياً من سجل لم يُكتب. ولهذا يفصل الإيصال الجيد بين القدرة والجلسة والتعليمة والقبول المحلي والتحويل والحالة القديمة وملاحظة الحزم ونتيجة الخدمة.

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

المصادر