要約

  • 11月1日付の個人提出の草案は、家庭向けゲートウェイがAI推論や動画の通信を分類できても、標準のRADIUSは加入者セッション全体を許可・計量する構造だと指摘する。
  • 不足するのは、機器と認証・課金システムが共有するサービスフローID、フロー単位の許可、開始・終了と利用量を結ぶ記録の三つだ。
  • 新しいプロトコルはまだ定義していない。端末が自称する優先マークは権利の証明にならず、照合に失敗したら通常のセッション設定へ戻すという。

見分けられるのに、同じメーターへ入る

自宅で一人がクラウド上の助手を使い、もう一人が動画を配信する。ゲートウェイは二つの通信を分けて扱える。しかしPPPoEやIPoEの加入者アカウントは一つのセッションで、標準の許可と利用記録もその単位で動く。SongとLiの草案が問うのは、分類結果を誰の許可に結び、何を使った記録として残すかだ。

Filter-Idの名称は機器ごとの設定に依存する。端末が付けられるDSCPや802.1pの印を、料金を伴う優先扱いの許可にすることはできない。接続の五要素も再接続で変わる。したがってゲートウェイ、AAA、課金装置が同じサービスを指す共通IDがない。現行のRADIUS属性と変更通知はセッションを対象とし、一つの短命な通信だけに速度や待ち行列を与える共通の意味を持たない。標準の計量はセッションの総バイト数と時間を記録し、個別フローの開始、終了、サービス実体との照合を表せない。独自方式の存在と、相互運用できる標準がないことは別の話だ。

草案は端末からの申告を加入者の権限と照合し、失敗時は通常のセッション設定へ戻すよう求める。個別の許可もセッション全体の上限を超えてはならない。詳しい利用記録には家庭内の行動が映るため、IDと保存期間を抑えるべきだ。IETFの記録はこの文書を支持された標準ではない個人提出のInternet-Draft、I-D Existsと明記する。実際にAI通信へ追加請求された事例は示されていない。