# ONOS ONOS(Open Network Operating System)は、ネットワーク全体をグローバルな視点で管理するネットワークオペレーティングシステム(NOS)の参照実装であり、本書はONOSを題材にNOSの構造を説明する。第8章は、[[Nicira]] チームが構築した初期のネットワーク OS である Onix を「ONOS の先駆け」と位置づけている(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 8 Network Virtualization]] ch.8 §8.2.2)。水平スケール可能な他のクラウドアプリケーションと同様、疎結合なサブシステム群からなるマイクロサービス的な構成を取り、スケーラブルで高可用なkey/valueストア[[Atomix]]を内部に持つ。[[Open Networking Foundation]] (ONF) のプロジェクトであり、[[Thomas Vachuska]] がチーフアーキテクトとしてこのプロジェクトを率いている(Source: [[Open Networking Foundation]], [[Thomas Vachuska]])。ONFの前身組織であるON.Labは、標準策定を担ったONFと役割を分け、ONOSのようなオープンソースプラットフォーム開発を担っていた(Source: [[Open Networking Foundation]])。 ## アーキテクチャ ONOSは3層構造を持つ。(1) 北向きインターフェース(Northbound Interface, NBI): アプリケーションがネットワーク状態の把握(トポロジーグラフの走査、パケットの傍受)とデータプレーン制御(Flow Objective APIによるプログラミングなど)に用いるインターフェース群。(2) 分散コア(Distributed Core): ネットワーク状態の管理とアプリケーションへの変更通知を担い、内部にスケーラブルなkey/valueストアAtomixを持つ。(3) 南向きインターフェース(Southbound Interface, SBI): 共有プロトコルライブラリとデバイス固有ドライバからなるプラグイン群で構成される。この設計は高度にモジュール化されており、デプロイメントごとに必要なモジュール部分集合のみを構成できる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.1) NBIの守備範囲は広く、制御アプリケーションだけでなく人間オペレータによるアクセスもすべてONOSを介して行われる。gNMI・gNOIによる構成・運用操作、Topology APIによる状態変化の把握、Flow Objective APIによるスイッチ制御が含まれる。ONOSには「in ONOS」か「on ONOS」かの境界が曖昧な、複数レイヤーのアプリケーション・サービスが積み重なる構造があり、ゼロタッチプロビジョニング(ZTP)アプリケーションなどが例として挙げられる。特権カーネルとユーザ空間を分けるsyscall相当の境界を持たず、単一信頼ドメインで動作する点で、従来のOSとは異なる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.1) ONOSは制御アプリケーションが望むネットワーク挙動の抽象的な指定を、各スイッチへ伝達すべき具体的な命令列へマッピングする。高レベルでトポロジー非依存なIntentと、デバイス中心でパイプライン非依存なFlow Objectiveのいずれかをアプリケーションは選択できる。情報はONOSを「下」(southbound plugins経由でパケット傍受・デバイス発見・リンク品質報告などの情報がコアへ)と「上」(NBI経由でアプリケーションがネットワークを制御)の双方向に流れる。ONOSは、OpenFlow・P4Runtimeなどのアダプタを介して、プロプライエタリスイッチ・ベアメタルスイッチ・光デバイス・セルラー基地局といった多様なデバイスの制御に用いられている。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.1) ## 分散コアとサービス ONOSコアは、トポロジー・ホスト追跡・パケット傍受・フロープログラミングなどネットワーク状態の各側面を担当する複数のサブシステムからなり、各サブシステムは固有のサービス抽象を維持する。多くのサービスは分散テーブル(map)として実装され、そのテーブルは分散key/valueストア[[Atomix]]上に構築される。ONOSが用いるコンセンサスアルゴリズムはRaftである。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.2) 主要サービスとして、Host(端末を記録)・Device(スイッチ等のインフラデバイス情報を記録)・Link(デバイス間リンクの属性を記録)・Topology(Device・Link Serviceの上にグラフ抽象を構築し結果整合性で収束)・Mastership(Atomixのleader-electionでスイッチごとのmasterインスタンスを選出)・Cluster(Atomixクラスタ構成とONOSノード情報を管理)・Network Config(デバイス・ホスト・リンク等のメタ情報を、オーケストレータやオペレータから受け付ける)・Component Config(ソフトウェアコンポーネントの構成パラメータを管理)・Packet(パケットの傍受・注入)がある。より高レベルなサービスとしてRoute・Mcast・Group・Meter・Flow Rule・Flow Objective・Intentがある。個々のアプリケーションは独自サービスをこの集合に追加し、Atomixプリミティブ(`AtomicMaps`・`DistributedMaps`)への直接アクセスも可能である。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.2.2) 各ONOSインスタンスの主要な役割は、ネットワーク中の物理スイッチの部分集合を監視・制御することである。ONOSはスイッチごとにmasterインスタンスを選出し、masterのみが制御命令を書き込み、全インスタンスが状態を読み取れる。この選出にはAtomixのleader-electionプリミティブが用いられる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.2.1) ## 北向きインターフェースとFlow Objective ONOSのNBIは、(1) 構成中の各サービスに対応するAPI、(2) Atomixプログラマティックインターフェース、(3) gNMI・gNOI、(4) Flow RulesとFlow Objectivesから構成される。Flow Objectiveには Filtering・Forwarding・Nextの3種があり、「Filtering→Forwarding→Next」という抽象パイプラインを形成する。パイプライン非依存なFlow Objectiveディレクティブを、パイプライン固有のFlow Rule操作へマッピングするのがPipelinerであり、P4プログラムされたパイプラインへのマッピングにはPipeconf(パイプラインモデル・ターゲット固有ドライバ・パイプライン固有translatorの対応関係を`.p4info`ファイルから維持する構造体)を用いる。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.3) ## 南向きインターフェース SBIはProtocol ProvidersとDevice Driversという2種のプラグインで構成される、プラグインアーキテクチャに基づく。Protocol Providersにはプロトコル固有のもの(OpenFlow・gNMI)と、他のONOSサービス経由で間接的に環境と相互作用するもの(DeviceProvider・HostProvider・LinkProvider)があり、ONOSコアとアプリケーションを制御プロトコルの詳細から隔離する。Device Driversは狭い一面の制御・構成能力を実装するモジュール群であり、ONOSアプリケーションとしてデプロイされるため動的にインストール・アンインストールでき、デバイス固有の差異からコードを隔離する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.4, §6.4.1, §6.4.2) ## スケーラブルな性能と高可用性 執筆時点の規模目安は、ネットワークデバイス最大50台・ポート5000・サブスクライバ5万・経路100万・フローエントリ/グループ/メータ500万。性能目安は、構成操作1万件/日・持続フロー操作50万件/秒・ピークトポロジーイベント1000件/秒・ポート/スイッチup検知50ms・down検知5ms・フロー操作3ms・ハンドオーバーイベント(RAN)6msである。実運用のデプロイメントは可用性のため少なくとも3インスタンスを稼働させ、各インスタンスは32コア/128GB RAMのサーバ上でKubernetesによりDockerコンテナとしてデプロイされる。内部モジュール性フレームワークとしてKarafを使い、バンドルにはAtomixも含まれるが、key/valueストアを独立してスケールさせるオプション構成もサポートする。複数インスタンスはAtomixを介してネットワーク状態を共有し、あるインスタンスが障害を起こすとAtomixのleader-electionプリミティブで代替インスタンスが選出される。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.5) マイクロサービスアーキテクチャへ再構成中の後継としてμONOSがある。Atomixを独立マイクロサービス化し、各制御アプリケーション・南向きアダプタを個別マイクロサービス化し、コアをTopology Management(Network Graph API)・Control Management(P4Runtime API)・Configuration Management(gNMI API)・Operations Management(gNOI API)の4マイクロサービスに分割する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 6 Network OS]] ch.6 §6.5) ## 第7章での利用例: SD-Fabric [[SD-Fabric]] はONOS上で稼働する制御アプリケーション群として実装されたリーフスパインスイッチングファブリックであり、第6章で導入されたRoute service・Mcast serviceに大域計算した経路・マルチキャストツリーを投入する。ONOS自体も可用性のため3〜5台のサーバにレプリケートされる。(Source: [[SD-Fabric]]) ## 第9章での利用例: RAN Intelligent Controller (RIC) 第9章は、O-RAN準拠のRAN Intelligent Controller(RIC、SD-RANの中央集権的コントローラ)の例示実装がONOSを再標的化(retargeting)して構築されていることを報告する。RIC実装は第6章で導入されたTopology Serviceを再利用しつつ、RAN固有の2つの新サービスを追加する。Control Serviceは[[Atomix]]ベースのkey/valueストアを使い、どの基地局がどのUE(User Equipment)をサービスしているか・潜在的リンク集合を管理する。Telemetry Serviceは時系列データベース(TSDB)を使い、RAN要素から報告される無線リンク品質情報を追跡する。Link Aggregation Control・Interference Management・Load Balancing・Handover Controlといった制御アプリ(xApps)がこれらのサービスのデータを利用してグローバルに最適な決定を下す。北向きインターフェースはA1(RANにおけるgNMI/gNOI相当)・E2(RANにおけるOpenFlow相当、Service Model抽象を介した制御)・xApp SDK(ONOS実装固有、Flow Objectivesに近い性格)の3つで構成される。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 9 Access Networks]] ch.9 §9.3.2, §9.3.3) ## 第3章(Basic Architecture)での位置づけ *Software-Defined Networks: A Systems Approach* 第3章§3.4は、ONOSの3つの責務(トポロジー管理・構成管理・スイッチ制御)とFlowObjectives抽象、そしてAtomix(RAFT合意アルゴリズム)への依存を、第6章の詳細な内部構造(NBI/分散コア/SBIの3層、Host/Device/Link/Topology/Mastershipなどの個別サービス)の手前にある概観として先に示す。ch.3は特に、「ソフトウェアスタックを上るほどインターフェースの合意形成が難しくなる」という一般論とともに、FlowObjectivesが業界標準に近い個々のスイッチ制御インターフェース(P4Runtime・OpenFlow)とは異なり、ONOS固有で標準化されていない抽象であることを明示する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ch.3 §3.4) ## 関連 - [[Atomix]] — ONOSの分散コアが依拠するRaftベースのkey/valueストア - [[SD-Fabric]] — ONOS上の制御アプリケーション群として実装されたリーフスパインファブリック - [[Open Networking Foundation]] — ONOSを開発する組織 - [[Thomas Vachuska]] — ONOSプロジェクトを率いるチーフアーキテクト - [[P4]] — ONOSのFlow ObjectiveがPipeconf経由でマッピングするプログラマブルパイプラインの記述言語 - [[O-RAN Alliance]] — RIC実装が準拠するインターフェース仕様の策定元 - [[Nicira]] — 先駆けとなったネットワークOS Onixを構築したチーム - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 3 Basic Architecture]] ## 出典 - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 6. - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 9: Access Networks, §9.3.2, §9.3.3. https://sdn.systemsapproach.org/access.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 3: Basic Architecture, §3.4. https://sdn.systemsapproach.org/arch.html - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 8: Network Virtualization, §8.2.2(OnixがONOSの先駆けと位置づけられる文脈). https://sdn.systemsapproach.org/netvirt.html