要約

  • RFC 5127の処理集約は、複数のDiffservサービスクラスを一つの転送処理へまとめる仕組みであり、複数のDSCPを保持できる。
  • サービスクラスはアプリケーションのエンドツーエンド要求を表し、処理集約は一つの区間のローカル実装を表す。
  • 集約はメンバー中で最も厳しい損失・遅延・ジッタ要件を満たさなければならない。
  • 類似した要求だけでなく、パケット長、バースト性、送信率など交通特性の類似性も必要になる。
  • 原来のサービスクラスは集約後も消してはならず、次の管理ドメインが別の集約を選べる状態を保つ。
  • 推奨方法はDSCPを書き換えずに複数値を共通キューへ分類することだ。ローカル値を使う場合は出口で復元する。
  • メンバーごとの調整・受付・ポリシングと、集約全体の追加制御は別の検査である。
  • 四つの処理集約は例であり、必須の最小数・最大数・能力証明ではない。
  • 高速リンクで集約を増やせるという目安は、利用率が設計範囲内という条件付きである。
  • 深いキューはバースト損失を減らせても待ち時間を増やし、短いキューはその逆の代価を払う。
  • MPLS Traffic ClassやLSPはドメイン内の符号化であり、設定済みキューや観測PHB、アプリ成果を証明しない。
  • 運用ではクラス識別、権限、受付、集約資源、実装、境界復元、実測性能、利用者結果を別々の受領証にする必要がある。

「高速だから一つにできる」という省略

二本の回線を比べる。一方は低速で、もう一方は十倍速い。高速側なら電話、シグナリング、対話映像を一つのReal-Timeキューへ集約しても安全だ、と判断したくなる。

RFC 5127の目安はそれほど単純ではない。高いリンク速度は、利用率が設計水準に収まるなら、より多くの集約を可能にし得る。ここで重要なのは速度ではなく条件全体である。

障害時に複数経路が一本へ迂回すれば、名目速度は変わらなくても利用率は跳ね上がる。新しい映像コーデックが平均パケット長を変えれば、同じビットレートでもキュー占有の仕方が変わる。スケジューラ更新が重みやバースト許容を変えれば、以前の余裕は再利用できない。

したがって、速度は能力の一要素であり、余白の証拠ではない。必要なのは、実際のメンバー構成と障害シナリオで測った損失、遅延、ジッタである。

共有キューが共有するのは資源だけ

処理集約は複数のサービスクラスを一つの転送処理に入れる。複数のDSCPを持てる点が、一つのコードポイントで表されるbehavior aggregateとの違いである。

この構造では、共有されるのはキューやスケジューリング資源であって、要求の意味ではない。電話と放送映像が同じ処理へ入っても、許容損失やバースト特性が同一になるわけではない。

RFCは、集約がメンバー中の最も厳しい要件を満たすよう求める。平均値で折り合いをつけることを認めていない。厳しいメンバーを守れなければ、その集約設計が不適切なのであり、他のメンバーが余裕を持つことは免責にならない。

ただし、規範文だけで必要帯域は出ない。クラス別の許可率、同時ピーク、パケット長分布、キュー容量、スケジューラ動作、障害後の経路を測り、最も厳しい目標との距離を計算する必要がある。

キュー深度には二つの価格がある

深いキューは短いバーストを吸収し、ドロップを減らせる。その代わり、パケットは長く待つ。リアルタイムアプリでは、遅すぎる到着がドロップと同じ、あるいはそれ以上に役に立たないことがある。

短いキューは待ち時間を抑えるが、バーストを早く捨てる。どちらが正しいかは、メンバーの損失・遅延・ジッタ要件に依存する。単一の「高品質」設定は存在しない。

大きなパケットが先に送られれば、小さな制御パケットの直列化待ちが増える。高レートの映像が同じキューを占有すれば、低レートのシグナリングの平均帯域が小さくても遅延に影響する。トラフィックの意味ではなく物理的な並び方が結果を決める。

そのため、クラスが「リアルタイム」という同じ説明語を持つだけでは不十分である。実際のパケット列とスケジューラを検証しなければならない。

受付制御はキューより前にある

