5分でわかる、これまでのSDN動向

この記事は、武蔵野 Advent Calendar 2017 の14日目の記事です。
昨今のSDNブームに便乗して、これまでのSDN動向をまとめてみました。
@hichiharaさんの「SDN 温故知新」のSDN続編として、お楽しみください。

あくまでも、私のこれまでの経験（主観）に基づいた回顧録なので、「あの技術が入っていないんだけど！」とか、多々、コメントがあるかもしれませんが、何卒、ご容赦お願いします。　m(_ _)m ﾍﾟｺﾘ

■ SDN黎明期

この時期から、ICT業界では、OpenFlowなる技術が、注目されるようになりました。
当時は、"SDN/OpenFlow"という用語ばかりが先行し、具体的な実装ユースケースにお目にかかることができず、情報収集に苦労した思い出があります。

(1) OpenFlowのブーム到来 [2011年頃 〜]

□ 当時の回顧録

OpenFlowの情報収集に苦労していた最中、「こんな夜中にOpenFlowでネットワークをプログラミング！」の連載記事を見つけた時には、ホント、目から鱗でした。「これで、私のSDN活動が始められる！」とひとり歓喜したのは、当時の懐かしい思い出です。
あと、SRCHACKさんによるBuffalo無線ルータをOpenFlowスイッチ化してしまう活動「おっさんの小遣いで実現したOpenFlowネットワーク」は、草の根なOpenFlowコミュニティに旋風を巻き起こしました。

その他としては、、、

• OpenFlow仕様策定の役割を担うオープン・ ネットワーキング・ファウンデーション（ONF）が設立されました。
• NECさんが、ProgrammableFlowを製品化して、国内市場を席巻していました。
• OpenFlow業界／コミュニティ活動も、NEC研究者さん等が主導していた感じでした。
• これまでのOpenFlowは、ControllerとSwitchの分離配備モデルが主流でした。

□ 実用化事例

やはり、国内ICT業界では、NECさんのProgrammableFlowを活用した導入事例が、当時のホットトピックスでした。

(2) OpenFlowのマルチテーブル化への対応 [2012年頃 〜]

□ 当時の回顧録

この頃、OpenFlowスイッチが、マルチテーブルに対応するようになりました。
これを契機に、当時の市中の通信技術（たとえば、MPLS）を、OpenFlowで拡張するモチベーションを持った通信ネットワーク分野の研究者／エンジニアが、SDN/OpenFlow業界に注目し始めるようになりました。

その他としては、、、

• OpenFlow1.3スイッチとして、OpenvSwitchがオープンソース化されました。
• それを受けて、Linuxカーネル開発者も、OpenFlow業界に注目し始めました。
• OpenStack/CloudStack等とのOpenFlow連携が注目されはじめました。
• OpenFlowコントローラとして、NOX/Trema/Ryuが、評判になりました。
• Ruby派は、Tremaを選択し、Python派は、NOX/Ryuを選択する感じでした。

□ 実用化事例

当時のOpenFlow導入ターゲットは、DCネットワークに限られていた気がします。たとえば、STP冗長プロトコルの置き換えによるL2冗長（active/active）マルチパスの実現や、マルチテナント環境設定に関わるVLANタグ付与などのL2レイヤの制御手段として、OpenFlowが活用されていたということです。
「SDN作ってみました ~BIGLOBEからみたSDNへの期待と課題~」あたりが、最初だと記憶しております。

□ 当時の個人活動

「家庭用BuffaloルータのOpenFlow化へのチャレンジ」して、OpenFlow環境を家庭で作成して、いろいろとOpenFlow動作を試していました。

■ SDN成長期

SDN/OpenFlowが、Interop等でも大々的に取り上げられるなど、成長期を迎えるになります。最初、学術／研究の領域から始まり、ICT市場に浸透しはじめた時期だと言えます。
あと、OpenFlowの開発者であるマーチン・カサードが所属していたNicra Networksが、VMwareに買収されたときには、「パラダイムシフトの瞬間を迎えた！」と、感じましたね。

(1) OpenFlowルータ時代へ [2013年頃 〜]

□ 当時の回顧録

