面白いことを発見してそれを面白がる

アーキテクチャ変遷の本質 - MPLS Japan SDN Panel Session - (2)

...その(1)からの続き。

本質を探る、なんてことは、そんなに簡単なことではないし、1時間ちょっとのパネルディスカッションで達成できる筈も無い。

しかし、パネリストに恵まれ（当時は東芝CSR開発・MPLS標準化でも活躍された、MPLS Japan実行委員長である永見さん、Nicira Japanの黎明期メンバーである進藤さん、NECでOpenflowの先導をされている岩田さん、StaratosphereをIIJ浅羽さんと立ち上げられた天才プログラマ石黒さん、そしてつねにInnovativeであるSoftbank松嶋さんという布陣）、会場からの活発なご意見もあり、いくつかのことを悟った。

勿論それは、今という一時点での、個人的単眼的な見方に過ぎないが、メモしておく。

• まず、プレーヤーが変わったということ。現在の主役は、データセンター技術者である。だから、SDNは、データセンター技術者による「ネットワークの再定義」と捉えることもできる。そしてその「ネットワークの再定義」は、まだ始まったばかりである。

• do not re-invent the wheelという言葉がある。同じような目的を達するために既に使える技術が存在するのであれば、それを使え、という鉄則である。しかし、プレーヤーが変わったので、ある程度の調停期間が必要だろう。例えば、vlan spaceを拡張しながらl2 over l3 tunnelを実現する、というときに、STT, VXLANなどの他に、PBB+EVPN、SPBM、LISPなどの、多くの技術およびその組合わせが考えられる。また、別にL2にこだわらず、L3-L4もしくはそれ以上のオーヴァレイがあってもよい。今後、どこがTunnelの起点終点になるか、Networkへの要件は何か、などの詳細議論の中から、いくつかの方式に収斂して行くと思う。

• MPLS黎明期に、多くの技術が出現しては消滅して行った。今回のSDNの場合も、何かが消え何かが残るだろう。類似性を対比させたり、そこから学んだりすることは有用である。但し、あの時こうだったから今回もこうなる、というような予測はできない。勿論、共通点もあるだろう。しかしプレーヤーも違う。環境も違う。

• 集中制御か分散制御か、ソフトウェアかハードウェアか、垂直統合か水平統合か、といったアーキテクチャ議論は、重要であるが、ひとまず本質ではない。SDNは、どちらかというと集中寄り、ソフトウェアっぽい(by 進藤)、垂直統合寄り、であるが、これらの按配は、SDNにせよそうでないにせよ、そのときの技術条件や環境条件により、常に変動する。（但し、自律分散との按分に関して、現時点では、十分な考慮がなされているとは言えない。まだまだやることがある。）

• プレーヤーが違えば常識も違う。例えば、データセンター技術者に取ってはプログラムを書いて自動運用することは「当たり前」であり、「ネットワーク開通」のために、業務が待たされるなんてことは、「ありえない」。また、語彙も違う。ネットワーク技術者が「オープン」と言う時は、「オープンプロトコル」「オープンスタンダード」「相互接続性」などを指すが、データセンター技術者にとっての「オープン」は、「オープンソース」「オープンAPI」だったりする。特に、「オープンソース」はビジネスモデルまでも包含する語彙である。とにかく、言葉一つとっても、そのままでは会話が成立しない可能性が高い。相互理解、そして融合が必要。

私はあまり瞬発力がある方でなく、パネルの進行のときは、これらの気付きを上手く言語化できていなかった。しかし、今後やるべきことが少し見えて来た気がする。超ご多忙の中パネルに快くご参加下さったパネリストの皆様に、そして会場からコメントくださった方、そして実行委員の皆様に、感謝したい。ありがとうございます。

 

P.S.

ところで、このパネルがいけなかったのか、MPLS JapanでのSDN関連プログラムを、「おじさんのおじさんによるおじさんのためのSDN」とtweetしてくれた方がいた。15年前のMPLS黎明期の話なんて持ち出してしまって、申し訳なかった！でも、歳はあまり関係なく、重要なのは謙虚に学ぶこと、そして革新することとだと思う。謙虚に学ぶことを忘れて、単に自分の身につけて来た知識と経験に基づき偉そうにしているおじさん（おばさん）には、絶対に、なりたくない。

