صودق على جار التحكم. أما المسار الذي يحمل الحزم فلم يُختبر

الخلاصة

• يعرّف RFC 5150 وصل مقاطع GMPLS، حيث يُخصَّص كل S-LSP لمسار واحد من طرف إلى طرف.
• يطلب رأس المقطع الوصل بالبت 5 في LSP_ATTRIBUTES، ويعلن الطرف الآخر الاستعداد بالبت المناظر داخل RRO.
• يشترط الاستعداد وسم إعداد غير صفري، أما عدم الدعم المعروف فيُعاد كخطأ Routing Problem بالقيمة 30.
• إعلان الاستعداد يسمح باختيار المقطع، لكنه لا يشهد بأن تبديلات مسار e2e اللاحقة قد بُرمجت.
• تبدو نهايتا S-LSP متجاورتين في طوبولوجيا TE، مع أنه لا توجد بينهما forwarding adjacency في مستوى البيانات.
• لذلك تكون قيمتا Label وUpstream Label في القفزة المجردة إلزاميتين شكلاً وعديمتي المعنى، ويجب تجاهلهما.
• يعتمد العبور الفعلي على تبديل محلي عند مدخل المقطع وآخر عند مخرجه، وفي الاتجاهين إذا كان المسار ثنائي الاتجاه.
• يسجل RRO لمسار e2e نهاية المقطع ولا يكشف العقد والروابط الداخلية التي يحملها S-LSP.
• تخصيص كامل عرض النطاق ومنع ارتباط ثانٍ يثبتان الحجز، لا التسليم ولا الأداء.
• جلسة المقطع وجلسة e2e مستقلتان في الإنشاء والإزالة؛ أما إجراء الاستعادة الدقيق فخارج نطاق الوثيقة.
• مصادقة RSVP تربط جيران مستوى التحكم ولا تمتد تلقائياً إلى مستوى البيانات أو حمولة العميل.
• يلزم فصل إيصالات الهوية والاستعداد والحجز والتبديل والصحة الداخلية والاستعادة والنتيجة المرصودة.

ما تثبته مصادقة الجار

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

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

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

الاستعداد إذن استخدام لا نتيجة تنفيذ

يضع رأس S-LSP قيمة LSP stitching desired في البت 5 من TLV الخاص بأعلام السمات. إذا فهم الطرف الآخر الإجراء واستطاع تنفيذه، يخصص وسماً غير صفري في Resv ويضع LSP segment stitching ready في كائن السمات داخل RRO. وعلى المصدر ألا يستخدم مقطعاً بقي بت الاستعداد فيه صفراً.

إذا كان الطرف يعرف الطلب لكنه لا يدعم الوصل، يعيد PathErr من نوع Routing Problem بالقيمة 30، Stitching unsupported. أما تنفيذ يعرف الكائن ولا يعرف الـTLV أو البت نفسه فقد يتجاهل الطلب وفق قواعد القابلية للتوسعة. وهنا تصبح قراءة الجواب، لا مجرد إرسال الطلب، هي الحد الأدنى للقرار.

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

وسوم القفزة ليست عقد تحويل

في المسار ثنائي الاتجاه، يحمل Path كائن Upstream Label عبر قفزة S-LSP، وتحمل Resv كائن Label في الاتجاه المقابل. وجود الكائنين قد يبدو في السجل كأنه تبادل وسوم عادي بين عقدتين متجاورتين. ينص RFC 5150 على العكس التشغيلي: لا توجد forwarding adjacency بين الطرفين، ويمكن أن تكون القيم أي شيء، وعلى المستقبل تجاهلها.

هذه الحقول تحفظ انتظام معاملة RSVP-TE عبر قفزة منطقية، لكنها لا تختار عملية تحويل مباشرة على سلك. التنفيذ الحقيقي محلي عند الحدود. يجب أن يحول مدخل المقطع الحركة من جزء e2e السابق إلى S-LSP، ثم يحول المخرج الحركة من S-LSP إلى الجزء التالي. وفي مسار ثنائي الاتجاه يلزم زوج مماثل عكسياً.

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

التجاور في قاعدة TE تجريد متعمد

يمكن الإعلان عن S-LSP كرابط TE واستخدامه في حساب المسار. تظهر نهايتاه متجاورتين للحاسوب، بينما قد يمر مستوى البيانات عبر عقد وروابط عديدة ولا ينشئ رابطاً مباشراً بينهما. الإعلان اختياري، وله كلفة في حجم قاعدة حالة الروابط ومعالجة التحديثات.

في RRO الخاص بمسار e2e، يسجل النظام عنوان نهاية المقطع أو معرف رابطه غير المرقم. ولا ينبغي أن يسرد في تلك القفزة العقد والروابط الداخلية للمقطع نفسه. نجاح التسجيل يعني أن التجريد عُرض كما صُمم، لا أن الجزء المخفي سليم أو متنوع مادياً.

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

الحجز الحصري لا يقيس المرور

يختلف الوصل عن هرمية LSP. في الهرمية قد يحمل H-LSP عدة مسارات من طبقة أعلى، وتكون الوسوم وسيلة فصل بينها. أما S-LSP فيعمل في طبقة التحويل نفسها، ولا يرتبط إلا بمسار e2e واحد، ويخصص كامل عرضه لذلك الارتباط.

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

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

السياسة المحلية هي صاحب القرار

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

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

يستطيع الوصل تجاوز عقد قديمة، بما في ذلك سياق LSRs قادرة على P2MP. يحذر RFC من أن بعض التهيئات قد تقلل جاذبية RSVP P2MP. حل التوافق القصير يمكن أن يتحول إلى اعتماد دائم إذا لم يكن له مالك وخطة خروج.

انتهاء إحدى الجلستين لا يفسر الأخرى

جلسة S-LSP وجلسة e2e مستقلتان في الإزالة. قد تستخدم إحداهما ADMIN_STATUS بينما تسحب الأخرى حالتها مباشرة. يمكن أن يبقى مقطع ثابت بعد انتهاء مسار e2e، ويمكن للسياسة أن تزيل مقطعاً ديناميكياً بعد بقائه بلا استخدام.

يوصي RFC 5150 بأن يُعامل إنهاء المقطع كفشل للمسار e2e وأن يؤدي إلى استعادة أو إنهاء، لكنه يترك طريقة الإشارة الدقيقة خارج نطاقه. وجود محفز ليس إثباتاً لنجاح مسار بديل. ويخفف تأخير موصى به يقارب 30 ثانية قبل إزالة المقطع الديناميكي من تزامن رسائل الخطأ والإزالة؛ لكنه لا يحجز استمرارية للعميل.

لذلك يحتاج التحقيق إلى خطين زمنيين: حالة الجلسة والموارد من جهة، والتبديلات والمسار البديل والحركة من جهة أخرى. تثبت قيم IANA والـerratum التحريري معنى الحقول، ولا تقدم دليلاً على انتشار التنفيذ أو نجاح تشغيل بعينه.

المصادر

1. RFC 5150 بصيغة HTML
2. RFC 5150 نصاً
3. سجل RFC Editor
4. سجل IETF Datatracker
5. تاريخ RFC 5150
6. مراجع RFC 5150
7. تصويبات RFC 5150
8. RFC 4206
9. RFC 3209
10. RFC 3473
11. RFC 4420
12. RFC 3477
13. RFC 4201
14. RFC 4203
15. RFC 4205
16. RFC 2747
17. RFC 3032
18. RFC 5151
19. سجل معاملات RSVP لدى IANA
20. Minimum Initial Specification
21. On Reality Layers
22. Running-Code Primacy