# SAI (Switch Abstraction Interface) SAI(Switch Abstraction Interface)は、コミュニティ(Open Compute Project)が定義する論理固定機能パイプラインである。ベンダー定義の[[OF-DPA]]と対をなす存在として位置づけられる。SAIは複数のスイッチベンダー・複数のフォワーディングパイプラインにまたがって機能する必要があるため、全ベンダーが合意できる機能の最大公約数に絞られる。設定インターフェースと制御インターフェース(フォワーディングパイプラインを抽象化する側)の2つを含む。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.5.2) SAIは、P4のプログラム可能パイプラインにおける「コミュニティ定義のアーキテクチャモデル」(V1Model・PSA)に対応する固定機能側の存在であり、ベンダー定義のTNA(プログラム可能側)・OF-DPA(固定機能側)と対比される。5種類のPipeline/SDK/ASICスタック比較(図26)では、Broadcom ASICが現在SAI準拠の論理パイプラインに対応する構成が既に存在する例として挙げられ、将来的にはSAIがP4プログラム可能性を取り込み複数ASIC上で動く構成(開発中)も展望されている。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.6) 本章はSAIの制御インターフェースの詳細には立ち入らず、設定APIとあわせて次章(Switch OS)で扱うとしている。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] ch.4 §4.5.2) ## SONiCの土台としてのSAIとPINSによる統合(第5章) *Software-Defined Networks: A Systems Approach* 第5章は、前章が予告した「次章で扱う」SAIの制御インターフェースの話を、[[SONiC]]と[[Stratum]]の比較という文脈で展開する。[[SONiC]]はSAIをベンダー非依存のSDKとして活用するSwitch OSであり、Stratumと同じ需要(ベンダー非依存なSwitch OS)を満たそうとしている。両者の主な違いは、StratumがP4と[[P4Runtime]]によるプログラム可能なフォワーディングパイプラインをサポートするのに対し、SAIは最大公約数的なフォワーディングへのアプローチを取る点にある。SONiCとStratumを統合しようとする取り組み[[PINS (P4 Integrated Network Stack)|PINS]](P4 Integrated Network Stack)の目標は、(1) リモートのSDNコントローラ/アプリがP4Runtimeと[[gNMI]]を使ってSAIと相互作用できるようにすること、(2) データプレーンの機能開発速度を高めるためにP4を使ったSAI拡張を可能にすることの2つであり、いずれもSAIの振る舞いモデル・パイプラインをP4プログラム(`sai.p4`)で新たに表現することに依拠する。(Source: [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] ch.5 §5.4) ## SAI誕生の背景(『実践SONiC入門』第1章) Switch ASICを制御するには、従来ASICベンダーからドライバを含むSDK(Software Development Kit)の提供を受ける必要があった。しかしSDK(およびそれを利用するAPI)はASICベンダー・ASICのモデルごとに異なり、異なるスイッチに対応するネットワークOSを開発するにはスイッチに搭載されたASICに応じて個別に開発する必要があった。加えてSDK利用のライセンス費用が非常に高額でユーザー企業が負担するのは難しい場合が多く、ネットワークOSの開発はネットワーク機器ベンダーや商用ネットワークOSベンダー以外には難しい状況だった。この状況を打破するために生まれたのがSAIである。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] ch.1 §1.2.1) 発端はMicrosoftが自社データセンターで利用するスイッチ用のネットワークOS(SONiC)をベンダーロックインを避けながら効率的に開発・維持するため、複数のASICベンダーに声をかけ共通のAPI仕様を策定したことにある。その仕様はOpen Compute Project(OCP)のプロジェクトとして採択され、現在もOCPで開発が進んでいる。最初の仕様であるSAI v0.9.1(2015年公開)には、Microsoft, Dell Technologies, Facebook(現Meta), Broadcom, Intel, Mellanox(現NVIDIA)が著者としてクレジットされ、1年も経たずにCavium, Barefoot Networks, Metaswitch Networks(現Microsoft)など主要なASICベンダー・ネットワークOSベンダーも加わった。SAIはC言語のヘッダファイルとして提供され、ネットワークOSの開発者はSAIに従ってASIC制御プログラムを開発し、搭載スイッチに合わせて各ASICベンダー提供のライブラリにリンクさせることで、最小限の開発で多様なASICへの対応が可能になった。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] ch.1 §1.2.1) SONiC開発のために生まれたSAIだが、現在ではSwitch ASICの制御APIとしてデファクトとなり、2021年にはMetaが内製するネットワークOSであるFBOSSもSAIの利用を開始した。SAIの登場によりネットワーク機器ベンダーでなくてもSwitch ASICを制御可能となり、仕様が公開されているためSAIを利用したプログラムの公開も可能になった。ただしASICベンダーが提供するSAIドライバはバイナリ形式で提供されるため、SAIの拡張・修正にはASICベンダーもしくはそのライセンスを受けた企業の協力が必要になる点には注意を要する。SAIのメジャーバージョンは概ね6ヶ月ごとにリリースされ(SONiCのリリースサイクルとASICベンダーの負担を考慮した方針)、3ヶ月ごとにマイナーバージョンがリリースされる場合もある。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] ch.1 §1.2.1) ## PINSの実採用例(『実践SONiC入門』第2章) *Software-Defined Networks: A Systems Approach* 第5章がPINSを概念として紹介するのに対し、『実践SONiC入門』第2章はPINSの実際の採用者([[Google]])と共同開発体制([[Open Networking Foundation]]・[[Microsoft]]・Intel)、具体的なデータフロー(SDNコントローラーからの設定がP4Runtime経由でAPPL_DBに登録され、P4OrchがASIC_DBへ変換)を報告する。GoogleのようなハイパースケーラーでなければPINSを自社サービスに利用するのは難しいと評されており、SAIが多数のベンダー・ユーザーに広く普及したのとは対照的に、PINSの採用は限定的である。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 2 SONiCの機能とユースケース]] ch.2 §2.2.5) ## APIとオブジェクトモデルの実体(『実践SONiC入門』第9章) 第1章がSAI誕生の経緯を語るのに対し、第9章はSAIというAPI・オブジェクトモデルの実体そのものを解説する。SAIはSwitch ASICの機能(テーブル、レジスタ、処理回路など)を抽象化したSAIオブジェクトに対し、CRUD(Create/Read/Update/Delete)操作を可能とするインターフェース(API)である。最初の仕様書「SAI-v0.9.1.pdf」の用語に従うと、Switch ASIC SDKを内包(またはそのクライアントと)するアダプタ(Adapter)にSAI APIが実装され、コントロールプレーンスタックに対しSAIの機能を公開するアダプタホスト(Adapter Host)が実行時にアダプタをロードして操作する。SAIはC言語スタイルのヘッダファイル(`*.h`)として定義され、アダプタホストにインクルードされて利用される。SAI以外にもMeta(旧Facebook)のFBOSSやLinux FoundationのDENTといったネットワークOSがSAIを利用する。(Source: [[@2025__Gihyo__実践SONiC入門 - Chapter 9 SAI詳細解説［API・オブジェクト・データプレーンパイプライン］]] ch.9 §9.1.1) Switch ASIC内部のパケット処理パイプラインは、マッチ・アクション・テーブル(ステージ)を順に並列実行する構造を持ち、SAIはこれらのテーブルをSAIオブジェクトとして抽象化する。SAIオブジェクトの多くは`sai_object_id_t`という不透明なIDで参照されるが、`SAI_OBJECT_TYPE_FDB_ENTRY`・`SAI_OBJECT_TYPE_NEIGHBOR_ENTRY`・`SAI_OBJECT_TYPE_ROUTE_ENTRY`のような「エントリ」系オブジェクトは、構造化されたキー(struct)をAPI引数にそのまま持つ点で異なる(`saiobject.h`の`sai_object_key_entry_t`型で統一的に扱われる)。テーブル分割の設計判断(単一テーブルに集約するか複数テーブルに分散するか)とその具体例は[[パケット処理パイプラインのテーブル分割]]を参照。(Source: ch.9 §9.2.1〜§9.2.3, §9.3.5) ## バージョンと定義ファイルの構造(第9章) SAIの定義ファイルは、[opencomputeproject/SAI](https://github.com/opencomputeproject/SAI)の`/inc`フォルダに保存されるヘッダファイルが実質的な仕様となる(`/doc`フォルダのデザイン文書は更新が追いつかない場合があるため)。定義ファイルは、機能共通の`sai.h`(エントリポイント。`sai_api_t`・`sai_api_query()`等)・`saitypes.h`(型)・`saistatus.h`(ステータスコード)・`saiobject.h`(オブジェクト共通の型/メソッド)・`saiversion.h`(バージョン情報)と、機能毎の`sai<機能名>.h`の6分類に整理される。機能追加のたびに`sai_api_t`(enum)へ新しいAPI IDが割り当てられるが、原則(機能内容変更時は新ID)に反してID自体の置き換え・削除も実際には起きている(例: SAI v0.9.4でSAI_API_QOSがSAI_API_QOS_MAPへ置き換え、SAI v1.9でSegment RoutingのSAI_API_SEGMENTROUTEがSAI_API_SRV6へ置き換え)。SAI v0.9.3(2015年10月にタグ付け)でPFC/ECN/WRED等のQoS/バッファ管理APIが追加された時期は、MicrosoftによるDCQCN論文の公開(2015年中旬)とほぼ重なっており、SAIの機能追加が当時のRDMA輻輳制御研究の実装・検証動向を反映していたことをうかがわせる。(Source: ch.9 §9.3, §9.4.1) ヘッダファイルのコメントは人間向けの説明にとどまらず、`@objects`/`@validonly`/`@flags`等のアノテーションとして「Metadata for SAI」という別の生成プロセス(`/SAI/meta`での`make`)に解析され、コンパイル時・実行時のバリデーションに使えるコード(`saimetadata.c`等)へ自動生成される。この生成プロセス自体がヘッダファイルのフォーマットをチェックする役割も兼ねており、コメントの削除・変更はビルドエラーを引き起こしうる。すなわちSAIのヘッダファイルは、人が読むドキュメントであると同時に、機械可読なスキーマ定義でもあるという二重の役割を担う。(Source: ch.9 §9.3.1) ## SONiCにおける実装: sairedisとsyncd(第9章) SONiCのソースコードをSAIに注目して読み進めた時に生じやすい混乱の1つが、Switch ASICとSAI APIで通信するsyncdの他に、orchagentでも同じSAI定義ファイル(`sai.h`, `saistatus.h`)がインクルードされ、初期化コード`initSaiApi()`が`sai_api_initialize()`・`sai_api_query()`を呼んでいることである。しかしこれらの関数はvendorのlibsaiではなく、sonic-sairedisの`sai_redis_interfacequery.cpp`で定義された同名関数であり、実体は`redis_sai`(`SaiInterface`を実装する`ClientServerSai`インスタンス)への委譲である。syncdはコンストラクタ(`Syncd::Syncd()`)で`vendorSai->initialize()`を呼び、実際のSAI APIは`VendorSai`の`m_globalApis`に登録された(vendor提供の)関数を通じて呼び出される——すなわちSAI-v0.9.1仕様書が言う「アダプタホスト」に相当するのは、orchagentではなくsyncdである。(Source: ch.9 §9.5.1〜§9.5.3) orchagentは「どのタイミングでどのSAI APIを呼び出すか」というアプリケーションとしての制御を担当し、SAI API呼び出しと同様の情報を[[Redis]]データベース(ASIC_DB)へ読み書きする。syncdはASIC_DBを通じてSAI APIと等価なインターフェースを提供しつつ、実際にvendor SAIライブラリ(`libsai.so`)にリンクしてSwitch ASICと通信する。この役割分担により、orchagentは数多いベンダー毎のSAIライブラリを意識(リンク)することなくSAI APIを利用可能になっており、この抽象化はsonic-sairedisが提供する。orchagent側の実装(`sonic-sairedis/lib/sai_redis_<機能名>.cpp`)は、機能名(SAIオブジェクト名)をパラメータに取る`REDIS_*`マクロ(`sai_redis.h`)によって生成され、マクロ展開の結果は`redis_sai->create()`のような`SaiInterface`メソッド呼び出しに帰着する。これらはSAI標準のメソッドテーブル構造体(`sai_<機能名>_api_t`)と同一の並び順で束ねられるため、Redis経由の実装は実SAI仕様とまったく同じインターフェース形状を保つ。orchagentとsyncdの命名規約による責務分離全体は[[SONiCのモジュール責務分離]]を参照。(Source: ch.9 §9.5.1, §9.5.4) ## 関連 - [[OF-DPA]] — 対をなすベンダー定義の論理固定機能パイプライン - [[Broadcom]] / [[Open Compute Project]] - [[プログラマブルデータプレーン]] - [[SONiC]] — SAIをベンダー非依存SDKとして活用するSwitch OS。SAI誕生の直接の動機 - [[Stratum]] / [[P4Runtime]] / [[gNMI]] — PINSによる統合の相手側 - [[PINS (P4 Integrated Network Stack)]] — SONiC-Stratum統合の取り組み、実採用例はGoogle - [[ホワイトボックススイッチ]] — SAIが技術的に可能にするハードウェア/ソフトウェア分離の対象 - [[パケット処理パイプラインのテーブル分割]] — SAIオブジェクトが抽象化するテーブル設計のトレードオフ - [[SONiCのモジュール責務分離]] — orchagent/syncdの命名規約とSAI API実装の対応 - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 4 Bare-Metal Switches]] - [[@2021__SystemsApproach__Software-Defined Networks - A Systems Approach - Chapter 5 Switch OS]] - [[@2025__Gihyo__実践SONiC入門 - Chapter 1 ホワイトボックススイッチとSONiCアーキテクチャ]] - [[@2025__Gihyo__実践SONiC入門 - Chapter 9 SAI詳細解説［API・オブジェクト・データプレーンパイプライン］]] ## 出典 - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第2章 §2.2.5. - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 4, §4.5.2, §4.6. - Peterson, Cascone, O'Connor, Vachuska, and Davie, *Software-Defined Networks: A Systems Approach*, 2021, Chapter 5: Switch OS, §5.4. https://sdn.systemsapproach.org/stratum.html - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第1章 §1.2.1. - 海老澤健太郎, 『実践SONiC入門』, 技術評論社, 2025, 第9章 §9.1.1, §9.2, §9.3, §9.4.1, §9.5.