でも若者は血気盛んの方がいいよね。私もプログラマ時代に、頭の固い大人は信用できず、「don't trust over 30」などと、息巻いていたことを思い出しました。

アーキテクチャ変遷の本質 - MPLS Japan SDN Panel Session - (1)

 

今年のMPLS Japan 2012は、MPLSの名が冠されるカンファレンスであるにかかわらず、テーマの大半がSDN関連であり、やはりSDN熱が高いことを実感させられた。私はプログラム最後のパネルセッション "MPLS meets SDN -- よくある歴史の繰り返しか、新たなアーキテクチャ可能性か"を担当することになった。

MPLSは今ではかなり成熟した技術に入り、私は既にこのカンファレンスの実行委員を退いているが、しかし今年は、このMPLS Japanというカンファレンスで、どうしてもやっておきたいことがあった。それは、「アーキテクチャ変遷の本質を探る」、ということである。

現在の、このSDNへの市場の過熱ぶりは、ちょうど15年くらい前のMPLSが出始めたときの過熱ぶりによく似ている。1990年代半ば、インターネットの商用普及に伴い、IPトラフィックが急速に増大した。当時は可変長パケットをハードウェアでは処理できなかったため、固定長セル交換であるATMが高速化の鍵と見られていた。しかし、ATMはConnection Oriented型の通信方式であるため、Connection Less型のIPとはそのままでは融和しない。そこで、多くの新たな技術が提案された。LAN Emulation(ATM Forum)、Ipsilon(その後Nokiaに買収される) IP Switch、東芝CSR、IBM Aris、3Com(その後HP) Fast-IP、Cascade(その後Lucent) IP Navigator…、そしてCisco Tag Switching。

IPをConnection Oriented方式のATMに融和させるために、殆どの技術は"flow"に着目した。（IPはDatagram/Connection-Lessであるが、flowはConnection Orientedある。）しかし、flowではステートが細かいため、スケール上の懸念があった。そこで、トポロジーによるflowの多重を提唱したTag Swithchingが市場の賛同を得、Tag SwitchingをMPLS(Multi Protocol Label Switching)という名称で標準化することになり、1997年にIETFにおいてMPLS WGが発足した。市場は、新たな通信方式の可能性に沸き立っていた。

しかし、間もなく可変長パケットもASICで高速処理できるようになり、高速転送技術としてのATMの必要性は無くなった。そのためATMとの融合のための技術としての、MPLSの必要性も無くなった。しかし、MPLSではTunnel/Overlay・VRF（仮想ルーティングインスタンス）などのネットワーク仮想化、Traffic Engineeringを実現したため、L2/L3 VPN提供技術やバックボーン仮想化技術として普及し、現在に至る。

SDNは、IPに捉われないアーキテクチャを一から考える(clean slate)プロジェクトであるGENIに端を発している。そこでまず提唱された技術が、Control PlaneとData Planeを分離し、Data Planeを、高速で安価なCommodity Switchに処理させるというOpenflowであるが、これはLAN Emulation, Ipsilon…などのアーキテクチャに結構似ている。Commodity SwitchをATM Switchに置き換えれば、殆どdeja-vuな感じがする。その他にも、Openflowの"Reactive vs Proactive"議論は、MPLSの"flow driven vs topology driven"に似ているし、また、Nicira CTOのMartin Casadoも、MPLSが既に実現したこと（具体的には、コアとエッジの機能分解、ラベルによるend-hostアドレスのコアからの分離、明示的なpath setup)に学ぶべき、というような主旨の論文(http://yuba.stanford.edu/~casado/fabric.pdf) を書いている。

また、プログラマビリティ、集中制御の要求は、SDN以前にも脈々と存在していた。古くはIN(Intelligent Network)、最近でもMegaco, Soap, Parlay-xなどによるApplication Aware/Policy Aware Control。SDNが可能にする技術それぞれは、別に新しい物ではない。それどころか、あまり市場に受け入れられたとは言い難いものに近い感じがする。しかし、MPLSの時も、多くのhypeが起こり、多くの技術が忘れ去られたが、確かに、長く残った要素はある。

そこで、MPLSによるアーキテクチャ変遷とSDNを対比させることにより、現在の、SDNによるアーキテクチャ変遷の本質を探りたいと思ったのだ。

...その(2)に続く。