進化するインターネット技術/IETFトピックス2016-17

第8回

クラウドの基盤を支える、データセンター接続とその運用管理の技術

インターネット技術の普及に向け、IPv6、DNS、HTTPなど基本となるプロトコルを定めてきたIETF(The Internet Engineering Task Force)。今年11月には、100回目の会合(IETF 100)がシンガポールにて開催される予定である。IETFがこれまで手がけてきたインターネット技術も、技術の進歩と普及により、現在も多くの分野において議論が継続され、まだまだ目が離せない状況が続いている。本連載では、インターネットの普及と発展を目的に日ごろIETFを中心に活動を行っているISOC-JP(Internet Society Japan chapter)メンバー有志が、ここ最近のIETFでの活動状況について紹介していく。

 今回と次回の2回に分けて、RTG(Routing)AreaならびにOPS(Operations and management)Areaの最新動向について紹介する。

 RTG Areaは2017年3月時点で25のWGが、OPS Areaは17のWGが存在し、多岐な活動を行っている。RTG Areaではルーティングプロトコルとして定着したOSPF、BGP、ISISを継続して議論を行っているほか、IPバックボーンに欠かせないMPLSについても議論が続いている。OPS Areaでは、次回述べるNETCONF/YANGのほか、v6ops、growなどインターネットに不可欠な技術(IPv6、BGP)運用管理を継続している。

 そこでこれらエリアの最新動向として、近年の注目技術であるデータセンター接続およびその運用管理を実現する技術にフォーカスし、それにかかわるWGの最新動向について紹介する。

2012年、データセンター接続で注目すべき2つの提案

 大規模のデータセンターネットワーク構築に関しては、モビリティの確保のためにレイヤー2で構築し、ルーターにて終端するようなデザインが当時はよく見られており、IETFにおいても、大規模のARP/NDPをどのように処理をすべきなのかという議論が行われていた。

  • RFC6820: Address Resolution Problems in Large Data Center Networks

 一方、2012年に注目すべき2つの提案がなされた。

 1つはMicrosoftによる実際のデータセンター構築のネットワークデザインを共有した、Using BGP for routing in large-scale data centersである。こちらはIP Closデザインとも言われ、TOR(Top Of Rackスイッチ)からBGPを利用し、トラブルシューティングを容易にし、かつTORにてARP/NDPを終端することができるため、安定したネットワーク運用が提供することができるという提案だ。

 その後、多くの大規模データセンターでこのデザインは採用され、日本においても、ヤフー、IDCフロンティアといったところでも構築されたこともあり、この提案はRFC7938 Informationalとなった。

 もう1つが、新しいデータプレーンの提案、VXLANである。レイヤー2フレームにVXLANヘッダーを取り付け、レイヤー3のネットワーク上でもモビリティを担保することができ、同時にVLAN ID 4096からの開放を実現することができます。ネットワークハードウェアベンダーでの実装や商用シリコン、Linux Kernelでのサポートなど多くの実装も出てきたことにより、事実上のスタンダードなフレームとして認知されるようになったと言うことはできるのではないだろうか。

 こちらもRFC7348 Informationalとなっている。

 ネットワークはBGPで構築し、レイヤー2フレームはVXLANでのカプセル化を行う。これが現在のデータセンターネットワークにおいて、最も安定し、オープンなデザインと言えると思う。

 だが、ここに来て、IETFにおいていくつかの動きが見られる。次の章ではその動きについて解説していきたい。

2017年、データセンターのルーティングプロトコルに新たな提案

 2017年1月25日、RTG WGではデータセンターでのルーティングに特化したインターリームミーティングを実施。Problem Statementとして、現状のデータセンターの状況および将来像をFacebook、LinkedIn、Yandexという事業者が説明し、議論を行った。

 FacebookではMicrosoftのデザインと同様にeBGPを用いて、安定性、プログラマビリティ、IPv6が主要であり、将来、拡張可能であることをゴールとしてデザインをしている(RFC7938の提案者は現在、Facebookにいるため当然なのだが)。Linkedinは自動ディスカバリーや最小設定が望ましく、アプリケーションによってはエンドツーエンドのパス選択が求められると主張しており、大規模のスケールでのISISが望ましいと考えていた。ただし、この大規模スケールでは実績が乏しいのが懸念事項だ。Yandexは、ホップごとにインラインでiBGPのRRとNHSで設定する手法を使ってるようだ。BGPはここでもコントロールしやすいため、好まれていた。

 新しいプロトコルの提案では合計4つの提案があったが、ここでは2つに絞って説明したい。

 1つ目は、IS-IS Routing for Spine-Leaf Topologyである。既存のISISに対して、スケーラビリティを持たせるための新たなSpine-Leaf TLVを持たせるという考え方だ。Spine間ではフルデータベースを持ち、LeafではSpineでのデフォルトルートのみを持つ。これにより、Leafでのスケーラビリティを持たし、障害時の影響範囲を狭めることができる。

 もう1つは、Shortest Path Routing Extensions for BGP Protocolである。こちらは、すでに大規模なデータセンターで実績済みのBGPのパス決定プロセスを、OSPFで使用されているDijkstraアルゴリズムを導入するというものだ。BGPにてノードのメトリックを運ぶ拡張はBGP-LS(RFC7752)で定義済みのため、これをメトリックにし、パス選択のアルゴリズムが変わる。

1)NLRIを発行したものかどうかを確認。発行元のNLRIを優先
2)次にBGP-LSのメトリック情報を元にSPFを実施
3)Router IDの最も高い値

 これによりBGPの特徴、コントロールのしやすさを保持しながら、各ノードがフルトポロジーを見ることができ、リンク障害時には関連のあったルートのみがアドバタイズされるというメリットを得ることができる。

 データセンターのルーティングプロトコルは運用者主導で考えられてきた。さらにスケーラビリティの拡張をすることにより、どのようなプロトコルが選択されるのかを注目したいと思う。

 なお、このインターリームミーティングの内容も踏まえ、IETFではメーリングリストを作成している

 11月にシンガポールにて行われる「IETF 100」で、BoF(Bird of a Feather:ワーキンググループ以前に小さなグループでの議論をすること)の開催を予定している。

データプレーンでは、3つのWGドラフト

 さて、データプレーン側の最新動向はどうだろうか?

 NVO3 WGでは、OAMなどをメカニズムとして保持した、IPベースのデータセンターでのデータプレーンを定めることをWGアイテムにしている。現在、データプレーンのWGドラフトとしては下記3つのドラフトが存在する。

 一度はベルリンのIETFにてそれぞれの提案が合意に達したが、WGでは1つの合意がふさわしいということで、再度デザインチームを形成し、それぞれのプロトコルの実装上の難しさなどをまとめている。

 本結論においては、Geneveが最初の標準化プロトコルとしてふさわしいとは推奨されている。ただし、考慮点にあるように、いずれのケースも、広く適用されているVXLANとの互換性はない。

 データセンターは今までも、独自リングプロトコルや標準化されていないTrillフォーマットやL2フォーマットで、日々成長していく帯域とベンダーロックインされた機器のスペックが合わずに頭を悩ますことも多かったと思う。現状の問題点解決のみではなく、こういった標準化の動向を踏まえることも重要だと言える。