私は，アラクサラネットワークスでルーターの開発に従事している角川といいます。学生だった1995年からIPv6の研究開発に携わっておりまして，気がつくと早12年になりました。今回は「IPv6ルーター誕生前夜」と題して回顧録をまとめていきたいと思います。回顧録といっても，アラクサラネットワークスはまだ3年目と若い会社です。この話は，アラクサラネットワークスの前身の一つである日立製作所に私が所属していた当時のものになります。

　日立製作所で「GR2000」というルーターをIPv6に対応させるプロジェクトがスタートしたのは，私が入社して1年が経った1998年6月のことでした。この時点ですでに発売されていたGR2000は，通信事業者やプロバイダの基幹ネットワークで使われることを想定したギガビット・クラスのルーターです。このルーターによって，それまでネットワーク業界ではあまり知られていなかった日立製作所の知名度が大きく上がったという製品です。

　GR2000にはIPv4のパケットをハードウエア・レベルで転送する機能がすでに入っていました。このGR2000にどうやってIPv6を搭載するのか――。これを技術的に解決するのが，プロジェクトの課題でした。

　昔話になりますが，今回はGR2000にIPv6を実装する過程を追っていくことで，ルーター開発の一面を実感していただきたいと思います。

■開発フェーズを三つに分ける

　GR2000をIPv6に対応させるに当たっては，ベースとなるソフトウエアに「KAMEプロジェクト」の成果を使うということで，会社の方針がすでに決まっていました。

　KAMEプロジェクトとは，無償で利用できるIPv6の参照コードを作るのを目的に，慶應義塾大学の村井純教授の支援の下，産学のエンジニアが集まって1998年4月にスタートしたプロジェクトです。今ではその成果がMac OS Xにも取り込まれるほど有名になっていますが，その時はまだスタートしたばかりの状態でした。私は，KAMEプロジェクトの第1期メンバーとしてプロジェクトに参加していました。日立製作所は，GR2000にIPv6を搭載することを見据えて，私をKAMEに参加させていたというわけです。

　日立製作所内に発足したGR2000のIPv6チームは，三つのフェーズに分けてプロジェクトを進めることになりました（図1）。

図1●GR2000のIPv6対応タイム・テーブル

　フェーズ1は「ベータ版フェーズ」（1998年6月〜1999年11月）。IPv6ソフトを迅速に製品へ搭載し，先進ユーザーに配布してテストをしてもらい，フェーズ2以降のデザインを決めるためのプロトタイプを固めるまでのフェーズです。

　フェーズ2は「ソフトウエア・ベース製品フェーズ」（2000年2月〜2001年2月）。フェーズ1のベータ版を正式に製品化するフェーズです。ソフトウエアとしてIPv6機能を搭載する製品の実装方針を決定します。製品化に当たっては，コマンドライン・ベースのユーザー・インタフェースを実装します。

　フェーズ3は「ハードウエア・ベース製品フェーズ」（2000年10月〜2001年8月）。フェーズ2でソフトウエア処理していたIPv6パケットの転送処理をハードウエアで実現させるフェーズで，目標は，通信事業者やプロバイダのネットワークにおける本格運用に耐えられる製品レベルを達成することです。

　では，この三つのフェーズについて順に見ていきます。

■KAMEの成果をどのように生かすか

　フェーズ1ではIPv6ソフトウエアを迅速に製品へと搭載することを目的とするとともに，フェーズ2以降のデザインを決めるためのプロトタイプとしての役割もありました。

　KAMEはパソコンで動くFreeBSDなどのBSD系UNIX上で開発しており，この中にはパケットを転送するためのルーターの機能も含まれています。こうしたソフトウエアで実現されたルーターを「ソフトウエア・ルーター」と呼びます。つまり，極端な話，複数のインタフェースをもったパソコンにKAMEをインストールすれば，IPv6のソフトウエア・ルーターが出来上がるのです。

　GR2000のOSはKAMEと同じくBSDを採用しているので，ソース・コードの移植そのものは難しい作業ではありません。しかし，ソフトウエア・ルーターには欠点があります。それは，パケットの転送処理を高速化しずらいという点です。

　GR2000などの高性能ルーターは，パケットの転送処理専用に開発したLSIを複数搭載することで，パケットの転送性能を向上させています。こうした構成を「分散化アーキテクチャ」と呼びます。KAMEを移植するとしても，分散アーキテクチャ上に実装するのは初めての試みです。KAMEのソフトウエアをルーターにどう特化させていけばいいのか，実際にやってみて課題を洗い出すのがプロトタイプの目的です。

■ソフトウエア・ルーターを分散アーキテクチャに載せる

　フェーズ1の流れを見る前に，まずGR2000で採用している分散アーキテクチャについて簡単に説明しましょう。

　分散アーキテクチャとはルーターのアーキテクチャの一つで，パケットの転送処理を複数のモジュールで分散処理する形態を指します。汎用のCPUを搭載する「コントロール・エンジン」と，分散化された「転送エンジン」から成るモジュール構成を取ります（図2）。

図２●GR2000の分散アーキテクチャとソフトウエア・ルーターのアーキテクチャ

　転送エンジンはルーターに複数搭載されており，上限がありますが数を増やすことによって転送性能を向上させ，収容できるインタフェースの数を増やすことが可能です。転送エンジンではASICと呼ばれるLSIがパケット転送のキモになります。このASICはパケットを転送するという目的に特化しているので，柔軟性よりも高速性を重視しています。したがって，転送エンジンはハードウエア処理の独壇場になります。

　ただし，転送エンジンにはASICだけではなくてCPUも搭載されています。転送エンジンのCPUは，インタフェース・レベルで，PPP（point to point protocol）などの簡易なプロトコルを処理するためのソフトウエアが動いています。人間の体で例えるならば，手足の部分に当たります。

　一方，コントロール・エンジンには汎用のCPUが搭載されており，先ほど説明したBSD系UNIXがOSとして動作しています。OSの上では，他のルーターと経路情報を交換するルーティング・プロトコルの処理プログラムや，その計算結果をルーティング・テーブルとして転送エンジンに配布するプログラムなどが動いています。こちらは人間の体で言うならば，頭脳の部分に当たります。

　コントロール・エンジンには，転送エンジンとは逆に，柔軟性が求められます。つまり，ソフトウエアの独壇場です。コントロール・エンジンは原則的に一つです。信頼性を向上するために二つ搭載する場合もありますが，性能が2倍に向上するわけではなく，片方はもう片方が故障したときのために待機しています。

　以上がGR2000の分散アーキテクチャです。

図3●IPv6対応のフェーズ1で採用した方式

　ここにどうやってIPv6を載せるかというのがフェーズ1の課題です。そこで私たちは，フェーズ1では，コントロール・エンジンのCPUを活用し，IPv6パケットをソフトウエアで転送させるアプローチをとりました（図3）。転送エンジンがIPv6パケットを受け取ると，それをコントロール・エンジンに渡します。こうすれば，コントロール・エンジンがソフトウエア・ルーターとしてIPv6パケットの転送処理をこなせるようになります。こうすることで，KAMEのソフトウエア転送エンジンをそのまま使うという方法を採用したのです。

　プロジェクト開始から5カ月後の1999年11月にはベータ版が完成しました。ベータ版の反応は上々で，通信事業者やプロバイダから数多くの引き合いをいただきました。

＞＞【2】を読む