アーキテクチャ ネットワーク アーキテクチャ考 (26) Dis-Aggregation Again! – 分解、そして新たなつながり Dis-Aggregation（当時De-Aggregationと表現しました）のことを取り上げたのは 3 年前（記事）。3 年前とは状況も大きく変わり、今となってはかなり恥ずかしいですが、ある問題に取り組み解決するためには、まずは「分解」することが必要であること、しかし、一体どこまで細かく分解すればよいか、分解する対象が明確でない場合はどうするか、という懸念があり、何が何でも分解すればよいという訳ではない、適度な分解を見極める必要がある、という主旨のことを書きました。 その後 Dis-Aggregation への勢いは増し、シスコにおいても相次いで Dis-Aggregation に関する発表を行いました（IOS-XR、Nexus-OS、IOS-XE）。

先日の BGP インシデント [*1] は影響の大きいものでした。シスコの比較的旧い L3 スイッチでは、TCAM 容量溢れのため SW フォワードに切り替わり、スイッチをリロードしないと復旧しないという問題が発生し、ご迷惑をおかけしてしまいました。そのため、関連するアカウントチーム はお詫びと事態収拾に努めました。 しかししかし。言ってみればこの動作は仕様どおりの動作であり、以前から何度となく注意喚起が行われています [*2]。しかもインターネット経路数は、 トラフィックを細かく制御するニーズが高まっているためか、IPv4 アドレス枯渇後も増加し続けています（Route-Views データによると IPv4 経路は現在 70万を越えています [*3]）。従って、このようなインシデントがなくても、いずれにせよ根本的な対処が必要でした。 でもそうは言っても、突然の 10万経路の誤広報は厳しい

Cisco DNA（Digital Network Architecture）で発表した「The Network. Intuitive.」では、Cisco Catalyst 9000 シリーズに加え、ネットワーク コントローラやデータ分析プラットフォームなど、ソフトウェア面が強調されました。その他にも、あまり国内では取り上げられていませんが、Cisco IOS-XE そのものの実装も大きくリフレッシュされ、内部的にも洗練され、Open IOS-XE として新たに発表されています。 内部アーキテクチャについては、こちらのブログで詳しく解説されていますので、ぜひご覧ください。従来の操作感を保ったまま、内部データベースや機能群の分離を行い、コンテナによるアプリケーション ホスティングなどを段階的に実現しました。その他にも、YANG データモデルが本格的に実装され、いよいよ Netconf をはじ

アーキテクチャ ネットワーク アーキテクチャ考 (16) 「モジュラー性・オープン性とパッケージング、そしてダイクストラ」 これまで私は至るところで、「仮想化アーキテクチャでは、モジュラー性・オープン性が重要。垂直統合してしまったら意味が無い。」と述べてきました。 今でもその考えは変わっていません。コモディティ化した汎用ハードウェアと仮想化アーキテクチャで実現するソフトウェア中心のシステムは、新たなサービスの柔軟かつ迅速な展開、小規模スタートや実験的展開、顧客の細かい要求に応じたテーラーメイド サービスなどに、大きな価値を発揮します。これらは、これまで周到な設備計画が必要だったハードウェア中心のシステムでは実現できなかったことです。しかし、その機能の性能最適化をしたければ、目的に特化したハードウェア システムの方が、コスト、スペース、電力等、あらゆる面で適しています。既に機能が固定化されて

SDN/NFVは、アーキテクチャ変遷の一つの可能性です。通信事業者は、それまでのハードウェアを中心とした基盤設備的なアーキテクチャから、ソフトウェアを中心としたより柔軟で迅速なアーキテクチャにシフトしようとしています。そのため、「アーキテクチャ変遷」を大きなテーマの一つとしているこのBlogでも、SDNやNFVについてのいくつかの、総論的な話題を取り上げてきました。 しかしこの辺でそろそろ一旦振り返り、次のステップに踏み出したいと思います。そこで今回は、振り返りのきっかけになったことと、今後考察して行きたいことを書きます。 Network Programmabilityと宣言的プログラミング 対立する価値の統合 White Box SwitchとForwardingのコモディティ化 Traffic Modelの変化とこれからの可能性 1. Network Programmabilityと宣

前回、前々回と、仮想化における課題を書きました。しかし、これらはまだ初期段階の課題です。現時点での仮想化、少なくとも SP（サービスプロバイダー）領域で NFV と呼んでいるものは、従来のアーキテクチャで実装した機能をほぼそのまま VM でエミュレートしているに過ぎません。仮想化ならではの恩恵を活かすためには、現在のプロセス モジュール構成でよいのか、そのまま VM に載せるのではなくコンテナとして実装した方が良いのではないか、プログラミング パラダイムやコーディング手法自体を見直した方がよいのではないか、などのことを、じっくり吟味する必要があります。 もう一つ。「仮想化の目的はコスト削減」と言う声を多く聞きますが、これには異を唱えたい。もちろん仮想化によって、初期投資を削減することはできます。しかし、ある程度のキャパシティ、性能を実現しようとすると、仮想化だけではコスト削減にはなりません

