要約

  • OpenFlowでは、Barrierがなければ性能上の理由でメッセージが並べ替えられ得る。同じ接続のBarrier Replyは、先行メッセージが応答やエラーを含め処理され、後続処理より前に境界を通過したことを示す。
  • それはデータプレーンの受領証ではない。仕様自身が、Packet-Outを完全に処理しても、輻輳、QoS、閉塞・無効ポートによってパケットがスイッチから出ない場合を明記している。
  • Nick McKeownはOpenFlow/SDNの共同起点をつくった人物の一人である。彼だけの発明としてではなく、八人の原著者と後続コミュニティが明確にした境界から、証拠を段階別に扱う方法を読むべきだ。

返信が正しくても通信は失敗する

FlowModの後にBarrier Requestを送り、期待どおりBarrier Replyが戻った。それでも対象通信が途絶える状況はいくらでもある。ルールが別テーブルに入り、マスクが誤り、上位優先度のエントリーに隠されているかもしれない。groupのbucketやmeterが結果を変え、出口ポートが閉塞し、その先のリンクが落ちているかもしれない。

ここでBarrier Replyが嘘をついたわけではない。「返信あり」を「配送済み」へ拡大した判定が間違っている。

OpenFlow 1.3.5はBarrierの役割を時系列として定義する。Barrierがなければ、スイッチは性能向上のためメッセージを並べ替えられる。一つの接続では、Barrier Requestより前のメッセージを、それに伴う返信またはエラーまで含めて完全に処理する。その後でBarrierを処理して返信し、後続メッセージを開始する。

group作成の後にそれを参照するflowを入れる、ポート変更の後にPacket-Outで使う、flow追加の後にパケットをテーブルへ送る、といった依存関係には不可欠だ。ただしこれは一接続の順序保証であって、ネットワーク全体のトランザクションではない。

プログラム可能な境界を共同でつくる

2008年のOpenFlow論文は、Nick McKeown、Tom Anderson、Hari Balakrishnan、Guru Parulkar、Larry Peterson、Jennifer Rexford、Scott Shenker、Jonathan Turnerの共著である。研究者のコントローラーが実スイッチのflow entryを追加・削除し、その後のパケットは高速なテーブルで処理するという、小さく開いたインターフェースを提案した。Amy-OSPFの例では、ソフトウェアが経路を選び、各スイッチを設定する。

McKeownはOpenFlowとSDNの共同創始者であり、単独の発明者ではない。後年のBarrier仕様も、ONF、導入現場、研究者、ベンダーからの入力で育った。この記事で彼を軸にする理由は、意思決定と実行を分離した設計が、受領証の境界まで考えられるようにしたからだ。

2014年の導入史によれば、実験からのフィードバックがOpenFlow 0.9のBarrier導入につながった。同じ資料は、flow設定時間のばらつき、処理能力の低いスイッチCPU、in-band制御の課題も記録する。診断では制御トレースだけでなく、RTT、CPU、設定レート、アプリケーション測定を照合した。Barrierは多層観測の一要素として生まれた。

「処理済み」は筐体の外まで届かない

仕様1.3.5は、Packet-Outを完全に処理してもパケットの送出を保証しない、と明記する。輻輳、QoS、閉塞ポート、無効ポートによって、OpenFlow処理後に通知なしで廃棄され得る。コントローラー宛てのパケットも、policingや輻輳で失われればPacket-Inが現れない。

flow entryはmatch、priority、counter、instruction、timeout、cookieからなるパイプライン上のオブジェクトだ。処理はtable 0から始まり、複数テーブルを進む場合がある。各表で最優先の一致が選ばれ、metadataやaction setが変わり、groupやmeterを経て出口へ向かう。

Barrier後にcookieとルールを読み戻すのは一段強い証拠である。それでも実パケットがそのルールを選んだとは限らない。制御したパケットでカウンターが増えれば照合は見えるが、次のリンクを渡ったとは限らない。出口カウンターも受信アプリケーションの答えではない。

接続の範囲にも注意が要る。OpenFlowは異なる接続間を同期しない。補助接続で送った処理に対し、主接続のBarrier Replyを使うことはできない。再接続後にはcontroller role、接続世代、スイッチに残った状態を改めて確認する必要がある。

適合性試験が分けた二つの問い

ONFのOpenFlow 1.3.4 Basic Single Table適合性試験では、最大1万flowを追加して削除し、Barrier Requestを送る。要求されたFlow-Removedがすべて届いた後にBarrier Replyが返ることを、一つの制御接続で確かめる。近くのPacket-Out試験はデータ接続を別に使い、パケット受信を確認する。

順序と受信は異なる事実だから、試験も分かれている。運用システムも、その区別を失うべきではない。

OpenFlow 1.5.1のbundleは設定の原子性を高める。複数変更を準備し、まとめてcommitでき、commit時に一つが失敗すれば全体を適用しない。ただし対応は任意で、装置能力の制約がある。bundle成功は設定証拠として強いが、どの本番パケットがどの照合を選び、遠隔サービスが応答したかは示さない。

VeriFlowはcontrollerと装置の間で更新を調べ、ネットワーク全体のinvariantを検証する。複雑な制御コードへの信頼だけでは足りない、という立場だ。モデル上のループやblack holeを見つけられても、物理リンクや受信結果を直接測るものではない。モデル検証と結果観測は補完関係にある。

八段階の受領証

変更を次のように分解すると、誤った昇格を防げる。

  1. 意図：版管理されたpolicyと期待ルール。
  2. 輸送：正しいDatapath ID、role、接続。
  3. 順序：同じ接続のBarrier Replyと先行エラーの照合。
  4. 状態：table、priority、mask、cookie、group、meter、portの読出し。
  5. 照合：本番相当の試験パケットによるcounter変化。
  6. 送出：意図したportまたはqueueの証拠とローカルdrop不在。
  7. 経路：下流観測または能動probe。
  8. 結果：endpointまたはapplicationの受領記録。

変更版、スイッチ、接続世代、transaction ID、cookie、試験ヘッダー、時間窓を同じキーで結ぶ必要がある。そうしなければ古い状態読出しと新しいprobeを合わせ、存在しなかった成功を作ってしまう。

出典