الخلاصة

  • تضع RFC 9833–9836 نماذج منفصلة للوصلة الحاملة، وخدمة دائرة النفاذ التي يراها العميل، ودائرة النفاذ داخل شبكة المزود، والمراجع التي تربط هذه العناصر بشبكات VPN من الطبقة الثانية أو الثالثة.
  • قد يكون الطلب معتمداً ومتحققاً منه لكنه يبقى في awaiting-processing. وقد تختلف أسماء AC بين طبقة الخدمة وطبقة الشبكة؛ لذلك لا يثبت القبول أو تطابق الاسم أن الدائرة تحققت.
  • تمتد سلسلة الإثبات إلى ربط الهوية بموارد PE/SAP، وربط VPN الصحيح، والإعداد المقصود والمطبق، والحالة التشغيلية، وOAM، وحركة البيانات. لكل مرحلة سلطة محدودة.

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

لا تكفي هذه الفجوة لإثبات عطل أو تضليل. إنها حد مقصود في RFC 9833 وRFC 9834 وRFC 9835 وRFC 9836. صدرت الوثائق الأربع في سبتمبر 2025 على مسار المعايير، وقسمت الطلب وتحقيقه بين نماذج YANG مترابطة. والغاية التشغيلية واضحة: لا يجوز لحالة في طبقة واحدة أن تدعي معرفة ما حدث في طبقة أخرى.

تثبت صفحات RFC 9833 وRFC 9834 وRFC 9835 وRFC 9836 إجماع IETF وموافقة IESG. لكنها لا تثبت تطبيق مزود بعينه، ولا قبول طلب حقيقي، ولا إعداد جهاز، ولا مرور حزمة. نشر المعيار وإيصال الخدمة حقيقتان منفصلتان.

الوصلة الحاملة ليست دائرة النفاذ

الـ bearer هو الرابط السلكي أو اللاسلكي الكامن. أما AC فهو الترتيب المنشأ فوقه لتمكين تبادل البيانات بين نقطة نهاية العميل وشبكة المزود. يمكن لوصلة حاملة واحدة أن تستضيف عدة دوائر، ولدائرة واحدة أن ترتبط بعدة أطراف عميل أو نقاط SAP مقابلة، ولطرف عميل واحد أن ينهي عدة دوائر.

لهذا لا تعني سلامة الـ bearer أن AC الخاص بالعميل نشط أو مربوط بالخدمة الصحيحة. كما أن سحب خدمة واحدة لا يمنح سلطة حذف المورد المشترك أو خدمات شقيقة. مؤشر أخضر واحد يمحو العلاقات التي يحتاجها المشغل لتقييد أثر الأتمتة.

تسمح RFC 9834 للمزود بإصدار bearer reference يسترده العميل ويستخدمه لاحقاً في طلب AC. ويمكن للمزود قبول المعرف الذي يقترحه العميل أو رفضه. ولا يلزم أن يكون معرف AC فريداً إلا داخل نطاق المزود؛ فهو مقبض محدود النطاق، ويجب حفظ مصدره ونطاقه والهدف الذي يحل إليه الآن.

نموذج العميل يصف المطلوب لا هندسة المزود

تعرف RFC 8309 نموذج خدمة العميل بأنه وصف للخدمة المطلوبة أو التي يختبرها العميل، لا لكيفية تحقيق المزود لها. تحافظ RFC 9834 على هذا الفصل، فلا تعرض للعميل اختيار PE أو SAP أو الواجهة أو الطوبولوجيا أو التقنية.

يسمح هذا التجريد باستخدام طلب مشترك فوق شبكات داخلية مختلفة. لكنه يعني أيضاً أن كائن العميل لا يثبت تعييناً صمم النموذج لإخفائه. ما يثبته إيصال الطلب هو هوية الطالب، وصلاحياته، ومرجع bearer أو peer-SAP، ومعرف AC في طبقة الخدمة، والمعلمات، ونتيجة التحقق، والحالة الإدارية.

تتضمن RFC 9833 حالات awaiting-validation وawaiting-processing وadmin-prohibited وrejected. وقد يأتي awaiting-processing بعد الموافقة والتحقق بينما يبقى عمل قبل التفعيل. تحويله إلى «نشط» في لوحة التحكم ليس تبسيطاً؛ بل إضافة لنتيجة لم تقع.

للشبكة هوية مستقلة

تعرف RFC 9835 نموذج ietf-ac-ntw الذي يربط مرجع الخدمة بدائرة الشبكة الفعلية ويحفظ تعيين PE/SAP. هنا تبدأ النية المحمولة في التحول إلى مورد داخلي محدد.

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

وجود سجل الشبكة لا يثبت تطبيق الإعداد. تفصل RFC 8969 بين نماذج الخدمة والشبكة والجهاز، وتدعو إلى إعادة الحالة التشغيلية والإحصاءات إلى الأعلى. يصف نموذج الشبكة ما تنوي الأتمتة إنشاءه؛ وعلى الأنظمة الأدنى أن تثبت ما نفذته.

الـ glue يثبت الارتباط فقط

تضيف RFC 9836 نموذج ietf-ac-glue لربط هويات AC بنماذج VPN. فهي توسع نموذج خدمة L3VPN في RFC 8299، ونموذج خدمة L2VPN في RFC 8466، ونموذج شبكة L3VPN في RFC 9181. وتوفر RFC 8345 وRFC 9543 سياقاً مجاوراً للطوبولوجيا وضمان الخدمة.

يثبت مرجع glue أن كائن VPN مرتبط بنموذج مع AC معين. لا يثبت تخصيص الموارد أو تطبيق إعداد أو قابلية الوصول أو التمرير أو تحقيق SLA. وقد يشير AC في الخدمة إلى AC الشبكي A بينما يشير VPN إلى B. تكون كل الكائنات موجودة وكل المعرفات صحيحة شكلياً، لكن الرسم البياني خاطئ.

المقصود والمطبق والمرصود

تميز RFC 8342 بين القيم المضبوطة، والإعداد المقصود، والحالة التشغيلية. يمكن للتأخير والعتاد والبروتوكولات والأنظمة الأخرى أن تفصل <intended> عن <operational>. والمقارنة بينهما، لا تاريخ قبول الطلب، تكشف مقدار النية المستخدمة فعلاً.

لذلك تبدأ السلسلة بالمصادقة والتخويل، ثم حل مرجع bearer، وقبول AC الخدمي، وربطه بمعرف AC الشبكي، واختيار PE/SAP والواجهة، وربط VPN الصحيح، وإنتاج الإعداد المقصود، ورصد التطبيق والحالة، ثم قياس OAM والوصول والحركة ونتيجة الخدمة على حدة.

تحدد RFC 7950 لغة YANG من دون فرض بنية داخلية واحدة. وتقدم RFC 9408 إطاراً أوسع لأمن وحدات YANG. لا تثبت هذه المصادر اختراقاً بعينه؛ بل توضح ضرورة ربط صلاحية الكتابة بالطبقة والكائن الصحيحين.

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

المصادر