前回の投稿では、仮想化における運用面の課題を書きました。今回は、もう 1 つの大きな課題である性能面を検討します。 1)  仮想化環境における転送性能最適化について 仮想化アーキテクチャのインフラストラクチャとなるサーバは CPU に特化したハードウェアであるため、当然、NPU（Network Processing Unit）や ASIC（Application Specific Integrated Circuit）に比べると転送性能は低いです。さらに、ハードウェアで行う割り込みや I/O などの各種処理を仮想化レイヤにてエミュレーションする必要があるため、オーバヘッドが大きくなります。 これまで、データセンターの仮想化においては、転送性能よりも柔軟性やスケーリングといった効用の方が大きく上廻っていたため、あまり転送性能の最適化は問題視されてこなかったのだと思います。しかし、通信事業者の

仮想化アーキテクチャの周辺は日々進化していて、落ち着く暇がありません。この春 Cisco は、通信事業者向けの、仮想化環境における Orchestration Layer アーキテクチャとして、ESP（Evolved Service Platform）を発表しました。しかしこれは製品でもなくソリューションでもなく、概念的フレームワークであるため、現場は扱いに困ります。この概念的フレームワーク、深く読めば、ACI（Application Centric Infrastructure）や InterCloud などとも共通する遠大な構想に裏付けられているのですが、いざ、このフレームワークを見せられても、それだけでは何も言っていない。具体的な解を提供しないといけないときに、遠大な構想などを持ち出したら、お客様からは話をはぐらかしているように捉えられてしまいます。この辺が最近感じている難しさであり

最近、「オーケストレーション」という言葉を耳にする機会が増えました。仮想化された要素を構成し、モニターし、柔軟なサービス提供に役立てるために、オーケストレーションは重要な役割を果たします。ETSI NFV（Network Function Virtualization）アーキテクチャを見ても、End-to-End Reference Architecture の大きな部分を、「Management and Orchestration」が占めています。（NFV 参照アーキテクチャについては、以前のエントリをご参照ください。）そこでは、Management and Orchestration の最上位に「Orchestrator」というエンティティが位置づけられていますが、では Orchestration、そして Orchestrator って一体何なのでしょう。本日は、オーケストレーションの

先日 SDN を取り上げたとき、SDN の狭義の定義は「Flow/Path Programmability」ではないか、と書きました。何もかもが“SDN”という文脈に絡めとられ用語が膨張して行くのは、市場の活性化にはよいのかもしれませんが、技術者としては気持ち悪く、どうにも傍ら痛い。そこで、仮にでもよいから定義しておこうと思ったのです。「私が SDN という用語を使う場合、特に注釈がない限りは Flow/Path Programmability という意味です」と言えれば、少なくとも漠然とした会話にならずに済みます。しかし、そんなものが定着することもなく、“SDN 的な何か”が模索され続けています。一方で、「Beyond SDN」というフレーズ[1]も出ています。定義も無かったのに、今度は超えてしまうのか―。:)  マーケティング畏るべし。 SDN – 最初の定義 「Flow/Path P

細々と、ネットワークアーキテクチャに関する連載を続けています。今は希有のアーキテクチャ揺籃期ですから、書いておきたいことがどんどん溜まってきます！が、筆無精、遅筆のためなかなか進みません。前回、NFV（Network Function Virtualization; ネットワーク機能仮想化）を取り上げましたが、今回はその続きを書きます。 NFVにおける-ilities この連載の初回（序論）で、「あるシステムの性質や能力（-ilities）を規定するのはそのシステムのアーキテクチャである」ということを書きました。（特性や能力を表す英単語は Availability、Scalability、Flexibility、Security、Extensibility、Elasticity… のように -ility という語尾がつくことが多いことから、それらが「-ilities」 と総称されます。）

前回のブログ記事では「アーキテクチャ変遷」の一例として SDN（Software Defined Networking）を取り上げました。SDN についてはまだまだ書かなくてはならないことが残っていますが、それらはひとまず今後に廻し、今回は NFV（Network Function Virtualization）を取り上げます。 NFVとは NFV とは Network Function Virtualization の略で、「ネットワーク機能の仮想化」を意味します。欧州電気通信標準化機構（ETSI, European Telecommunications Standards Institute）(*) が NFV ISG (Industry Specification Group) を立ち上げ、米国や日本などヨーロッパ以外の通信事業者も加わって積極的に活動を行っているため、今、SDN と

前回のブログで「次は SDN に関して書く」と宣言してから大分時間が経ってしまいました。SDN（Software Defined Networking）という言葉は、バズワード的な性質が強く、また市場も擾乱しており、個人やコンテクストによって意味することが異なるため、端的に書くのが難しい話題です。 SDNの喧噪 SDN とは「パスやフローといったデータ プレーンの Programmability」または「データ プレーンを Programming すること」を指す、というのが、現時点における最も一般的な定義だと思います。巷では、「SDN/Openflow」のようにわざと曖昧にさせているような記述もよく目にしますが、これは『フローの Programmability、およびそのための 1 つの手段としての Openflow』と捉えられます。また、データプレーンのみならず、コントロール プレーン