الخلاصة

  • في نمط shuffling يستبدل موجّه PE عند الدخول معرّفات CPI بمعرّفات PPI داخل كائني Session وSender Template، ثم يعكس PE عند الخروج العملية.
  • لذلك يستطيع العميل رؤية جلسة متصلة من دون أن يعرف نسخة PIT التي اتخذت القرار، أو المنفذ الداخلي الذي اختير، أو ما إذا كان الربط المادي ومستوى البيانات قد حققا النتيجة المقصودة.

الاستمرار الظاهر ينتج من تغيير خفي

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

هذا ما يسميه RFC 5251 بالتبديل أو shuffling. يغيّر PE عند الدخول كائني RSVP-TE اللذين يحددان الجلسة والمرسل، فيستبدل Customer Port Identifier، أي CPI، بـ Provider Port Identifier، أي PPI. وعند الخروج تُستعاد قيم CPI. يحافظ النظام على التجريد نفسه للعميل عبر تغيير الأسماء الأساسية مرتين.

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

ثلاثة معرّفات لا تملك السلطة نفسها

يصف CPI جانب العميل من المنفذ، ويصف PPI جانب المزوّد، أما VPN-PPI فيسمّي منفذ PE داخل فضاء العناوين الذي يراه عميل L1VPN. يسيطر المزوّد على تعيين PPI، بينما تضبط إدارة L1VPN عناوين CPI وVPN-PPI.

قد يستخدم PPI غير المرقّم وVPN-PPI رقم المنفذ نفسه تسهيلاً للتشغيل. تساوي الرقم لا يوحّد المجالين. إذا احتفظ السجل بعبارة «المنفذ 17» وحذف نوع الاسم وسياق VPN وحدّ الرصد، فلن يبقى ما يكفي لإعادة بناء الترجمة.

ينطبق القيد نفسه على عناوين قناة التحكم. يجب أن تكون عناوين CE وPE فريدة داخل L1VPN واحد، لكنها قد تتكرر في شبكة افتراضية أخرى. ولذلك فإن الربط الواضح بين القناة وVPN جزء من الهوية، وليس تفصيلاً إضافياً.

نسخة PIT التي استُخدمت أهم من حالتها الحالية

تحتفظ كل حافة للمزوّد بجدول Port Information Table خاص بالشبكة الافتراضية. يضم الجدول أزواج CPI وPPI، كما يضم معلومات VPN-PPI للمنافذ المحلية. قد تأتي الصفوف من التزويد الإداري، وقد تسهم آليات الاكتشاف المعتمدة على BGP أو OSPF والمبيّنة في RFC 5195 وRFC 5252.

لكن معرفة مصدر المعلومة لا تحدد وحدها ما حدث عند التنفيذ. عندما يصل الطلب، يختار PE عند الدخول جدول PIT الخاص بـ L1VPN، ويحل CPI الهدف إلى PPI، ثم يعيد كتابة الإشارة. وتستخدم الحافة الأخرى حالة جدولها لإجراء الترجمة العكسية.

لا يستطيع المدقق الاعتماد على جدول اليوم لتفسير جلسة الأمس. فقد يكون الصف الذي استُخدم قديماً أو مهيأً بصورة خاطئة أو مرتبطاً بسياق VPN غير صحيح، مع بقاء التحويل سليماً من الناحية النحوية. لهذا يحتفظ RFC 5251 بأهمية حماية الإدارة والتهيئة، ويطلب النظر في تحقق لمستوى البيانات لمواجهة الخطأ العرضي في الإعداد.

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

إخفاء الطريق لا يلغي وجوده

تحمل الرسائل داخل شبكة المزوّد معرّفات PPI. وعندما يُستخدم shuffling يجب تطبيق التحويل على جميع رسائل RSVP-TE ذات الصلة عند الحافتين. أما إعادة كتابة بعض الرسائل فقط فتنتج حالات متعارضة تحت جلسة واحدة ظاهرياً.

يرى العميل LSP واحداً ورابطاً افتراضياً بين جهازي PE، بينما يرى المزوّد تفاصيل المقطع الداخلي. ويمكن للحواف أن ترشح معلومات الطوبولوجيا وأن تعدل أو تحذف كائني Record Route وNotification. حماية الخريطة الداخلية حد مشروع للخدمة، لكنها لا تجعل الخريطة بسيطة أو غير موجودة.

لا تعني الجلسة الواحدة قفزة مادية واحدة أو ليفاً واحداً أو طول موجة واحداً أو مساراً ثابتاً. كما يسمح RFC 5251 بنمطي stitched وnested. ويمكن ربط جلسة بين جهازي PE أو LSP قائم أو forwarding adjacency بطلب العميل وفق آليات RFC 5150 وRFC 4206. قد تبدو النتيجة واحدة خارجياً وتترك سجلات داخلية مختلفة جذرياً. لذلك يجب حفظ نمط التنفيذ نفسه.

قبول الهدف لا يثبت الوصلة المادية

يختار CE المصدر هدفاً يعرفه. تقيد سياسة المزوّد الطوبولوجيات المسموح بها بين المنافذ. تترجم الحافة الأسماء وتحسب الطريق الداخلي، ثم يقبل CE الهدف الطلب أو يرفضه. كل خطوة قرار حقيقي، لكنه يجيب عن سؤال محدود.

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

ولا يمنح Explicit Route Object يقدمه العميل سلطة كاملة على كل قفزة داخلية. يستطيع PE رفضه، وعند قبول صيغة مرنة يظل PE مسؤولاً عن حساب مسار المزوّد وإدراجه. تقيد نية العميل الخدمة من غير أن تصبح توقيعاً على كل قرار هندسي.

سجل يبقى قابلاً للتفسير بعد التغيير

تبدأ سلسلة الإثبات بهوية L1VPN وارتباط قناة التحكم وقيمتي CPI الأصلية للمصدر والهدف والطلب كما وصل. ثم تحفظ الجيل الدقيق من PIT ومصدر الصف وقيم PPI الناتجة وحالة Session وSender Template قبل الاستبدال وبعده. وعند الخروج تحفظ عملية البحث العكسية وقيم CPI المستعادة واستجابة الطرف البعيد.

بعد ذلك تأتي حالة RSVP وبرمجة الموارد والربط المادي واختبار مستوى البيانات والنتيجة المرصودة. لا يمكن لحقل موحد باسم «session up» أن يحل محل هذه السلسلة. فعندما تتغير التهيئة، لن يفسر الحقل أي مطابقة دعمت الجلسة القديمة.

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

يمنحنا انضباط طبقات الواقع لدى Lu Heng قاعدة تشغيلية واضحة: الاسم في مجال العميل ليس الحقيقة نفسها في مجال المزوّد؛ نجاح الترجمة ليس رصداً لوصلة مادية؛ واستمرار الجلسة ليس استمرار الخدمة بأكملها. تبقى الأنظمة قادرة على تحمل المسؤولية عندما يسجل كل حد ما غيّره وما رآه بالفعل.

المصادر