要約

  • IPv4のTOSは優先度や望ましい品質を示したが、資源を保証しなかった。DiffServは6ビットのDSCPでホップごとの動作を選び、複雑な分類、計測、ポリシング、整形、再マーキングを境界に集めた。
  • AFやEFはサービスを組み立てる部品であって、経路全体への命令ではない。受信ドメインは、自らの資源と合意に従って外部の印を受理、変換、初期化、拒否できる。

境界を越えたのは数字だけだった

企業網で音声パケットにExpedited ForwardingのDSCPが付けられたとする。その網では、契約を知る分類器がトラフィックを選び、一定のサービスレートを持つ短いキューへ送っているかもしれない。ところが通信事業者の入口に届いたとき、見えるのは主に6ビットである。顧客の資格、購入量、流量プロファイル、確保済み容量はヘッダーに入っていない。

入口ルーターは自分の規則で判断し直す。合意に合えば印を残し、超過分だけを落とせる。根拠がなければDefaultへ戻し、別の値へ変え、場合によっては破棄できる。直前の網で受けた優遇は、次の網に対する債権ではない。

DiffServの核心は、印を運べるようにしたことだけではない。印と権限が同じ速度で移動するという思い込みを退けたことにある。

1981年のTOSは希望を記す欄だった

RFC 791 がIPv4を定義したとき、Type of Serviceには1オクテットが与えられた。3ビットのprecedenceに加え、低遅延、高スループット、高信頼性への希望を表すビットがあった。異なる技術の網を横断しても、アプリケーションは抽象的な希望を表明できる。

ただし、Network Control precedenceの実際の利用と管理は各ネットワークに委ねられていた。重要な区分なら、その網自身がアクセスを制御しなければならない。送信者が値を書けることは、利用資格の証明ではなかった。

1992年の RFC 1349 は限界を明記した。TOSは助言的な仕組みにすぎず、サービス保証の要求には適さない。値を見ても処理を変えられない網はあり、必要帯域の具体量も表現できない。「低遅延が望ましい」と「この遅延を保証せよ」の間には、容量と責任の大きな空白があった。

6ビットと集約でコアを軽くした

すべての中核ルーターが顧客ごと、アプリケーションフローごとの状態を持てば、規模と速度の負担が増える。1998年12月の RFC 2474RFC 2475 は、個別フローではなく集約を扱う設計を示した。

旧IPv4 TOSオクテットとIPv6 Traffic Classの上位6ビットがDifferentiated Servicesフィールドとなり、その値DSCPが各ノードのPer-Hop Behaviorを選ぶ。下位2ビットは後にECNへ割り当てられ、DiffServの命令領域ではない。

DSCPはPHBそのものではない。複数のコードポイントが同じPHBに写ることも、値がローカルな意味しか持たないこともある。PHBが定めるのは、あるノードがパケットの集約へ与える外部から観測可能な処理である。キューのスケジューリング、バッファ配分、廃棄規則などがそれを実装する。

標準化されたのは、動作する機器で検証できる一段分の振る舞いだった。経路全体の商品名ではない。

複雑さを境界へ置くという交換条件

DiffServでは、入口や出口が多フィールド分類、計測、マーキング、再マーキング、シェーピング、ポリシングを担う。流量がプロファイル内かを測り、突発を遅らせ、超過を落とす。内部ノードは、すでに整えられたbehavior aggregateを少数のPHBで処理できる。

共通のサービス供給方針とPHB定義で運用される連続領域をDS domainという。これは単なる地理や配線ではなく、ポリシーの届く範囲である。内部では受理した値を十分一貫して扱い、境界では外から来た主張を信頼圏へ入れるか決める。

6ビットが小さいのは情報不足ではなく役割分担である。顧客ID、契約、許容量、価格、超過時の措置は、分類器や設定、当事者間の合意に残された。

AFの「保証量」は事業者が決める

