الخلاصة

  • تعيّن خدمة Ethernet Tree لدى MEF لكل وصلة وصول دور Root أو Leaf. تستطيع Leaf الاتصال بـ Root، لا بـ Leaf أخرى؛ أما VPLS التقليدية فتعامل وصلات الوصول على قدم المساواة.
  • يبين المثال الافتراضي ذي موجهي الحافة في RFC 7152 أن عنوان MAC الوجهة ووصول الإطار لا يكفيان: لا تعرف الحافة البعيدة دور الوصلة التي أرسلته.
  • حددت مذكرة 2014 متطلبات مثل تعدد الجذور واجتماع أدوار مختلفة على الحافة والتوافق مع الإصدارات السابقة. ولا تثبت الوثيقة نشر الخدمة أو نتائجها؛ فـ RFC لاحقة وصفت الأطر والآليات.

التحليل

الدور كان خاصاً بوصلة الوصول

Ethernet Tree خدمة متعددة النقاط ذات جذر. تستطيع وصلة Root الاتصال بوصلات Root وLeaf، بينما تصل Leaf إلى Root ولا يجوز أن يمرر الإطار من Leaf إلى أخرى. وتختلف هذه العلاقة عن Ethernet LAN التي تسمح بالتواصل بين نقاطها.

عندما تعبر الخدمة شبكة مزوّد، يصبح الفرق تشغيلياً. في مثال RFC 7152، يربط موجّها حافة وصلة Root ووصلة Leaf لكل منهما، ويتبادلان إطارات Ethernet عبر pseudowire. تعرف الحافة المستقبلة أن الإطار جاء من حافة بعيدة، لكنها قد لا تعرف أي وصلة محلية في الحافة الأولى استقبلته، ولا ما إذا كانت تلك الوصلة Leaf.

معرفة عنوان MAC الوجهة لا تحل المشكلة. فالوجهة تخبر الشبكة إلى أين يتجه الإطار، لا بالدور المسند إلى وصلة دخوله. ومن دون ذلك الدور، لا تستطيع الحافة البعيدة تطبيق قيد Leaf-to-Leaf على نحو موثوق على الإرسال الأحادي المعروف أو المجهول أو البث أو البث المتعدد. وتوضح RFC أن الرسم افتراضي لشرح المشكلة، وليس وصفاً لخدمة نموذجية.

حملت VPLS الاتصال، لا هذه السياسة

عامل نموذج VPLS القائم وصلات الوصول بالتساوي وأتاح اتصالاً من أي نقطة إلى أي نقطة داخل المثيل. كان ذلك مفيداً لمحاكاة Ethernet LAN، لكنه لم يعبّر عن علاقة Root وLeaf التي طلبتها خدمة MEF. لم تكن المعلومة الناقصة عنواناً إضافياً للعميل، بل خاصية لوصلة الخدمة ينبغي أن تظل مفهومة بعد عبور قلب شبكة المزوّد.

لذلك وضعت RFC 7152 متطلبات بدلاً من إعلان حل مكتمل. يجب أن يمنع الحل الاتصال بين وصلات Leaf، ويسمح بأكثر من Root، ويتيح اجتماع وصلة Root ووصلة Leaf على الحافة نفسها. كما يجب تحديد تقنية VPN للطبقة الثانية المعنية وتقليل أثر التغيير على شبكات VPLS وEVPN القائمة. وإذا لم تدعم سوى بعض الحواف السلوك الجديد، فالقيد ينطبق ضمن نطاق الحواف المتوافقة؛ ولا يعد ذلك بعزل كامل عبر جزء غير داعم.

تذكر المذكرة استخدامات محتملة مثل VPN بنمط المركز والفروع، والوصول بالجملة، وربط شبكات الهاتف المحمول، ومزامنة الوقت، والوصول إلى الإنترنت، والفيديو وإدارة الأجهزة. هذه حالات استخدام في وثيقة متطلبات، وليست إحصاءً لخدمات منشورة. كما تميّز المذكرة E-Tree عن خدمة البث المتعدد الخاصة التي كان IETF يناقشها آنذاك: تدعم E-Tree أنماط الإرسال الأحادي والمتعدد ضمن قواعد Root وLeaf، ولا تستبدل خدمة البث المتعدد كل هذه التدفقات.

أوضحت RFC اللاحقة السياق المفقود

قدمت RFC 7387، المنشورة لاحقاً في 2014، إطاراً معمارياً لـ E-Tree وحددت فجوتين: VPN الطبقة الثانية لا تميز أدوار وصلات الوصول، والحافة البعيدة لا تتلقى إشارة تخبرها هل نشأ الإطار من Root أم Leaf. ثم حددت RFC 7796 دعم E-Tree في VPLS باستخدام معرفات VLAN مختلفة لإطارات Root وLeaf، كي تتمكن معدات التحويل من ترشيح الإطارات عند منافذ Leaf. ووسعت RFC 8317 الدعم إلى EVPN وPBB-EVPN.

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

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

المصادر

وتؤكد صفحة معلومات RFC 7152 لدى RFC Editor حالتها في سجل النشر.

المصدر الأساسي هو RFC 7152، التي تحدد المتطلبات وتصف مثال الحافتين بأنه افتراضي. وتوثق RFC 7387 وRFC 7796 وRFC 8317 الإطار والآليات اللاحقة لـ VPLS وEVPN. تثبت هذه المصادر ما نصت عليه الوثائق، لا معدلات الاعتماد أو إعدادات المزوّدين أو قياسات الحركة أو نتيجة تشغيلية محددة.