البوابة ترى حركة الذكاء الاصطناعي، والسجل القياسي يحسب الجلسة كلها

الخلاصة

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

بيت واحد، عداد واحد

قد يرسل أحد أفراد المنزل طلباً إلى مساعد سحابي فيما يبث آخر فيديو مباشراً. البوابة الذكية تستطيع تمييز النشاطين، لكن اتصال PPPoE أو IPoE يظهر في RADIUS جلسة واحدة للمشترك. مسودة Song وLi تبدأ من هذا التباين: تصنيف الحركة أسهل من إثبات من وافق على إعطاء إحداها أولوية أو على حسابها وحدها.

أسماء Filter-Id محلية للجهاز، وقد لا يفهمها جهاز آخر. ويمكن للطرف المنزلي وضع علامتي DSCP و802.1p بنفسه؛ لذلك لا تصلحان كتصريح. أما عناصر الاتصال الخمسة فتتغير عند الاتصال مجدداً. لا يوجد معرّف معياري واحد يحمل معنى الخدمة نفسه إلى البوابة وخادم AAA ونظام المحاسبة. ثم إن سمات RADIUS وتغيير التفويض الحاليين يتعاملان مع الجلسة كلها، لا مع منح قصير الأجل لسرعة تدفق واحد أو أولويته. سجل الحساب القياسي يجمع البايتات والزمن للجلسة؛ ولا يحمل عداداً منفصلاً أو أحداث حياة التدفق أو مفتاحاً يصل الخدمة بإذنها. يمكن للبائعين بناء حلولهم الخاصة، لكن ذلك لا يصنع لغة مشتركة بينهم.

تعطي المسودة حداً واضحاً للسلطة: يجب مطابقة ادعاء الطرف المنزلي مع حق المشترك. إن فشل التحقق، تعود الحركة إلى سياسة الجلسة العادية؛ ولا يتجاوز منح التدفق سقف الجلسة. وتزيد السجلات التفصيلية قدرة المشغل على قراءة عادات البيت، لذلك تدعو إلى تقليل المعرّفات وفترة الحفظ. سجل IETF يصنفها Internet-Draft فردية بحالة I-D Exists، بلا اعتماد من IETF أو امتداد بروتوكولي. لا توثق الرسالة فاتورة فعلية لخدمة ذكاء اصطناعي.