ソフトウェアで構成可能なネットワーク-仕組み

-私たちはあなたに現代世界へのつながりをもたらしました。

-1か月以内に、抗うつ薬を投与します。



投稿「 SDNにかかる費用 」は、Habrの注目を集めています。sergeykalenikの招待で、ブログをハブに置き 、SDNテクノロジーの分野における国内の成功について話せるようになります。



5年以内に3人の大学教授と民間投資家が12億6000万ドルのスタートアップをどのように構築できたかについてのNiciraの話は、専門家によると、ネットワーク機器市場の電力のバランスを劇的に変化させ、場合によってはシスコの「キラー」になるために（信じることは難しいですが、それにもかかわらず、そのような意見があります。）



投稿へのコメントでは、ソフトウェア構成可能ネットワーク（PKS）自体とは何か、これが実際にどれだけ適用できるかについて多くの議論がありました。 簡単に言うと、コメントは次のグループに分類できます。

• すべてがすでにうまく機能しているため、PKSは必要ありません。
• 興味深いが、何となぜ
• マーケティングでたらめ
• 大学でのテストおよび実生活での厳密な実験室アプローチは、ほとんどの場合適用されません

一般的に、後者の観点は部分的に真実です。 新しいネットワークアーキテクチャの概念は、スタンフォード大学の教授による論文の一部として2007年にのみ提案されました。 それ以来、PCSは主にスタンフォードおよびバークレーの研究室で開発されており、工業規模で試された人はいません。 したがって、PCBの「理想化」と「埋め込み」の両方が少なくとも時期尚早です。



なぜスタンフォード大学とバークレー大学は、ネットワークアーキテクチャの変更を試みたのでしょうか。 キャンペーンの作者自身が説明しているように、Martin CasadoとNick McKeownは、次の点を変更または影響を与えたいと考えていました。

• 従来のアーキテクチャのネットワークはプロプライエタリであり、研究や実質的に外部からの変更が禁止されています。
• トラフィックの指数関数的な成長と、現在のアーキテクチャのネットワークは必要な品質レベルで「ダイジェスト」できないという理論
• ネットワーク上のプロトコルとそのスタックの数

TCP / IPアーキテクチャの主要なネットワークプロトコルは、インターネットのawn明期の70年代に開発されました。当時、誰も送信データの現在の速度と量を予測できませんでした。 2010年、エリックシュミットはTechonomy会議で次のように述べています。「文明の誕生の瞬間から2003年まで、人類によって5エクサバイトの情報が作成されました。2日ごとに同じ量が作成され、速度が増加しています...」



シスコの予測によると、今後5年間でトラフィック量は4倍に増加し、モバイルトラフィックは毎年2倍になります。 2015年までに、ネットワーク上のデバイスの数は世界の人口の2倍になります。 新しいIPv6プロトコルのネットワークアドレスの数は、6.7 * 1023個のアドレスが地球の表面の1 m2にあるような数です（実際、これは潜在的にネットワークに接続できるデバイスの数です）。 現在、3500万人以上のユーザーがSkypeで、Facebookで2億人以上のユーザーが同時に作業しており、72時間分のビデオが毎分YouTubeにアップロードされています。 ビデオトラフィックは消費者トラフィックの50％以上を占めており、そのシェアは増え続けるだけです。 2015年までに、ワイヤレスデバイスからのトラフィックは、固定デバイスからのトラフィックの量を超えます。 確かに、今日、ネットワークプロトコルをゼロから開発し、得られたすべての経験を考慮に入れる機会があった場合、それらはまったく異なるものになるでしょう。



説明のために、すべてのWebサーバーが70年代に開発され、変更されていないことを想像してください。 今ではNginxもApacheもなく、1995年のISSだけがあったかのようです。 残念ながら、これはプロトコルの場合です。



最近まで、現在のネットワークアーキテクチャは、「ツバメの巣」方式に従って開発されました。 問題が特定されると、この問題を解決する新しい問題がTCP / IPプロトコルスタックに追加されました。 たとえば、音声、データ、画像伝送（ISDN）を組み合わせたサービス統合を備えたデジタルネットワークが登場したとき、ビデオトラフィック伝送の問題が発生しました。 問題の本質は、ネットワーク経由でビデオを送信する場合、遅延を許可しない非常に高速なトラフィックを動的に「プッシュスルー」する必要があるため、サービス品質の管理に厳しい要件が発生します。



RSVPプロトコルは、このようなトラフィックに必要なリソースを予約するという問題を解決したばかりであり、それに応じて、必要なレベルのサービス品質を提供できました。 ただし、後で判明したように、このプロトコルも罪のないものではなく、たとえばネットワークのスケーラビリティに関連する多くの制限があります。



別の例は、DHCP（動的ホスト構成プロトコル）プロトコルです。これは、任意のホームルーターに存在します-動的ホスト構成プロトコルは、IPv4ネットワーク用に開発されました。 このプロトコルを使用すると、以前に行われたことに応じて、限られた期間（「リース時間」）またはクライアントがアドレスを拒否するまで、IPアドレスを割り当てることができます。 これにより、IPv4ネットワークの制限されたIPアドレスの問題はある程度解決されましたが、結果として、同じネットワークインフラストラクチャ内の異なる機器への同じIPアドレスの割り当てという別の問題が発生しました。 現在、実際に（アクティブに）使用されているプロトコルの数は600を超えています。そして、その数字は有限とはほど遠いものです。