1999年の RFC 2597 はAssured Forwardingを4クラス、各クラス3段階の廃棄優先度として定義した。輻輳時には、同じクラス内で廃棄優先度の高いパケットほど失われやすくする。一方、同一マイクロフローをその違いだけで並べ替えてはならない。

AFの番号は世界共通の料金表のようにも見えるが、RFCはクラス間の帯域やバッファ比率を決めていない。実際のassuranceは、割り当て資源、現在負荷、入口プロファイルで変わる。DiffServ準拠ノードにAF実装は必須でもない。

境界ではAFトラフィックを整形し、廃棄優先度を変え、別クラスへ移し、超過を落とせる。共通の符号は会話を可能にするが、配分を実行するのは各網の設定である。

EFの約束は一台のノードで終わる

RFC 3246 は2002年、Expedited Forwardingを改めて定義した。EFを実装すると表明するノードは、設定されたレート以上で処理し、限定条件下の遅延や揺らぎを評価できなければならない。

同時に、RFCの対象は一ノードだけだと明記された。複数ノードの挙動は範囲外で、DiffServ準拠のためにEFを実装する義務もない。経路を低遅延にするには、関係する全ノードに容量があり、到着量が短いキューを保つ条件内でなければならない。

一台の誠実な実装は、隣のルーターに帯域を作れない。局所的な約束を局所的と呼ぶからこそ、測定と責任が一致する。

契約はヘッダーの外側にある

RFC 2475はSLAとTraffic Conditioning Agreementという語を使った。RFC 3260 は後に、価格や可用性などの商取引事項も含む「agreement」と、DiffServが扱う技術パラメータを区別し、後者にSLSとTCSを用いた。

IETFはフィールドとPHB適合性を定められるが、誰がどのサービスを買ったか、二事業者が何を相互承認するか、どれだけ設備投資するかは決められない。拡張サービスの合意がないドメインから来たDSCPはDefaultへ戻せる。不適切な値は変更または破棄できる。入口処理後に未知の値が残れば、偶然の特権ではなく通常はDefaultとして扱う。

誰でも書ける値には検問が必要になる

DSCPは認証情報ではない。端末は自ら高待遇の値を付けられ、保護されていない外側ヘッダーは改変されうる。不正な優先トラフィックが予約資源を食い尽くせば、サービス窃取はサービス妨害になる。

主要な防御は境界でのconditioningである。入口がトラフィックとポリシーに値が合うか確認し、内部は検査済み集約を扱う。トンネル終端で内側ヘッダーが新しいドメインに現れる場合も同じだ。暗号は改変されていないことを示せても、次の事業者の同意までは作れない。

Wi-Fiとの接続でも意味は翻訳された

RFC 7657 は2015年、エンドポイントが特定ネットワーク内のClass SelectorとPHBの対応を知ることはできず、エンドツーエンドならなおさらだとした。CS1も、Lower Effort、Default、それ以上の処理、再マーキング、廃棄のいずれにもなりうる。

2018年の RFC 8325 は、IPのDSCPとIEEE 802.11のUser Priorityが別の符号空間であることを扱った。アクセスポイントは両者を対応付け、相当するサービスがなければDefaultへ移すことがある。ビット列の保存と意味の保存は同じではない。

小さな共通層は決定権まで共通化しなかった

DiffServは、世界中のキューを6ビットで統治する仕組みではなかった。標準は共通語彙と検証可能なノード動作を提供し、事業者は資源と入場を管理し、顧客と隣接網はプロファイルと合意を持った。境界がそれらを接続した。

パケットは頼める。稼働中のノードは答えられる。しかし、どのヘッダー値も次のネットワークの所有者にはなれない。この節度が、差別化を拡張可能にした。

情報源と限界

TOSの歴史はRFC 791とRFC 1349、DSフィールドと構造はRFC 2474とRFC 2475、AFとEFはRFC 2597とRFC 3246、後年の境界はRFC 3260、RFC 7657、RFC 8325に基づく。これらは、現行事業者の設定、顧客資格、私的契約、普及率、実測性能を示す資料ではない。