RFC 5127のReal-Time例は、エッジで各クラスが受付され、予測可能で強制可能な上限を持つと仮定する。この前提があるから、弾力的トラフィックのバーストから共通キューを保護できる。

クラス別受付と集約合計の受付は別である。あるクラスが自身の契約を超えても、他が静かなら合計は正常に見える。逆に全クラスが個別上限内でも、ピークが同期すれば合計が失敗する。

前者は個別権限の逸脱、後者は共有予算モデルの誤りである。同じキュードロップだけを見れば区別できない。

履歴は計画材料になるが、将来を許可する署名ではない。点対点サービスと多点サービスでは変動性が異なる。メンバー追加時には、平均だけでなく相関と最悪シナリオを再評価する必要がある。

元のDSCPを残す理由

一つのドメインが同じキューへ集約していても、次のドメインはより細かく分けるかもしれない。だからRFCは個々のエンドツーエンドサービスクラスを破壊してはならないとする。

推奨方式では、元のDSCPを保持したまま分類器が複数値を共通キューへ導く。ローカル事情で書き換える場合、出口で元の指示を復元する。トンネルはその保管方法の一つにすぎない。

監査には入口値、内部値、カプセル化の対応、デカプセル化、出口値が必要である。トンネル設定が存在するだけでは、実パケットで復元が成功したと証明できない。

復元失敗は通信断にならないことがある。下流が別のクラスとして扱い、遅延や損失だけが変わる。意味の連続性が壊れても、接続性が残るため、証拠がなければ障害点を特定できない。

四分類は採用の出発点

Network Control、Real-Time、Assured Elastic、Elasticは分析しやすい例である。RFCはドメインが三つでも五つでも、あるいは一部だけでもよいと明示する。

Network Controlでは顧客の制御トラフィックと事業者自身の制御を分け得る。Real-Timeは受付上限を前提とする。Assured Elasticは複数のドロップ優先度を残す。ElasticではCS1をDefault/CS0より先に落とせる。

同じキューに入ることと同じ生存確率は同義ではない。集約の内部に別のドロップ規則が存在する場合、平均キュー統計だけではメンバーの実態を表せない。

実装数を数える監査ではなく、各メンバーの要求と実測値を照合する監査が必要である。

ドメイン境界ではクラスを渡す

RFCは事業者間関係をサービスクラスに基づけるよう勧める。内部集約名をそのまま隣接ネットワークへ命令として渡すのではない。

事業者Aは四キュー、Bは六キューでもよい。Aは送信時のクラスと受付根拠を示し、Bは受信クラスの解釈、不支持時の処理、再マーキング、受付、測定を示す。

両端で同じDSCPを確認しても、中間全ノードのPHBや資源を証明したことにはならない。境界のフィールド連続性、内部処理、エンドツーエンド結果は異なる現実層である。

この設計はローカル自由を守る一方、証拠の移植性を要求する。専有キュー名ではなく、クラス、契約、測定が相互運用面になる。

MPLSの三ビットもローカルである

付録はE-LSPのEXP値で四つの集約を表す例を示す。RFC 5462は後に名称をTraffic Classへ変更した。各MPLSドメインはその割り当てを管理する。

E-LSPではTraffic ClassからPHB Scheduling Classなどを推論する。L-LSPでは一つのLSPが一つのPSCを持つため、処理集約はLSP単位の判断になる。

ラベルとビットは運搬メタデータである。インストール済み分類器やスケジューラ、実際のドロップ、出口復元、アプリの結果までは含まない。

Elastic例でCS1が輻輳時にstarveし得るという注意は、低優先度の意味を具体化する。しかし、それでも最低配送量や回復時間は定義しない。意図と結果を別に測る必要がある。

資料が示さないもの

RFC EditorとDatatrackerはRFC 5127の発行とInformational状態を示す。IANAはコードポイント登録を示す。関連RFCはDiffserv、AF、EF、メーター、MPLS、後続クラスを定義する。

資料には、現在の特定事業者の実装、製品設定、パケットトレース、障害、普及率、SLA結果はない。本稿は規格上の構造と検証境界を扱い、現場の成功を推定しない。

情報源