الخلاصة

  • تقترح draft-ietf-intarea-dhcp-rate-signaling-00 خيارات في DHCPv4 وDHCPv6 لحمل معدلات جرى توفيرها للمشترك؛ ويمكن للخادم والمرحّلات وBNG أن تنتج قيمًا مختلفة أو تطبقها في مواضع مختلفة.
  • يلزم سجل لسلطة المعدل يفصل الخطة المتعاقد عليها، وإعلان الخادم، ونوع المحاسبة L2 أو L3، وتعديلات المرحّلات، وإعداد الطابور الفعلي، والسقف المادي، والقياسات المستقلة.

رقم يظهر قبل أن يبدأ أي قياس

قد يعرض موجّه منزلي «1 غيغابت في الثانية» فور تلقي DHCPACK. الرقم آت من الشبكة، ويبدو رسميًا، وربما استُخدم فعلًا لضبط shaper. لكن الجهاز لم يحتج إلى إرسال حركة اختبار، ولا إلى ملء الوصلة، ولا إلى الاتصال بخادم قياس بعيد. لقد تسلم تعليمات، ولم يكتشف سعة.

تعالج مسودة DHCP Explicit Rate Signaling مشكلة تشغيلية مختلفة. فكثيرًا ما تكون سرعة وصلة Ethernet بين جهاز المشترك CPE والمودم أو ONT أعلى من فئة الخدمة التي اشتراها المشترك. وإذا رأى CPE سرعة المنفذ فقط فقد تتراكم الحزمة بعد موضع الاختناق الحقيقي. ويتيح حمل معدلي الرفع والتنزيل لأجهزة CPE والمرحّلات والمبدلات التي تمارس DHCP snooping إعداد shaping أو policing أو Active Queue Management قرب الحد الموفّر.

هذه فائدة حقيقية في التحكم، لكنها ليست اختبارًا للمسار. تسمح المسودة لخادم DHCP بأخذ القيمة من إعداد محلي أو RADIUS/AAA أو خادم سياسة خارجي. وقد يكون أصلها فئة تجارية أو ملف سياسة للمشترك. أما DHCP فينقل القرار ولا يتحقق من قدرة الخط المادية أو من معدل الأداء بين الطرفين في تلك اللحظة.

وتحتاج منزلة الوثيقة إلى الدقة نفسها. بدأت دعوة INTAREA إلى تبني المسودة الفردية في 31 يوليو/تموز 2026. وفي 27 أغسطس/آب سجل الرئيسان وجود توافق على التبني وطلبا تقديم المحتوى نفسه في النسخة 00 باسم مجموعة العمل. ما زالت الوثيقة Internet-Draft قابلة للتغيير أو الاستبدال. ولا يسجل Datatracker حالة RFC مستهدفة، فيما بقيت رموز IANA المطلوبة بصيغة TBD. التبني يفتح مراجعة جماعية؛ ولا يثبت معيارًا نهائيًا أو انتشارًا في الشبكات.

وحدة واحدة وثلاثة معانٍ

يحمل الخيار الحاوي قيمتين من 64 بت بوحدة bit/s للاتجاهين، ومعهما خيار فرعي يحدد النوع. النوع هو الذي يحدد ما يجوز للرقم أن يحكمه.

النوع 0 معلوماتي. يمكن عرضه أو استخدامه في القياس التشغيلي، لكن لا يجوز أن يضبط واجهة أو shaper أو policer أو AQM. النوع 2 يحسب على الطبقة الثانية ويصبح الافتراضي إذا غاب النوع. النوع 3 يحسب رأس IP والحمولة على الطبقة الثالثة. وتقول المسودة إن أساس L3 هو الشائع في اختبارات السرعة وفي عرض سعة المنتج تجاريًا.

لذلك قد يعطي shaper يعمل على L2 واختبار يعمل على L3 نتيجتين مختلفتين وكلتاهما صحيحة ضمن تعريفها. فوسوم VLAN وأعباء التغليف تقع بين الحسابين. كما قد تكون القيمة المعلوماتية صحيحة للخطة التجارية ولكنها غير مخولة بتغيير معالجة الرزم. وإذا لم يفهم المستقبل نوعًا أساسيًا فعليه إسقاط الخيار كله والعودة إلى الإعداد الافتراضي، لا تخمين المعنى.

وللصفر معنى تنفيذي أيضًا. فالمعدل 0 يعني غير مقيد، ويمكنه إزالة حد سبق تطبيقه. الصفر الصريح، وغياب الخيار، والخيار التالف، وعدم مشاهدة الرد ليست حالة واحدة. ولو خُزنت كلها باسم «0 ميغابت/ث» لتحول أمر إعادة الضبط إلى انقطاع مزعوم.

سلطة الخادم لا تكشف مصدر السياسة

يستطيع العميل طلب الخيار، واقتراح قيم قصوى، وإبداء تفضيل لـL2 أو L3. ومع ذلك تكون قيمة الخادم في DHCPACK أو DHCPv6 REPLY هي الملزمة في المعاملة. هذه سلطة داخل تبادل DHCP، ولا تصادق على صحة العقد التجاري أو حداثة ملف AAA الذي غذّى الخادم.

كما أن الخادم قد لا يكون آخر من يحرر القيمة. يستطيع DHCPv4 relay، ومنه Broadband Network Gateway، إضافة الخيار أو تغييره أو حذفه قبل التمرير. ويمكن لعقدة L2 قراءة القيمة بالتنصت المشروع على DHCP وإنشاء طابور أو policer محلي. وفي DHCPv6 تسمح ترويسات relay-reply المتداخلة بإرسال قيمة إلى العميل وقيم أخرى إلى مرحّلات وسيطة. ويتعامل كل مرحّل مع الطبقة الموجهة إليه بدل تفتيش حمولة العميل الداخلية.

