Cisco Japan Blog
Share

ネットワークアーキテクチャ考 (4) 「SDN!」


2013年7月15日


前回のブログで「次は SDN に関して書く」と宣言してから大分時間が経ってしまいました。SDN(Software Defined Networking)という言葉は、バズワード的な性質が強く、また市場も擾乱しており、個人やコンテクストによって意味することが異なるため、端的に書くのが難しい話題です。

SDNの喧噪

SDN とは「パスやフローといったデータ プレーンの Programmability」または「データ プレーンを Programming すること」を指す、というのが、現時点における最も一般的な定義だと思います。巷では、「SDN/Openflow」のようにわざと曖昧にさせているような記述もよく目にしますが、これは『フローの Programmability、およびそのための 1 つの手段としての Openflow』と捉えられます。また、データプレーンのみならず、コントロール プレーンやマネージメント プレーンの Programmability を意味する場合もあります。ルータやスイッチのSDK、シスコで言うと ONE-PK(Open Network Environment-Programmers’ Kit)を使えば、データプレーンのみならず、設定・照会可能な要素のほぼすべてを、API で操作することができます。これらは、上位システムへの抽象化・API 提供への要請に応えようとするものです。(なおこれらの API は、共通的なものから、IETF の I2RS Working Group にて標準化されつつあります。)

さらに、近年のサーバ仮想化、クラウド化による要請により、仮想オーバレイのようなネットワーク仮想化も SDN の文脈で語られます。また、リソース オーケストレーション(コンピューティング、ストレージ、ネットワークといったリソースの割り当て)も SDN に含まれる場合もあります。

一方で、従来から存在した概念が、再度脚光を浴びるようなケースもあります。例えば、アプリケーションやサービス、ポリシーへの Awareness。Netconf/Yangのようなエレメントやデータ モデルに対する Programmability。Legacy System と言うべきNMS(Network Management System)/OSS(Operations Support System)、IMS(IP Multimedia Subsystem)や、3GPP(Third Generation Partnership Project)で規定されたPCC(Policy and Charging Control)等までも含めて、「集中的制御ポイントからのダイナミック制御」という意味で、今や SDN だと言う人もいます。

 

Cisco ONE (Open Network Environment) ⊇ SDN

シスコ社内でも、「SDN」の意味するところは実に多岐に渡ります。昨年(2012年)、シスコはその SDN 戦略として「ONE(Open Networking Environment)」を発表しましたが、ONE の概念は SDN (狭義の)よりも広いです。ONE の概念を一言で表すとしたら、”Feedback loop”です。Programmability だけでなく、Collecting(各種情報収集), Analytic(分析)を Feedback Loop として循環させ、動的な価値創造と進化を目指します。そのようなこともあり、部署によって、また個人によって、SDN の意味は様々です。加えてマーケットの過熱ぶりもあり、どうも SDN という言葉には食傷気味にならざるを得ません。ある程度コンテクストを共有していればまだよいのですが、そうでない場合は、「SDN」と言われても何を意味しているのか俄には判別がつかず、困惑すること度々です。乱用は避けたいので、周囲が「SDN」という言葉を発する度に「何それどういう意味?」などといちいち突っ込んでしまいます。とはいえ自分でも頻繁に使ったりするので始末が悪いですね。最近は、少なくとも狭義の SDN と広義の SDN は使い分けようと心がけています。

 

SDN はアーキテクチャか

SDN はアーキテクチャでしょうか。「SDN は手段に過ぎない」という人もいます。確かにそのとおりだと思います。問題は「SDN で何を実現するか」であり、SDN が自己目的化するのはナンセンスです。しかし、「アーキテクチャか?」と問われると、やはりアーキテクチャだと思います。なぜなら、アーキテクチャ フレームワークとしての対極的概念に関して、いくつかの見直しを求められているからです。例えば「集中 vs 自律分散」。インターネットや IP ネットワークでは、これまで専ら自律分散を中心的なアーキテクチャ原理としていましたが、SDN は集中制御方向への見直しを迫りました。また「HW vs SW」では大きく SW 優位に傾斜しています。SDN では、ネットワークは仮想的なリソースとして抽象化されます。

従来のネットワーク アーキテクチャでは、ノードとリンクおよびそのつながり方(トポロジー)が重要な意味を持ちました。トポロジーによって必要となるリンクの数、経由するホップ数、さらには頑健度、アベイラビリティも変わって来るからです。広域網では、リンクの帯域も大きな検討ポイントになります。そして各ノードは自律分散コントロール プレーンによりトポロジーを把握し、自律的に最適パスを計算します。一方 SDN では、物理的なノードやリンク、トポロジーは、ひとまず捨象し、抽象化することが求められます。

このことは、「ネットワーク自体としての価値」よりも、「上位システムからみた時の価値」を求められていると言えるでしょう。ネットワーク中心の視点とは別の視点です。こう考えると、これまでノードとリンクに着目しすぎたあまり、“システム” としての捉え方や抽象化が足りなかったかもしれません。自律分散制御に拘ったあまり、必要以上にコントロール プレーンを複雑にしてきてしまったかもしれません。これまでのネットワークのあり方は、仮想化環境には最適ではなかったのかもしれません。

 

ネットワークのあり方に関する再定義

そこで我々は、新たな視点からのネットワークの再定義に取り組んでいます。自律分散コントロール プレーンのよいところは残した上で、過度に複雑化しそうなところをシンプル化できないか、Cloud Practice から見て使い易い Service Orchestration、WAN Orchestration はどのようにあるべきか、仮想化環境に最適化させたフォワーディング プレーンはどういったものか、アプリケーションやサービス、ポリシーに対応した制御やオーケストレーションはいかに行うべきか、といったことです。

Openflow は、このような時代の要請を捉え、SDN へのブレーク スルーのきっかけになりました。これは素晴らしいことです。一方、Openflow は、Flow Pragrammability のための Primitive な手段に過ぎず、これだけでは充分ではない、少なくとも Openflow だけでは、新たなネットワークのあり方に関する再定義はできないのではないか、と感じています。

また先ほど、ノード、リンク、トポロジーなどの、これまでのネットワーク アーキテクチャの中心概念は捨象されると書きましたが、「捨象される」=「非重要」を意味するわけではありません。重要であっても、いや、重要であればあるほど、顕著な問題がない限りは捨象される場合があります。「健康」や「自然環境」のように。したがって、これまでの知見やその実装を全て捨て去るのではなく、これまでとは別の視点から見直しを行った上で、良いものは残す必要があります。

今後、新たな文脈から、いくつかの素材となる技術が出てきます。開発部門と常に連携しながら、それらの本質と意味を模索します。先日の 日本ネットワーク・オペレーターズ・グループ(JANOG)popup_iconでは、その一端として、Segment Routingに関するご紹介popup_iconをさせて戴きました。しかしまだまだ一端に過ぎません。今後もしっかり地に足をつけて(マーケットの喧噪とは一線を画し:))、お客様や業界の仲間とともに、ネットワークのあり方に関する再定義、プロダクトへの実装、ソリューション提案、そしてアーキテクティングを行っていきたいと考えています。

Tags:
コメントを書く

2 コメント