OpenFlow1.3の技術スペックを満たすOpenFlowスイッチが、ICT市場に投入されるようになると、通常のルータ機器が通信制御として行なっている動作（ルーティング、ポリシング等）をOpenFlowで行なってしまおうという動きが活性化してまいりました。
元来、OpenFlowは、ネットワーク層をプログラマブルに制御できる仕組みだったのですが、ルータ機器的な制御を実現しようとすると、ルータ内部のアーキテクチャおよびトラフィック制御に長けた技術者が必要になるため、この頃から、ルータ機器ベンダが、OpenFlow製品を市場投入するようになりました。

その他としては、、、

• Ryu SDN Frameworkにおいて、BGPSpeakerコンポーネントが利用可能になりました。
• 各社ルータ機器ベンダは、OpenStack Neutronモジュールへ、自社製品用制御用プラグインを提供されるようになりました。
• OpenFlowコントローラとのNorth-boundインタフェース連携を狙ったオーケストレーション技術が台頭し始めた時期もこの頃だと思います。
• この頃から、OpenFlowルータの同一筐体に、Controller部とSwitch部を同居する配備モデルが登場するようになりました。
• データプレーン高速化として、DPDK技術が一般的に活用されるようになりました。
• DPDKのユースケースとして、NTT研究所による、オープンソースなOpenFlowスイッチ"Lagopus"が公開されました。

□ 実用化事例

「SDN/MPLS 2014会議：NTT Communications' Activities/Perspectiveon SDN/OpenFlow」での講演内容では、MPLS-VPNネットワークとDCネットワークとの相互接続点にOpenFlowルータを配備したモデルが発表されました。

□ 当時の個人活動

「Ryu BGPSpeakerの実践活用へのチャレンジ　〜BGP/OpenFlow連携編〜」として、BGP/OpenFlowルータを作成していた記憶があります。懐かしい思い出です。

(2) Transport-SDNのはじまり [2014年頃 〜]