スタンフォード大学とバークレー大学の研究者は何を始めたのか-彼らは、コンピューターネットワークで制御機能とデータ転送機能を分離することが可能であることを示唆しました。





図1.イーサネットスイッチでのデータの処理と転送



データを送信するとき、イーサネットスイッチはスイッチングテーブルにリクエストを送信します（図1）。 次に、受信した情報に基づいて、スイッチングマトリックスは、ターゲットソースポートへのさらなる処理とデータ転送を実行します。



従来のイーサネットスイッチでは、管理とデータ転送の両方が同時に実装されます。 制御レベルは内蔵コントローラーで表され、データ転送レベルはスイッチングテーブルとスイッチングマトリックスで表されます。 コントローラには、ネットワーク構造に関する情報に基づいてデータ転送に関する決定を行うことができるインテリジェントな機能がいくつかあります。 ただし、意思決定を直接制御することはできません。特定のルールと優先度のセットを設定することによってのみコントローラーを構成できます。 これにより、スイッチとネットワーク全体の機能が大幅に制限されます。 たとえば、このようなネットワークでの「各接続」接続の組織は、第3レベルのネットワークデバイス（ルーター）なしでは構築できません。



スタンフォード大学とバークレー大学の研究者は、ソフトウェア構成ネットワーク（PCN）と呼ばれるアプローチの枠組み内で、制御レベルとデータ送信の分離の問題を解決することを提案しました。







OpenFlowの前は、ネットワークアーキテクチャは、20世紀の初めに手動で切り替えが行われた電話通信と考えることができました（Young lady、Smolny！）。 原則として、管理者は指定されたパラメーターに従って機器を手動で構成し、それ以上の変更は主にハードウェアレベルで実行されます。



OpenFlowを使用すると、そのような「手動」のネットワーク管理から逃れることができます。これは、たとえば、スケーラビリティにプラスの影響を及ぼします。







OpenFlowスイッチは、データ転送レイヤーのみを実装します。 コントローラの代わりに、はるかに単純なデバイスが使用されます。そのタスクは、着信データを受信し、アドレスを抽出し、アドレスがスイッチングテーブルにある場合、スイッチングマトリックスにデータをすぐに送信します。 そうでない場合、スイッチはセキュアチャネル経由でOpenFlow Centralネットワークコントローラーにリクエストを送信し、そこから受信した情報に基づいて、スイッチングテーブルに必要な変更を加え、その後、受信したデータを処理します（機器はもはや手動で再構成されず、ソフトウェアを使用して再構成されます）。



中央コントローラには、ネットワークの構造とトポロジに関する正確な情報があります。 これにより、データパケットのプロモーションを最適化し、特に、IPルーティングを使用せずに、L2レベルで「それぞれと」通信を確立できます（図2）。 また、ソースからデスティネーションまでデータチャネルを「切り替える」ことも可能になります。 その結果、データストリームは個々のパケットではなく、ネットワークを介して送信されます。



したがって、PCBの用語では、このような切り替えテーブルはFlowTable（フローテーブル）と呼ばれます。 各コントローラーには独自の固有のFlowTableがあり、中央コントローラーから受信した情報に基づいてのみこのテーブルを埋めます。



新しいPKSアーキテクチャのネットワークでは、すべてのルーターとスイッチがネットワークオペレーティングシステム（SOS）の制御下で組み合わされ、アプリケーションにネットワーク管理へのアクセスを提供し、ネットワーク設備の構成を常に監視します。



ネットワークプロトコルのスタックと統合されたオペレーティングシステムとしてのSOSという用語の従来の解釈とは対照的に、この場合、SOSは特定のノードではなく、ネットワーク全体の監視、アクセス、管理、リソースを提供するソフトウェアシステムです。 SOSは、すべてのネットワークリソースのステータスに関するデータを生成し、それらへのアクセスをネットワーク管理アプリケーションに提供します。 これらのアプリケーションは、トポロジの構築、ルーティングの決定、負荷分散など、ネットワーク機能のさまざまな側面を制御します。



OpenFlowプロトコルは、特定のベンダーのネットワーク機器への依存の問題も解決します。これは、SDN（SDN）が一般的な抽象化を使用して、ネットワークオペレーティングシステムがネットワークスイッチの管理に使用するパケットを転送するためです。



OpenFlowは、スイッチをプログラミングするための低レベルのプロトコルであると言えます。 SDN / PKSネットワーク用のソフトウェアは、開発のごく初期段階にあり、ほとんどの場合、開発中です。 技術は研究室の壁を去ったばかりなので、近い将来、開発者はアプローチの正確性、新世代ネットワークのスケーラビリティのみを検証する必要があります。



しかし今、メーカーからの関心は非常に大きいです。 たとえば、シスコはNexusおよびCatalyst 37XXスイッチにOpenFlowを追加し、JupiperはJunOS SDKにOpenFlowオプションを追加し、今年6月にEXおよびMXシリーズスイッチラインでのこのテクノロジーの実装を発表しました。 さらに、多くのネットワーク機器メーカーがすでにOpenFlowプロトコルのみを実装するスイッチを提供しており、従来のプロトコルはサポートしていません：NEC、Pronto、Marvell。



ロシアでは、コンピューターネットワーク応用研究センターが 、初期段階でオープンフローのすべての宣言された特性の検証に従事します。 あなたの中に自分の手ですべてを試してみたい人がいるなら、everizhnikova @ arccn.ruに書いてください、私たちは協力してうれしいです。