الخلاصة

  • يتيح RFC 9800 للمصدر وضع عدة SIDs مضغوطة في عدد أقل من حاويات 128 بتاً، بشرط التحقق من البنية والحفاظ على قائمة المقاطع الأصلية بلا تغيير.
  • Clarence Filsfils واحد من خمسة مؤلفين مسمّين. تقليل البتات المكررة يجعل دقة الأطوال والـflavors والإعلانات والتخصيص وخصائص الحدود أكثر أهمية، لا أقل.

البتات المشتركة التي لم تكن تتخذ قراراً

قد تحمل سياسة SRv6 الصارمة سلسلة طويلة من تعليمات طوبولوجية أو خدمية. عندما يظهر كل SID كعنوان IPv6 كامل، تتكرر قيمة Locator-Block في تعليمات متتالية، وقد تبقى أصفار حشو في النهاية. هذه البتات تجعل الشكل واضحاً، لكنها لا تضيف خطوة توجيه جديدة.

يعرّف RFC 9800، المنشور في يونيو 2025، طريقة منظمة لإزالة هذا التكرار. يحتفظ CSID بجزئي Locator-Node وFunction من SID الأصلي. ويمكن لحاوية CSID واحدة بطول 128 بتاً أن تحمل CSID واحداً أو أكثر، إضافة إلى Argument الخاص بآخر واحد عند الحاجة.

لكن القائمة لا تتحول إلى بيانات صامتة أثناء الضغط؛ فهي تبقى برنامجاً ينفَّذ داخل الحزمة. يجب أن يشير Destination Address في كل مرحلة إلى سلوك محلي صالح، وأن تظهر التعليمة التالية بترتيب محسوم. لذلك يلزم RFC المصدر بأن تعبّر القائمة المضغوطة عن سلسلة المقاطع نفسها التي عبّرت عنها القائمة الكاملة.

إذا تغيّرت adjacency أو جدول lookup أو وظيفة الخدمة، فالحزمة الأقصر ليست نسخة محسنة؛ إنها سياسة أخرى. هذه هي حدود الأمان التي تمنح توفير الحجم معناه.

NEXT-CSID وREPLACE-CSID

في NEXT-CSID تكون الحاوية النشطة SID كاملاً. يحتل CSID الأول موضعه الطبيعي، وتوضع القيم اللاحقة في مساحة Argument. بعد تنفيذ السلوك الحالي، ينقل الطرف التالي إلى الموضع النشط داخل Destination Address، ويصفّر البتات الدنيا غير المستخدمة، وينقص Hop Limit، ثم يجري lookup جديداً في IPv6 FIB.

أما REPLACE-CSID فيبدأ أيضاً بـSID كامل، لكنه يضع CSIDs اللاحقة في مواضع ثابتة داخل حاويات معبأة في Segment List التابعة لـSRH. يحمل Argument فهرس الموضع الحالي. ينتقل التنفيذ داخل الحاوية، أو يخفض Segments Left عند الانتقال إلى حاوية أخرى، ثم يعيد بناء عنوان وجهة IPv6 صالح.

هاتان طريقتان لترميز السلوكيات القائمة، وليستا معنيين جديدين للمقاطع. يوضح قسم الأمن في RFC أن دلالة segment لا تتغير؛ الذي يتغير هو كيفية ترميز SID التالي واستخراجه.

يمكن للـflavors أن تتعايش، حتى داخل قائمة واحدة. ومع ذلك ينصح النص عادة بعدم خلطها داخل routing domain واحد أو Locator-Block واحد. اختلاف codepoints والأطوال ومسارات الخطأ يوسع عبء الاختبار والتشخيص، ولو بقي الشكل قانونياً على السلك.

المصدر الذي يعرف متى يرفض

قد تأتي القائمة من إعداد محلي، أو من حساب محلي، أو من controller. لا يمنح أي مصدر إعفاءً من التحقق. يجب ألا يكون LBL صفراً، وألا يكون LNFL صفراً، وأن يساوي AL تماماً 128-LBL-LNL-FL.

تُعامل البنية التي تفشل في هذه الشروط على أنها مجهولة وغير قابلة للضغط. لا يحتاج المصدر إلى إسقاط السياسة كلها؛ يستطيع إبقاء SID المعني كاملاً وضغط البقية. هكذا يصبح الرفض محلياً وقابلاً للعكس، ولا تتحول سلطة controller إلى بديل عن حقيقة البنية.

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

إعلان البنية ليس دليلاً على التنفيذ

يلزم الإعلان عن SRv6 SID Structure لكل SIDs الجديدة. على endpoint أن يعلن أطوالاً تطابق البنية المثبتة محلياً وأن يجعل Argument صفراً في الإعلان. يمكن لامتدادات IS-IS وOSPFv3 وBGP وBGP-LS ومسارات تعتمد PCEP نقل هذه المعلومات.

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

لذلك يحتاج المشغّل إلى مطابقة أربع صور: البنية الفعلية على endpoint، والإعلان، ومخزون controller، والبنية التي قبلها المصدر. وجود route وحده لا يكفي؛ يجب أن تتفق behavior وflavor وLBL وLNL وFL وAL.

تبديل الكتلة عند الحد

تتشارك CSIDs في sequence واحدة Locator-Block في العادة. عند عبور نطاق يستخدم كتلة أخرى، يبدّل End.LBS الكتلة إذا كان الحد على العقدة نفسها، بينما يجمع End.XLBS بين التبديل وL3 cross-connect محدد على الوصلة المجاورة.

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

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

كثافة الضغط لها ثمن في فضاء الأسماء

يسمح CSID الأقصر بوضع تعليمات أكثر في الحاوية، لكنه يقلل عدد المعرّفات المتاحة. ويمنح CSID الأطول مساحة تخصيص أكبر مع ضغط أقل. يوصي RFC بأطوال متسقة داخل النطاق حتى يبقى هذا الاختيار مفهوماً.

فضاء GIB مشترك بين العقد تحت Locator-Block، أما LIB فمحلي لكل عقدة. توجّه التوصية GIB إلى المقاطع العالمية فعلاً، مثل هوية عقدة، وتضع الخدمات وadjacencies وcross-connects في الفضاء المحلي. الإفراط في استخدام المورد المشترك لوظائف محلية يسرع نفاده، بينما تقصير الحقول أكثر من اللازم يقيد النمو المقبل.

موقع Filsfils في سجل جماعي

يسمي سجل RFC Editor Weiqiang Cheng وClarence Filsfils وZhenbin Li وBruno Decraene وFrancois Clad مؤلفين. صدر العمل عن مجموعة SPRING في IETF، وحدّث RFC 8754، وسُجلت سلوكياته لدى IANA.

تعرّف صفحة Cisco الرسمية Filsfils بصفته Cisco Fellow وتعرض تاريخه في Segment Routing. هذا سياق مهني مؤرخ، لا دليل على تأليف فردي لمعيار جماعي، ولا على التحكم في تطبيقات الآخرين أو نتائج تشغيل لم تُقَس هنا.

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

المصادر