当時、OpenFlowスペック策定に注力を図っていたONFは、トランスポート層のSDNにも力を注ぎ始めて、各伝送装置ベンダと一丸となって、技術革新に貢献してきたと理解しています。Linux Foundation Events講演資料[「Transport SDN in ONF」]より
(http://events.linuxfoundation.org/sites/events/files/slides/5%202016%20ONS%20ONF%20Mkt%20Opp%20Transport%20SDN%20KSethuraman%20Mar%2014%202016.pdf)

ちなみに、ONSイベントでのNTTコミュニケーションズの講演資料「Open and Disaggregated Transport SDN - from PoC to Field Trial -」で、現在の取り組み状況が確認できると思います。

(3) NFVのはじまり [2014年頃 〜]

この頃から、汎用ハードウェア（IAサーバー等）で構成した仮想化基盤上で、仮想アプライアンス（Firewall, IDS, loadBalancerなど）や、5G通信インフラ等をデプロイする新たなアーキテクチャが、ESTI標準化団体が検討を進めておりました。

これまでのSDNと共通する要素技術が多数活用されているとは言うものの、「そもそも、NFVは、SDNなのか？」という指摘が入りそうなので、詳細を知りたい方は、他の有用な技術サイトをご覧ください。

■ SDN熟成期、その後

SDN技術が、ICT市場に浸透した後、みなさんの注目は、AWS/Azure/Googleなどの最新クラウド基盤のトピックスに、移っていったと感じています。
最近は、新たなプロダクトが商品化される際に、"SDN"を売りしたキャンペーンに遭遇する機会がめっきり減ってしまった印象を感じています。

(1) ホワイトボックス・スイッチ時代を迎えて [2015年頃 〜 現在]

ネットワーク機器のプログラマブル化が浸透してきたこの頃から、OCP仕様に準拠したホワイトボックス・スイッチに注目が集まるようになりました。
さらに、仮想アプライアンスとして、動作するソフトウェアルータにも、注目が集まるようになったと思います。

SDN技術を活用して新たな製品が、ICT市場に投入されるようになると、この頃から、"SDN"の拡張を意図して、"SDx"という呼び名で呼ぶことが一般的になりました。これは、従来のSDN要素技術を、新たな領域に活用することによって、さらなる付加価値を高めて行こうというものです。"SDx"の"x＂には、そのようなマインドが込められております。
その一つとして、多拠点をシームレスにつなぐ、エッジコンピューティング技術が台頭し、"SD-WAN"が話題にあがるようになりました。

いっぽう、IETF SPRING-WGが中心になって、SegmentRoutingなるHybridSDNが、ICT業界で話題になってきました。これは、SDN分野として有望とされていたOpenFlowを、バックボーンネットワークに適用する際に顕在化された技術的課題を、いままでと異なるアプローチで解決する試みになります。
こちらは、JuniperさんのApricot2017講演資料「SEGMENT ROUTING FOR SDN」になります。あと、CiscoさんのJANOG40 Meeting資料「Segment Routing チュートリアル」では、SegmentRouting技術での課題解決が、わかりやすく解説されているので、雰囲気的に伝わると思います。

その他としては、、、

• マイクロサービス的なアーキテクチャが一般化して、さらに、Dockerコンテナ技術の台頭により、クラウドオーケストレーション（Kubernetes等）に注目が集まるようになりました。
• 各ルータ機器ベンダでも、SDN製品とクラウドオーケストレーションとの融合が図られるようになりました。
• NTT研究所による、オープンソースなBGPソフトウェア"GoBGP"が公開されました。
• 従来のOpenFlowに変わるフォワーディング技術として、"P4 Language"が公開されました。

■ これからのSDNの未来

SDN熟成によって、培った経験を踏まえて、パブリック/オンフレ／WAN環境の融合を実現する技術（例えば、SD-WAN）が、一般化するようになりました。
これからも、SDxとして、いろんな分野に活躍の場を広げていくことでしょう。

• モバイルネットワークとの融合
• IoTなどセンサー技術との連携
• BigData/デープラーニング技術との連携 ...

以上、ざっと、これまでのSDN動向を振り返ってみました。

■ 参考：SDN時代の最新オープンソースなソフトウェアルータの紹介

最近、オープンソース公開されたソフトウェアルータとしては、
- Zebra2.0
- BIRD 2.0.0 -> http://bird.network.cz

双方とも、昔から存在するソフトウェアルータであり、最近、メジャーバージョンアップを迎えた感じです。ここでは、"Zebra2.0"について紹介します。

□ Zebra2.0とは？

これまで、オープンソースなソフトウェアルータとして、"quagga"、"VyOS"が、よく活用されてきたと思います。これらのDataPlaneコンポーネント部分には、GNU Zebraが適用されていました。
ただ、GNU Zebraは、SDNブーム以前から、存在していたものであり、モノリシックな従来型ソフトウェア構造であったため、新たにコード焼き直しが行われて、"Zebra2.0"としてこの度、公開されました。

ONIC Japan2017にて、Ponto Networks海老澤さん講演の「プログラマブル・データプレーン時代に向けたネットワーク・オペレーション・スタック」にて、Zebra2.0のアーキテクチャが発表されたのは、記憶にあたらしいところです。

□ "Zebra2.0", "GoBGP"の環境セットアップ

以前、「GoBGP活用によるSD-WANプラクティス」において、GoBGPを活用したZebra環境において、通信の疎通性を確認したことがありました。

今回は、Zebra箇所を、"ribd(Zebra2.0)"に置き換えて、BGP動作を確認しました。
なお、具体的な設定方法は、本家リポジトリを参照ください。
https://github.com/coreswitch/zebra/blob/master/docs/gobgp.md

□ 実験ネットワーク構成

以下のトポロジ構成のうち、AS65001に配備されたGoBGP環境（３台）に、おのおのribd(zebra2.0)を配置しました。

まずは、"GoBGP-1"<->"VyOS-1"のBGPネイバー状態を確認します。こちらが、"GoBGP-1"にて、BGPネイバー情報を確認した結果です。
Hold timeが"9秒"と設定されている様子が確認できると思います。

GoBGP-1でのBGPネイバー情報の確認

tsubo@gobgp-1:~$ gobgp neighbor 192.168.0.1
BGP neighbor is 192.168.0.1, remote AS 65000
  BGP version 4, remote router ID 10.0.0.1
  BGP state = established, up for 00:00:56
  BGP OutQ = 0, Flops = 0
  Hold time is 9, keepalive interval is 3 seconds
  Configured hold time is 9, keepalive interval is 3 seconds

  Neighbor capabilities:
    multiprotocol:
        ipv4-unicast:   advertised and received
    route-refresh:      advertised and received
    4-octet-as: advertised and received
    cisco-route-refresh:        received
  Message statistics:
                         Sent       Rcvd
    Opens:                  1          1
    Notifications:          0          0
    Updates:                1          1
    Keepalives:            19         20
    Route Refresh:          0          0
    Discarded:              0          0
    Total:                 21         22
  Route statistics:
    Advertised:             2
    Received:               1
    Accepted:               1
tsubo@gobgp-1:~$ 

さらに、"GoBGP-3"にて、BGPテーブルの状態を確認してみました。ここでのエンドエンド通信の実験では、"0.0.0.0/0"のデフォルトルートを用いて行うように環境構築しました。
よって、"0.0.0.0/0"が、BGPテーブル上に、２レコード、エントリされている様子が確認できました。

GoBGP-3でのBGPテーブル情報の確認

tsubo@gobgp-3:~$ gobgp global rib 
   Network              Next Hop             AS_PATH              Age        Attrs
*> 0.0.0.0/0            172.16.0.1           65000                00:01:14   [{Origin: ?} {Med: 0} {LocalPref: 100}]
*  0.0.0.0/0            172.16.1.1           65000                00:00:42   [{Origin: ?} {Med: 0} {LocalPref: 100}]
*> 192.168.2.0/24       192.168.2.2          65002                00:01:11   [{Origin: i} {Med: 1}]
*> 192.168.101.0/24     192.168.2.2          65002                00:01:11   [{Origin: i} {Med: 1}]

□ 実験方法

エンドエンドにて、ping疎通確認を行なっている最中に、"VyOS-1"を停止させてみます。すると、エンドエンド経路が、停止箇所を迂回するようなにて、ping疎通確認が継続できる様子を確認してみます。ちなみに、"VyOS-1"を停止してから、隣接BGPルータである"GoBGP-1"にて、BGPピア断を検出するのに、"HoldTime値:9秒"の時間を要することになります。その間は、Ping疎通が不達となります。

□ 実験結果

pingを行いながら、"VyOS-1"を停止されたところ、9発のパケットロスが観測されました。

tsubo@tsubo-PC:~$ ping 192.168.3.1
PING 192.168.3.1 (192.168.3.1) 56(84) bytes of data.
64 bytes from 192.168.3.1: icmp_seq=1 ttl=60 time=3.52 ms
64 bytes from 192.168.3.1: icmp_seq=2 ttl=60 time=3.21 ms
64 bytes from 192.168.3.1: icmp_seq=3 ttl=60 time=3.80 ms
64 bytes from 192.168.3.1: icmp_seq=4 ttl=60 time=3.28 ms
64 bytes from 192.168.3.1: icmp_seq=5 ttl=60 time=3.83 ms
64 bytes from 192.168.3.1: icmp_seq=6 ttl=60 time=3.69 ms
64 bytes from 192.168.3.1: icmp_seq=16 ttl=60 time=3.69 ms
64 bytes from 192.168.3.1: icmp_seq=17 ttl=60 time=3.21 ms
64 bytes from 192.168.3.1: icmp_seq=18 ttl=60 time=3.76 ms
64 bytes from 192.168.3.1: icmp_seq=19 ttl=60 time=3.62 ms
64 bytes from 192.168.3.1: icmp_seq=20 ttl=60 time=3.64 ms
64 bytes from 192.168.3.1: icmp_seq=21 ttl=60 time=3.28 ms
^C
--- 192.168.3.1 ping statistics ---
21 packets transmitted, 12 received, 42% packet loss, time 20089ms
rtt min/avg/max/mdev = 3.211/3.547/3.836/0.236 ms
tsubo@tsubo-PC:~$ 

以上、期待どおりに動作していることが確認できました。

■ おわりに

駆け足で、SDN動向を振り返ってきました。
今後も、ネットワークをプログラマブルに制御する技術者マインドをもって、このSDN分野に注目していきたいと思います。