1.タイトル: 「どんなの？ NP (Network Processor)？」 2.ロガー 　　金山　健一（インテック　ネットコア） 　　登田　浩介（NTTコミュニケーションズ） 3.発表者/所属:（以下、敬称略） パネルチェア 永見 健一 (Intec Netcore) パネリスト 　藤本 幸一郎 (NEC Solutions America Inc.) 　　松古 典夫 (古河電気工業) 　 　　石黒 邦宏 (IP Infusion) 4.時間 2003年7月24日(木)　14:30-15:30 5.内容 ---------------------------------------------------------- ■パネルチェア：永見（Intec Netcore） ○本日のパネルセッション焦点、論点 ネットワーク・プロセッサ(NP)は、ソフトウェアの柔軟性とハードウエア の高速性を兼ね備えるルータの内部処理のデバイスとして注目されている。 　また専用のASICを開発するよりはコストが安いという特徴がある。 　応用例はルータやロードバランサなど色々あるが、今回はルータに特化して お話しする。 セッションは以下の分担で進めたい。 藤本さん：NEC americaでNPのサーベイをやっている。NPのチュートリアルを 松古さん：古河電工でNPを使ったプログラマ。プログラマから見たNP。 得意なところ、苦手なところ。 石黒さん：NPの期待される使われ方を。 本セッションを通じて今後の NP の可能性や NP に対しての期待を意見交換 し、今後のインターネットの新しいサービスにつなげて行きたい。 ---------------------------------------------------------- ■パネル発表：藤本（NEC Solutions America Inc.） - ルータの開発自体は日本でやっているが、自身は米国でNPを含むルータ 　　技術の調査をしている。 - NPは、高速なプログラマブルな石だから速い機器が作れそうだが、必ずしも 　そうではない。 ASICに近い高速性とソフトウェアによる柔軟性の両立。ASICよりも柔軟性 　がある。(開発期間、仕様の変更) でもベンダによって色々でASICに及ばない性能など、NPベンダと心中したく 　ないという思いもあり。 - NPを載せる対象は色々ある。トレンドとしては、10G製品だが、ベンチャー 　はハイエンド、大手は1桁下あたりの売れ筋を売る傾向がある。 - 歴史の紹介。現在は大手メーカーも開発を絞りこんでいる。（色々つぶれた 　　会社もある） - NPの分類。パフォーマンス、フレキシビリティどちらよりかでチップベンダ 　をグルーピングできる。両方を追うのは難しい。トレードオフがある。 NPはまだ性能的に未熟な部分もあるので、よりASICに近い性能を出す 　ために、ASICと組み合わせて高速処理させる部分とプログラマブルな部分を 　持たせているものもある。 - まとめとしては、NPは性能とコストのトレードオフ。ベンダー全てがNPを 　使うようになるとPCのように機器に個性がなくなっていくことも懸念してい 　る.。 --------------------------------------------- ■パネル発表：松古(古河電気工業) - 古河電器製品の紹介と自己紹介。ここ2年ほどNPプログラミングをしている。 - NPコード実行環境の紹介 　 メモリアクセスが一番ネックになりやすい。高速/低速なものを組み合わせ 　て使用。NPで賢いことをやろうとするとタイマー機構が必要になる。 - 開発はアセンブラが中心。Cも使えそうだが処理が遅くなる懸念。 コード量に制限があって、サポートするプロトコル数が増えると作りこみが 　厳しい。容量の関係で、IPv6、MPLS、どちらを実装すればいいか？など。 - ハードウェア構成 　 CPUの方で経路計算、NPはフォワーディングに集中。 複数のポートを一つのＮＰで処理させるものが多いが、10Gなんか 　だと複数のNPで実現することも。 - ソフトウェアアーキテクチャ 　 カーネルはBSD系。通常NPでパケットフォワーディングをさせるが、 　IP optionなんかがついてくると処理しきれないのでカーネルへ処理を依頼。 　 アプリ、カーネル、NPでルートテーブルを同期させることも重要 - 効率のいいコードを書くために 　 メモリアクセスを減らす、条件分岐を極力なくす、高速メモリを使うなど 　あるが、一番効いて来るのはスレッド間排他の最小化。共有メモリアクセス 　部分がボトルネックになる。チップ独自の命令セットを活用して高速化を 　図る。 - NPのいいところ 柔軟性が高いところ。 ＃QOSをやっているとカスタマイズが避けられない。 　　　また、いろんなプロトコルを追加できる。シグナリングもできるかも？ - NPのこまったところ 機能と性能はトレードオフ。バグが多い。blackbox的なところがあるので 　内部を情報公開するとよいのでは。 - 最後に...高速で豊富なスレッドのNPがほしい（など）。 -------------------------------------------------------- ■石黒(IP Infusion) パネリストの意向により、ログ取得せず。 --------------------------------------------------------- ■セッション、質疑 Q1:ハード屋さんで言う、「DSP」と「NP」との違いは？位置づけの違いは？ NPのほうがCPUと同機能、マイクロコードレベルのコマンドセットを 　もっているのがNP？ A1:藤本： 　NPは決まった処理はASIC的に持っており、上に載せる機能だけ 　プログラマブルなイメージ。 　ベンダによってASICとNPの領域が未定義な感じ。フレキシビリティの 　ないNPの領域で処理が早いものはASICに近い位置づけ。 　石黒： 　NPは柔軟性と速度のトレードオフがあって、ベンダによってはNPといっても 　かっちり作っていてASICみたいなところがある。 　そういうところは作りこみに2年もかかってしまって、できたころには 　新しいプロトコルに対応できなかったりして市場の動向に追いつけない 　ことがある。時流にあわないという悲劇がある。 　松古： 　NPはアーキテクチャに依存するところが大きい。チップベンダから提供 　されるドキュメントもどっさり来る。 　よくドキュメントを見ると色々工夫ができる場合がある。特にタイマー 　周り。 　　＃チップメーカが思っても見ないところの使い方ができる場合がある。 Q2:マルチキャストの最適化の意味でNPでいいことはあるか？ A2:松古 　最適化ではないが、パケットのコピーをどこでやるか？という話がある。 　チップ依存のところがあって、知っているところでは、スイッチファブリック 　でコピーするものやNP毎やNP内でコピーするアーキテクチャのものがあった。 　スイッチングファブリックでコピーするものは、ストリームの数に制限が 　あった。 　コピーはハードウェアでやったほうが性能的にいいと思うので、NP毎、NP内で 　マルチキャストができるかどうか、については自分も気になっている。 　石黒： 　インテルはサポートせず。力業が必要。IBMはできるかもしれないが正式 　サポートしていない。 　PIMのパケットがきたときにコントロールプレーンにあがってこないバグが 　ある。 　PIM-SMのDraftではcontrol plane、forwarding plane がきちんと分けて 　書かれてあるが、その辺りをきちんと反映して実装できればいい性能の 　ものが出来ると思うが、実際にはできていない。 Q3:ATMはITU-T、IPはIETFという流れがあるが、IETFのスピードにハードウェア 　の実装のスピードが追いついていないのでは。NPはそれに追いつけるのか。 　また、NPの実装屋とIETFにいえることはないか。40Gの処理はできるのか？ A3:松古 　IPv6のネストヘッダーでACL処理の作りこみが大変だった。 　藤本： 　IPv6の設計はソフトウェアとしてはいいが、ハードウェアとしては失敗して 　いると思う。 　石黒： 　NPフォーラムについてIETFに認めさせようという動きがあったが迷走して 　いる。NPに実装している人たちからrequirementがほしいところであるが 　そうなっていない。 Q4:NPについて社内で2-3年前までリサーチしていた。当時からNPに高い 　負荷をかけると熱が発生する問題があった。10Gでも大きなヒートシンクを 　必要としていた。40Gともなると熱密度があがっているとおもう。 　現在の熱に対する対策はどうなっているのか。パイプラインを深くする方法 　もあると思うがるのか遅延が大きくなる問題があったとおもう。 A4:藤本： 　熱の話は存在する。負荷をかけると燃える！ 　半導体屋さんにがんばってもらうしかない。熱の発生はかなりあがってきて 　いると思う。やはりヒートシンクをのせるなどの対策が必要。 --------------------------------------------------------- ■パネリストより　NPに期待すること（まとめ） ○藤本： 　プロトコル処理を柔軟に実装するためにはNP技術は必要。 　たくさんコードをかけることが望ましい。かつ、それでいて速度が落ちない 　ことが望ましい。 　NPと組み合わせる周辺技術の発展に期待。 ○松古： 　担当はQOS。現状のNPはまだ柔軟性が足りない。お客様からの要求を 　制約でかけない部分が結構ある。 　ロジックはすぐに浮かぶがアーキテクチャ上の制限でできないことがある。 　柔軟性＋スピードのあるものが欲しい。 ○石黒： 　まずNPを使うのかという問題がある。が、現在大規模に使われており、 　アジアで多い。自分でASIC作るとコストがかかるのでNPは今後どんどん進化 　すると思う。 　40Gはみえているが、100Gは無理ではないか。GMPLSに一番上が切替わる 　のはいつ？ 　アメリカよりも日本/韓国がその問題に最初にあたるのかも。 --------------------------------------------------------- 6. ロガー所感（金山) 　NPについてまとまった話を聞くのは初めてで大変参考になった。NPは 　ASIC的に高速な処理とプログラマブルな柔軟性の両面を特長に持ち、現在、 　将来において機器開発に非常に重要な技術であると感じた。また、それと 　同時に高速性、それに伴う熱量、ハード的に実装すべき部分の決定の難しさ、 　multicast処理における実装の中身などまだ問題点が存在することも知った。 　今後の更なる研究・開発に期待したい。 ロガー所感（登田） ・今後短いサイクルでますます加速していくと思われる技術革新、装置実装に 　対して、性能を確保しつつ柔軟に対応するためのハードウェアからの 　アプローチとしてNPは必須の技術と感じた。 　　＃旧来のASIC技術 onlyでは昨今のMPLSの機能拡張はこれだけの期間で 　　　対応することは難しかったと思われる。　 　ただしアーキテクチャ上の制限や熱問題、コスト、更なる高速性の追求など 　超えるべき複数の大きなハードルがあることを知った。 　IETFでの標準化作業とそれを実装するハードウェア設計手法との壁が、 　装置実装スピードや、インプリそのものの障害になる可能性があることに 　ついて興味を持った。今後、チップメーカ・NP実装者・それを使う人からの 　標準化作業へのアプローチが活性化し、よりスムーズな装置実装が 　すすむことに期待したい。