米シスコは2008年3月5日，満を持して次世代エッジ・ルーター「ASR 1000」と，それに搭載する新型ネットワーク・プロセッサ「QuantumFlow Processor」（QFP）を発表した（関連記事）。同製品の記者発表会の場では，NTTのNGN（次世代ネットワーク）へのASR 1000の採用が公表された。NTT採用製品の具体的なベンダー名や製品名が明らかになるのは異例であり，このルーターがNGNの実現で重要な役割を果たしていることを示している。ASR 1000の開発責任者であるシスコのMidrange Routing Business Unit，Vice President兼General Managerのステファン・ダイカーホフ氏に話を聞いた。
 |
| 写真●米シスコのMidrange Routing Business Unit，Vice President兼General Managerのステファン・ダイカーホフ氏 [画像のクリックで拡大表示] |
ASR 1000とQFPの開発は，いつスタートしたのか。
ASR 1000とQFPは，今では一体として扱われているが，もともとは別のプロジェクトだった。
QFPの開発は，5年前の2003年に始めた。当初は基礎的な研究だった。アプリケーションやサービスをネットワークに統合していくためには何が必要か，というところが出発点だ。研究の過程で，新しいサービスを追加し，提供していくネットワーク・インフラを実現するには，ネットワーク機器に全く新しいレベルの計算処理能力が必要だと考えるに至った。これとは別に，4年前の2004年，ASR 1000の開発計画がスタートした。これは，サービスをルーター・レベルで実現する製品が目標だった。そのようなルーターには，どのようなネットワーク・プロセッサやパケット処理デバイスが必要かを検討し，その結果，QFPを採用することとなったのだ。
当初はASR 1000とQFPは別々のプロジェクトだったが，この3年半は一つのプロジェクトとして動いてきた。
NTTのNGNに採用されたのには，どのような背景があったのか。
我々のカスタマーであるNTTとは，いろいろなエリアでいっしょに働いている。そうした活動を通じて，ネットワークで何を提供しなければならないか，という点で我々は同じビジョンを共有している。
NGNは，音声，ビデオ会議，IPTV，データ，IPv4/IPv6――といった様々なサービスをネットワークが提供する。さらにNGNは，10～15年にわたって，新しいサービスを追加し続けることになる。ASRは，サービスを追加するため，ソフトウエア・エンジニアが容易にプログラムを追加・修正できる。それにもかかわらず，高いパフォーマンスを実現している。こうしたASRの強みが，NGNの要件に合致した。
余談だが，英BTも同社のNGN「21Cネットワーク」でASR 1000を採用する予定だ。
ASRの設計時には，NGNの仕様があらかじめ分かっていたのか。
我々がNTTのRFP（request for proposal）に応じたのは，ASR 1000の開発をスタートしてからになる。
NGNは，当初からASRの主要な用途として考えていた。しかし，仕様の詳細まで把握していなかった。さらに，NGN構築後にどのような新しいアプリケーションが登場するかも分からなかった。そのような用途に対応することが，まさにASRを作っていくうえでのキーだった。つまり，将来，様々なサービスを実現する機能を追加しても，パケット処理性能を落とさないようなルーターを開発したかったのだ。
NGNへの採用に当たって，NTTから何かフィードバックや要求はあったのか。
我々は，リード・カスタマから様々なフィードバックや要求を受けている。NTTも例外ではない。NTTのことは，NGNに対する先進的な考えを持つ「リーディング・シンカー」ととらえている。だから，NTTが当社の製品を採用したことはうれしく思っている。
フィードバックの内容には，先進的な技術をルーターに統合するというものがあった。その一例としてSBC（session border controller）を挙げよう。
SBCは，双方向のマルチメディア・コミュニケーションを実現するために必要な機能の集まりだ。QoS，セキュリティ，課金，アドレス変換などの一連の機能で構成されている。
NTTのNGNがユニークなのは，大容量のマルチメディア・コミュニケーションを大規模に取り入れようとしている点だ。NTTのユーザー数は2000万と聞いている。そのくらいの規模で双方向通信ベースのマルチメディア・コミュニケーションを実現するには，SBCに高いスループットが要求される。従来の音声通信に比べて，要件が全く異なる。
ASR 1000は，SBCの機能を10Gビット/秒のスループットで処理できる。つまり，SBCのような複雑な処理を大容量でこなせる能力がある。
このような特徴は，企業ネットワーク向けの機能でも同様だ。例えば，フルステートなファイアウォールを10Gビット/秒のスループットで実現する。他社の装置で同様の機能を実現しようとすれば，スループットはせいぜい1Gビット/秒止まりだろう。
ネットワーク・プロセッサのQFPについて聞きたい。これはどのような構成になっているのか。
QFPは，正確に言えば「パケット・プロセッサ」と「トラフィック・マネージャ」の2チップで構成するチップ・セットだ。社内のコードネームでは，それぞれ「Popeye」（ポパイ）と「Spinach」（ホウレンソウ）と呼んでいる。
パケット・プロセッサは，ルーターが受信したパケットの処理全般を受け持つ。IPアドレスのルックアップ，ファイアウォール，DPI（deep packet inspection），SBCなどの処理を実行する。そうした処理が終わると，パケットはもう一つのチップ，トラフィック・マネージャに渡される。このチップは，パケットのスケジューリングやキューイングを受け持つ。利用できるキューは，12万8000個にも及ぶ。
QFPのイノベーションはパケット・プロセッサにある。パケット・プロセッサは，40個もの汎用プロセッサを1チップに集積したアーキテクチャを採用している。ネットワーク，トラフィック管理，ルックアップ，その他のハードウエア・アクセラレーションなど，様々な特定の処理を，大規模な並列コンピューティングで実現したのだ。
つまり，従来のネットワーク機器では，特定の処理を個別のASICで実装していたが，QFPではたくさんの汎用プロセッサを集積させて実現したということか。
その通りだ。40個あるプロセッサの一つひとつに機能を実装するのに，C言語を利用できるようにした。マイクロコードを利用していた従来に比べ，ソフトウエア・エンジニアの作業効率は大幅に向上する。
個々のプロセッサは，一般的なMIPSベースの命令セット・アーキテクチャを採用している。ただ，ネットワーク用途に最適化している。例えば，必要のない浮動小数点演算や除算の機能は省いている。
どのようにこのアーキテクチャを考えつき，採用を決めたのか。
このアーキテクチャを考えたトリガーは，先進的な機能を一つに統合するとともに，高いパフォーマンスを維持するということにあった。
現在の一般的なネットワーク製品は，ファイアウォールやSBCを実現するのに標準のマイクロプロセッサを使っている。その理由は，アプリケーションがつねに変化しているからだ。柔軟性が必要なので，機能をチップにハードウエア・コーディングするわけにはいかない。その一方で，スタンダードなシリコンでは，我々が必要としているパフォーマンスが出ないのではという懸念があった。QFP開発チームには，このような二つの要件が突き付けられていた。
これらを解決する手段として，40ものプロセッサを1チップに集積することにしたのだ。しかし，40ものコアを1チップに統合しようとすると，最先端の設計が必要となる。スタンダードな設計では間に合わない。そこで，フルの「カスタマ・オン・ツーリング」（COT：ベンダーが自社で半導体の物理設計まで手がける手法）を使うことにした。つまり，先端の設計技術を使ってトランジスタ・レベルで最適化した。
QFPの開発には，5年の歳月と100人のエンジニアを投入し，1億ドル（約100億円）もの開発費を投じたと聞いている。これは，過去のプロジェクトと比べて，どのくらい破格なのか。
プロジェクトのコストは通常開示していないので，過去のプロジェクトとのコスト比較はできない。しかし，シスコの中，あるいは通信業界全体で，通信機器向け半導体に対して行われた最大の投資の一つと言って間違いない。
QFPを作る上での大きな投資の一つが，チームを作ることだった。QFPのチームは，半導体業界全体で見ても「ベスト・アンド・ブライテスト」の人材を集めたと自負している。
当社のハイエンド・ルーターである「CRS-1」のチップ開発チームに加え，当社が買収したハイエンド・ルーターのチップ開発チームが開発に参加した。特に，ナバロ・ネットワークスとプロケット・ネットワークスのエンジニアがチームに加わった。他にも，半導体業界から個別に優秀な人材を採用し，QFP開発チームに加えた。
現在，シスコが考えているNGNは，3GPPやETSI/TISPAN，ITU-Tなどが策定した「IMS（IP Multimedia Subsystem）」準拠という理解でよいのだろうか。
NGNの定義は，カスタマーである通信事業者による。当然，自社のNGN構築にIMSのアーキテクチャを採用するかどうかも通信事業者ごとに異なるだろう。顧客の中には，積極的にIMSでサービス統合を図っているところもあれば，IMSを利用しないところもある。
我々の戦略は，ネットワーク制御のための標準インタフェースはすべてサポートするというものだ。IMS準拠が良い，悪いとサポート対象を限定するつもりはない。
つまり，IMSを含む全ての標準インタフェースをサポートしていれば，カスタマーの通信事業者がIMSに準拠している場合と準拠していない場合にかかわらず，ASR 1000を導入できるということか。
その通りだ。例えば，一台のASRで，あるサービスはIMSを使いながら，別のサービスはほかの制御メカニズムで提供することもできる。そのように，制御メカニズムに依存しないことがASRの強みでもある。
