الخلاصة

  • يثبت PCRep الإيجابي أن PCE وجد حلاً ضمن لقطة TED وقيود ودالة هدف وسياسات محددة؛ ولا يثبت أن PCC قبله أو أن الجهاز ثبّته.
  • تحتاج الإشارة أو البرمجة وحجز الموارد وRIB/FIB وحالة LSP ومراقبة الحزم وقياس الخدمة إلى إيصالات لاحقة منفصلة.

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

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

كتب Adrian Farrel مع Jean-Philippe Vasseur وJerry Ash وثيقة RFC 4655 ضمن مجموعة عمل PCE في IETF. تعرّف الوثيقة PCE بأنه كيان يحسب مساراً انطلاقاً من رسم بياني للشبكة ويطبق قيوداً حسابية. في نموذج PCE الخارجي، يطلب headend الحساب قبل بدء الإشارة؛ ويستخدم PCE قاعدة TED تحت سياسة محلية ثم يعيد الرد.

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

قاعدة TED تمثل معرفة في لحظة معينة

تحتوي Traffic Engineering Database على معلومات الطوبولوجيا والموارد في النطاق. قد تأتي من امتدادات IGP أو من مزامنة خارجية أو من مصادر متعددة. وهي تصف ما وصل إلى PCE، لا ما يضمن بقاءه ثابتاً بعد الحساب.

يشير RFC 4655 إلى أن ضعف المزامنة يمكن أن يزيد فشل المسارات المحسوبة أو ينتج مسارات أقل كفاءة. ويمكن أن تتغير السعة أو الأعطال أو الحجوزات بين لحظة الحساب ولحظة التنفيذ. لذلك يجب أن يصاحب كل نتيجة وقت TED ونطاق رؤيتها.

تحدد RFC 5440، التي كتبها Vasseur وJean-Louis Le Roux، رسائل PCReq وPCRep. يمكن للطلب أن يحمل النقطتين الطرفيتين وعرض النطاق والأولويات وسمات أخرى. تستبعد القيود حلولاً غير مقبولة، بينما تحدد دالة الهدف، مثل الآليات الواردة في RFC 5541، كيف يُختار حل من بين المقبولين. وتؤثر السياسة المحلية في ما يُطلب وما يُعاد.

إن حفظ ERO وحدها يفقد السؤال الذي أنتج الإجابة. ومن دون القيود ودالة الهدف والسياسة ونسخة TED يصعب إعادة بناء سبب الاختيار عند وقوع خلل.

ما الذي يعنيه النجاح في PCRep

يصف RFC 5440 التسلسل الإيجابي بدقة: استلم PCE الطلب، نجح في الحساب، ثم أرسل المسارات المحسوبة إلى PCC. ترمز ERO إلى مسار TE LSP المحسوب وتصبح متاحة للإشارة الفورية.

كونها متاحة للإشارة لا يعني أن الإشارة نُفذت.

في RSVP-TE تبدأ بعد ذلك عملية الإشارة والحجز المحددة في RFC 3209. وقد يرفض عقدة ما الطلب أو تكون حالة المورد قد تغيرت. أما في Segment Routing فتفصل RFC 9256 بين candidate path وsegment list وبين SR Policy المثبتة على headend والحركة التي وُجهت فعلاً إليها. تحمل RFC 8664 معلومات SR عبر PCEP، لكنها لا تقرأ FIB ولا تراقب الحزم.

تختلف آلية RSVP-TE عن SR، ولذلك لا ينبغي دمجهما في قصة تثبيت واحدة. لكن القاعدة الإثباتية واحدة: وصف المسار ليس استخدامه.

الحالة والتفويض لا يلغيان دور PCC

تضيف Stateful PCE مزامنة الحالة والتحديثات والتفويض. تؤكد RFC 8231 أن ملكية حالة LSP تبقى لدى PCC وأن السمات الواردة من PCE تخضع لسياسته المحلية. يمنح delegation حقاً محدوداً لتعديل سمات LSP ويمكن سحبه لكل LSP على حدة.

يأتي PCRpt لاحقاً لعرض الحالة. عندما يصبح LSP في حالة Up أو Active يبلغ PCC بذلك، وإذا فشل الإعداد يبلغ Down مع السبب. وتنص الوثيقة على عدم وجود ارتباط مباشر بين PCRep وPCRpt، وعلى إمكان صدور تقارير حالة متعددة بعد رد حساب واحد.

هذا الفرق أساسي: PCRep يتحدث باسم الحاسبة، وPCRpt يتحدث باسم مالك الحالة. وتسمح RFC 8281 لـPCE ببدء إنشاء LSP، لكن البدء يظل أمراً تحكمياً يحتاج إلى نتيجة من PCC والجهاز.

سلم الإثبات حتى نتيجة الخدمة

بعد الحساب يجب إثبات قبول PCC. ثم يجب إثبات الإشارة أو البرمجة. وإذا كانت التقنية تحتاج إلى حجز، فيجب التحقق منه. بعد ذلك تُقرأ RIB وFIB كل على حدة. ثم تأتي عدادات الواجهات وعمليات probe وتتبع المسار وflow telemetry لإثبات حركة الحزم. ولا يصح الحديث عن SLA إلا بقياسات خسارة وتأخير وتذبذب وتوافر ضمن نافذة زمنية معرّفة.

RIB ليست FIB، وFIB ليست دليلاً على مرور حزمة بعينها، ومشاهدة حزمة ليست قياس SLA. وظيفة هذا السلم ليست إبطاء الأتمتة، بل منع النية من انتحال صفة النتيجة.

تقدم وثائق التنفيذ مثالاً واضحاً. تشرح وثائق Juniper الخاصة بـPCEP أن PCC يعيد الإشارة بعد استلام سمات من PCE، وتفصل أوامر فحص الجلسة وLSP وSPRING-TE والمسارات. ويعرض دليل أعطال Paragon حالة يتلقى فيها الخادم إقراراً بطلب التوفير بينما يبقى LSP في حالة Down لأن PCC لم يستطع الإشارة. هذا سلوك تنفيذ محدد، لكنه يوضح الفرق بين الإقرار والحالة التشغيلية.

نسبة الفضل بدقة

يعرض ملف Farrel في IETF سجلاً واسعاً. الفضل المقصود هنا محدد ومشترك: ساعد Farrel مع Vasseur وAsh في وضع معمارية تجعل المعرفة والحساب والسياسة والإشارة قابلة للفصل. كتب Vasseur وLe Roux بروتوكول PCEP الأساسي. وطوّر مؤلفون آخرون ومجموعة PCE امتدادات الحالة والتفويض والبدء وSegment Routing، ثم حوّل المنفذون والمشغلون النص إلى شبكة عاملة.

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

سجل المصادر