وهكذا قد توجد عدة معدلات صحيحة على مسار نفاذ واحد. ربما يتحكم CPE في الرفع، ويتولى مرحّل النفاذ مقطعًا آخر، ويدير BNG التنزيل. اختلافها ليس عطلًا بالضرورة، لكنه يمنع لقطة شاشة من جهاز واحد من تمثيل حالة السياسة كاملة.

للوقت أثر كذلك. يمكن لـReconfigure وتجديد lease في DHCPv6 تغيير المعدل أثناء الجلسة. وفي DHCPv4 قد تساعد قيمة DHCPOFFER على اختيار خادم، لكن التطبيق لا يكون إلا لقيمة DHCPACK. نوع الرسالة، ومعرّف المعاملة، ووقت الاستلام، وتاريخ الانتهاء أجزاء من حقيقة الرقم.

عندما يصل 2 غيغابت إلى منفذ سعته 1 غيغابت

تتناول المسودة صراحة قيمة معلنة تتجاوز قدرة الواجهة المادية. إذا استلم CPE معدل 2 Gbps وكان منفذه لا يتجاوز 1 Gbps، فعليه خفض الإعداد الفعلي لـshaping وpolicing وAQM إلى سعة الواجهة. وينبغي أن تعرض واجهته القيمة الأصلية والقيمة الفعلية المحدودة وأن تسجل الفرق.

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

وتحتاج تعارضات البروتوكول إلى أثر قرار. إذا اختلف DHCPv4 وDHCPv6 تفضل المسودة قيمة v6 وتطلب حفظ بروتوكول المصدر مع الإعداد المطبق. وإذا تكرر الخيار الفرعي نفسه انتصرت آخر قيمة جرى تنفيذها. وفي PPPoE يتقدم معدل DHCP على قيمة خاصة واردة في مصادقة PPP؛ ويعيد الصفر أو انتهاء الجلسة الإعداد الافتراضي.

لا يشرح حقل نهائي بعنوان «المعدل المضبوط» أيًا من ذلك. فهو لا يقول إن v6 تغلب على v4، أو إن مرحّلًا غيّر قيمة الخادم، أو إن المنفذ فرض سقفًا، أو إن انتهاء PPP أزال الحد. البدائل المرفوضة وقاعدة الاختيار معلومات تشغيلية أيضًا.

سجل سلطة المعدل

ينبغي أن تنتج كل قيمة نافذة سجلًا صغيرًا قابلًا للمراجعة. هذا اقتراح تحريري للحَوْكمة في هذه المقالة، وليس مطلبًا في مسودة IETF.

يبدأ السجل بالجلسة أو lease والجهاز والواجهة وإصدار DHCP ونوع الرسالة ودليل المعاملة ووقت الاستلام والانتهاء. وعند إمكان الربط الآمن، يحفظ الخطة المتعاقد عليها ومصدر سياسة الخادم في حقول منفصلة عن قيمتي الرفع والتنزيل اللتين أعلنهما الخادم وعن النوع المعلوماتي أو L2 أو L3.

ثم يحصل كل موضع تعديل على سطر مستقل: القيمة الداخلة، وإجراء الإضافة أو التغيير أو الحذف، والقيمة الخارجة، وهوية relay أو BNG، والجهة المستهدفة، والطابور المحلي الذي أُنشئ. وفي DHCPv6 تسجل طبقة relay-reply المعنية. أما المبدل الذي راقب فقط فلا يوصف بأنه منفذ للسياسة.

تأتي النتيجة في حقول أخرى: قيم shaper وpolicer وAQM الفعلية، وحد الواجهة، وسبب الخفض، والبروتوكول الفائز، وشرط إعادة الضبط. وترتبط القياسات كسلسلة مستقلة لها منهج وطرفان ووقت. وتحتاج واجهة المستخدم إلى أفعال واضحة: «معلن»، و«مطبق»، و«مدعوم ماديًا»، و«متعاقد عليه»، و«مقاس». كلمة «السرعة» وحدها لا تحمل أيًا من هذه الضمانات.

المعقولية ليست إثباتًا للمنشأ

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

يمنع الحد رقمًا شاذًا، لكنه لا يثبت منشأ رقم خبيث يبدو معقولًا. وقد يمنع خفضًا تجاريًا مشروعًا. لذا يجب توثيق السلطة الإدارية أيضًا: أي نظام يملك اختيار الفئة، وأي مرحّل يملك التعديل، ومن يتحمل التحقيق في الفارق.

ولا يظهر الخيار المقترح أو سجلا الخيارات الفرعية والأنواع في سجل IANA BOOTP/DHCP Parameters الحالي. هذا وصف للمرحلة الراهنة فقط، وليس رفضًا ولا ضمانًا لتخصيص قادم. ويلزم ربط أي تجربة مبكرة برمزها المؤقت وبنسخة المسودة الدقيقة.

أين تنتهي دلالة الدليل

تشرح RFC 7567 أهمية إدارة الطابور قرب الاختناق، وتبيّن RFC 9330 اعتماد L4S على الطوابير القصيرة وإشارات الازدحام السريعة. وقد يساعد معدل توفير دقيق هذه الآليات ويحسن ما يراه اختبار لاحق.

مع ذلك لا يثبت رد DHCP إلا أن سلسلة تحكم بعينها أرسلت تعليمة بعينها في معاملة أو lease محدد. ويتطلب الحكم على الأداء مصدر السياسة وتعديلات المرحّلات والحالة المطبقة والحدود المادية ومشاهدات مستقلة. كثرة البتات في الحقل لا توسع نطاق الحقيقة التي يحملها.

المصادر