UDP内のMPLS：アンダーレイのためのエントロピー、ドメインのための規則

ふたつのプロバイダーが同じサービスラベルを説明しているが、UDPヘッダーに触れているのは片方だけだ。違いは見た目ではなく、MPLSをUDPの中に入れると外側のIPネットワークが見えるものが変わり、したがって並列リンク間でハッシュできるものも変わる。誰が導入できるかも変わる。

階層は覚えられるほど短い。外側のIP、次にUDP、次にMPLSラベルスタック、次にサービスペイロードであり、ラベルスタックは消えず、ラベルスイッチングを再開する端点での転送を今も決めている。

UDPエンベロープが加えるもの

RFC 7510はこのカプセル化をUDP宛先ポート6635で定義し、送信元ポートフィールドを使ってフローエントロピーを運ぶ。カプセル化する装置が、何をフローとみなすか、値をどう導くかを決める。標準は意図的に単一のハッシュを義務づけておらず、これはベンダーの挙動に余地を残し、同じトラフィックミックスに対してふたつの実装が異なる分布を生み得ることを意味する。値はアンダーレイに差し出されたヒントとして読み、標準が下すルーティング判断として読まないことだ。

利点は間接的だ。外側の五つ組で負荷分散するトランジットネットワークにはハッシュできるものができたが、裸のMPLSパケットが提供できたのはおそらく最上位ラベルだけだった。それが役立つかは、分散を行うプラットフォームと、実際にどのフィールドを考慮するかによる。

エントロピーは帯域ではない

利用可能なリンクへフローをより均等に配ることは、それらを一本のより速い経路にまとめることとは違う。ひとつのアプリケーションフローは依然として一本の経路を通り、フロー単位の分散は着地したリンクの容量を超えられない。この仕組みは均等な分布も保証せず、ハッシュ関数に良い入力を与えるだけだ。

再順序化が許容できる場合を除き、所定のフローに対してエンベロープを安定させる。送信元ポートがパケットごとに変われば、アンダーレイはひとつの会話を複数の経路に喜んで広げ、再組み立てはアプリケーションの問題になる。目標はフローごとの一貫したエントロピーであり、絶え間ない目新しさではない。

導入の境界は仕様の一部である

RFC 7510は導入を単一オペレーターのネットワーク、または協調するオペレーターの隣接集合に限定し、輻輳を避けるようトラフィックを管理する。また、カプセル化されたトラフィックがそのドメインから逃げないようにするフィルタリングを求めている。これらは飾りの条件ではなく、カプセル化が独自のセキュリティを加えないという事実から導かれる。設計メモの提案ではなく、正当な導入の前提条件として扱うこと。

UDPヘッダーには送信者を認証するものはなく、ペイロードの機密性や完全性を提供するものもない。トラフィックに保護が必要なら、独自の鍵管理を持つ別の仕組みから得る。MPLS-in-UDPを選んでも信頼モデルは上がらない。

保護が望んだハッシュに何をするかに注意する

IPsecや別のセキュリティカプセル化を加えると、トランジット装置がハッシュする外側ヘッダーの形がまったく変わり得る。トンネルモードは内側のUDP送信元ポートを新しい外側ヘッダーの背後に隠すことがあり、慎重に用意したエントロピーが分散の行われる場所で見えないかもしれない。先に暗号化してからカプセル化するのは逆順とは別の設計であり、その差は隣人よりはるかに多くのトラフィックを運ぶリンクとして現れる。

標準が説明する層だけでなく、ワイヤ上に現れる完全なパケットを評価する。MTUと端点の容量を見直すべき点でもあり、UDPヘッダーに加えて何らかのセキュリティオーバーヘッドがあれば、収まるペイロードは減る。

経路全体を見て決める

MPLS-in-UDPをGREなどの代替と、アンダーレイがどのフィールドで分散するか、どれだけのオーバーヘッドを許容できるか、どのセキュリティラップが必要か、ドメイン境界を強制できるかという、自社ネットワークにとって重要な基準で比較する。GREに対する無条件の性能優位を認めるのは、標準が支持しない結論である。

次に実際のトラフィックミックスで試し、メンバーごとのリンク利用率を確認する。実験室で良く見えるハッシュも、すべてのフローが同じタプルを共有すれば一本のリンクに崩れ落ちることがあるため、正直な要約は、カプセル化が、管理することに合意したドメインの中で、アンダーレイが使える情報を露出させるというものだ。