フェーズ3は最終目的の転送エンジンのハードウエア化です。
■拡張ヘッダーの一部だけをハードウエア処理の対象にする
GR2000はそもそも,分散アーキテクチャを採用したハードウエア転送を実現したルーターです。IPv6対応機能をソフトウエアで実装しても,ハードウエアで処理できるIPv4と処理能力を比べてしまうと,性能に大きな差が生じてしまいました。そこで,これまでの検討や実装経験を基にIPv6パケットの転送にも対応したASICを設計し,それをGR2000に実装することで,GR2000のIPv6処理能力を通信事業者やプロバイダのバックボーンでの本格運用に耐えられるレベルにまで持っていくのがこのフェーズの目的です。実際には,フェーズ2と一部並行する形で,別のチームによってハードウエア化の検討が始まりました。
ネットワーク機器から見たIPv6の特徴は二つあります。それは,(1) 128ビットのアドレス長と,(2) 拡張ヘッダーの存在――です。これら二つの特徴により,ハードウエアのデザインに影響が出ました。
特に議論になったのが,IPv6で新しく定義された「拡張ヘッダー」の扱いです。IPv6は表1の通り多様なヘッダー群をサポートしており,拡張ヘッダーとしてIPv6ヘッダーとTCPなどの上位ヘッダーの間に挿入できるようになっています。
表1●IPv6の主な拡張ヘッダー |
IPv6では,任意のヘッダーを必要に応じて付け加えることで,IPv4に比べて柔軟性を向上させたわけです。しかし,その一方で,固定的な処理を高速にこなすというハードウエア処理との相性が悪くなってしまいました。拡張ヘッダーがどういう順番で使われるのかが決まっていれば,まだ何とかできたかもしれません。しかし,使われる順番に“推奨”はあるものの,順序が異なる場合も処理できるようにと仕様で決まっています。これでは,すべてのIPv6パケットをハードウエアによる転送処理の対象とするのは,ほぼ不可能です。したがって,フェーズ3では,現実的にどこまで実装すれば必要十分かを検討しました。
結論としては,拡張ヘッダーがないパケットと,IPv6ヘッダーの直後に「断片化ヘッダー」があるパケットだけをハードウエア処理の対象としました。それ以外のパケットが来た場合は,ソフトウエアによる転送処理(いわゆる「スロー・パス処理」)になるように設計したわけです(図6)。
図6●フェーズ3で採用したIPv6のスロー・パス処理 |
拡張ヘッダーの順序が仕様に準じていないパケットをハードウエアで処理するのは最初からあきらめるとしても,ルーターが処理しなければいけない拡張ヘッダーのパケットはまだあります。その一つが「ホップ・バイ・ホップ・ヘッダー」です。しかし,ホップ・バイ・ホップ・ヘッダーそのものが可変長であるうえ,規格上現実的な用途が提示されていなかったので,ハードウエア処理の対象とすることは見送りました。
なお,スロー・パス処理の部分については,フェーズ2で開発した動作実績のあるソフトウエアがそのまま使えました。
余談になりますが,上記で述べたように,IPv6の拡張ヘッダーはハードウエア・ルーターの開発ベンダーからすると,“困った仕様”です。ハードウエア処理との相性が悪いため,私たちのように,高性能ルーターの処理対象から拡張ヘッダーのパケットを除外してしまうと,その拡張ヘッダーを使った通信は高速処理できなくなります。すると,性能が出ないため,ユーザー側ではそうした拡張ヘッダーを使わなくなり,結果的に誰も使わない仕様になってしまいます。これではせっかく拡張ヘッダーの仕様を作った意味がありません。
本当は,IPv6の標準仕様を議論している段階で,ルーター・ベンダーとして仕様を修正するように提案すべきでした。しかし,IPv6の基本仕様が議論されていた時期は,私はまだ学生で,残念ながらハードウエアの知見も低く,英語のコミュニケーション能力もありませんでした。IPv6を推進してきた技術者の一人として,今でも悔やんでいます。
■こっそり入れたのに使われなかった機能もある
製品化の上で,ソフトウエア処理とハードウエア処理の最も大きな違いは,機能追加や修正にかかるコストと時間にあると思います。ソフトウエアであれば,機能追加や修正にそれほど大きなコストや時間はかかりませんが,ハードウエアで実現したものに機能を追加したり修正したりするには,膨大なコストと時間がかかります。そのため,一度作ってしまうとなかなか修正がききません。そこで,「現時点ではあまり必要性はないけど,将来は必要になるかもしれない」という機能を“隠し機能”と称して,あらかじめ実装しておくことがあります。
フェーズ3の設計当時に使い方が決まっていなかったものに,IPv6ヘッダーで定義されている「フロー・ラベル」があります。実は,GR2000のIPv6対応フェーズ3では,隠し機能としてフロー・ラベルを中継時に書き換える機能をこっそり仕込んでいました。フロー・ラベルが頻繁に使われるようになったら,「こんなこともあろうかと思って,あらかじめ実装しておいたんだよ」と言って公開しようと企んでいました。しかし,フロー・ラベルは現在に至るも有効に使われていません。そのため,お蔵入りのまま後継のASICでは機能そのものが削除されてしまいました。
ハードウエアがらみのエピソードとしては,回路設計終了間際になって,致命的な設計上の不備に気づいたということがありました。
フェーズ2の部分で,複雑な状態遷移をもつNDPをどこに実装するかという話をしました。その状態遷移の中で,NDPエントリを使い,パケットが転送されているかどうかで動きが変わるところがあります。つまり,ハードウエアでのパケット転送処理の中でも「どのNDPエントリを参照して転送したのか」という情報を持たないといけないのですが,その部分が仕様書からきれいさっぱり抜け落ちていたのです。
フェーズ2のソフトウエア・チームで議論していたときにこの問題に気づいて,慌ててハードウエア・チームのところに飛んで行きました。あと数日でASICの回路図を完全にフィックスするという切羽詰った時期だったのですが,この機能がないとNDPが正常に動かなくなるので,無理を言って追加の回路を押し込んでもらいました。
問題を説明すると,ハードウエア・チームが議論しながらホワイトボードに回路図を書き始めたので,「こいつらすごいなぁ」と関心したのを今でも覚えています。
機器を開発するエンジニアの世界では,どれも100点ではない複数の選択肢の中から一つを選ばなければならないというシーンに遭遇することが多々あります。こうしたとき,多くのエンジニアは,「様々な観点で検討して相対的にどれが一番良いのか」を判断することになるわけです。
今回こうしたコラムを書かせていただいたおかげで,改めて過去の決断が「よい判断だったのか,そうでなかったのか」を長期的な視野で見直すことができました。
こうした判断を下すときは,さまざまな基準を考慮して機械的に○×表を作るだけではダメだと思っています。最終的には,経験や勘に頼るところが大きいと思えるからです。IPv6の開発を通じて,このセンスを鍛えることが出来たのは,いい経験だったと思います。
|
|
>>【2】を読む