マルチベンダに対応したネットワークコントローラを OSS として公開している話 (NTT Tech Conference 2023)

© NTT Communications Corporation All Rights Reserved.
マルチベンダに対応したネットワーク
コントローラを OSS として開発している話
NTT コミュニケーションズ
イノベーションセンターテクノロジー部⾨
Testbed-Service PF PJ
⽵中幹

View Slide

© NTT Communications Corporation All Rights Reserved. 2
名前: ⽵中幹 (たけなかもとき)
所属: イノベーションセンターテクノロジー部⾨
Testbed-Service PF PJ
出⾝: 兵庫県加古川市
趣味: ちいかわ、ポーカー
業務: Multi-AS Segment Routing (SR-MPLS, SRv6)
に関する技術検証
SR網運⽤効率化のためのコントローラ開発
=>本セッションの関連内容
Testbed の運⽤・更改
⾃⼰紹介

View Slide

Pola PCE
Segment Routing ネットワークにおいてパス管理を⾏うことができるネットワークコントローラ
Go ⾔語による実装
• クライアントサーバシステムを導⼊しやすい標準機能
RFC/I-D 準拠・マルチベンダ対応
• ルータとの通信に利⽤するプロトコルが双⽅を満たす実装
OSS 公開
• コミュニティによる既存機能のメンテナンス & 新規機能の追加
• 利⽤者が増えることによるクライアント実装の充実
• NTT Com のプレゼンス向上
本セッションでは Pola PCE の開発・運⽤の中で得た知⾒をお話しします︕

View Slide

本セッションで話すこと・話さないこと

View Slide

本セッションで話すこと
Pola PCE を OSS として実装してみて
ü RFC/I-D 準拠・マルチベンダ対応したネットワークコントローラ実装について
• RFC/I-D に準拠した実装
• マルチベンダに対応した実装
ü OSS 化するにあたって
• プロダクトを使ってもらうための⼯夫
• コントリビュータを増やすための⼯夫
• 良いコードを書くための⼯夫
ü Go ⾔語でクライアントサーバシステムを実装してみた感想
• 学習コストについて
• goroutine と channel によるサーバ実装
• interface を使ってコード整理

View Slide

本セッションで話さないこと
ü OSS の詳細
• 発表資料
https://speakerdeck.com/watal/da-gui-mo-srwang-falseyun-yong-woxiao-lu-hua-
surunetutowakukontororafalsekai-fa-ntt-tech-conference-2022
• Pola PCE に関するブログ
https://engineers.ntt.com/entry/2022/12/20/090000
• GitHub
https://github.com/nttcom/pola
ü Segment Routing 技術に関する話
• 発表資料
https://mpls.jp/2021/presentations/20211101_MPLSJAPAN_NTTCOM_tajima_pub.pdf
• ブログ
https://engineers.ntt.com/entry/2022/06/13/090000
ü NTT グループにおいて OSS 公開にいたるまでの事務的な⼿続きあれこれ

View Slide

Pola PCE (再掲)
Segment Routing ネットワークにおいてパス管理を⾏うことができるネットワークコントローラ
Go ⾔語による実装
• クライアントサーバシステムを導⼊しやすい標準機能
RFC/I-D 準拠・マルチベンダ対応
• ルータとの通信に利⽤するプロトコルが双⽅を満たす実装
OSS 公開
• コミュニティによる既存機能のメンテナンス & 新規機能の追加
• 利⽤者が増えることによるクライアント実装の充実
• NTT Com のプレゼンス向上
TCP コネクションの上で新しめのプロトコルを
複数のクライアント(ルータ)と対話するネットワーク管理サーバのようなもの

View Slide

RFC/I-D 準拠・マルチベンダ対応した
ネットワークコントローラ実装について

View Slide

RFC/I-D に準拠したサーバ実装
例えば HTTP サーバの場合...
引⽤: https://gobyexample.com/http-servers
サーバ機能に必要な
• クライアントからのリクエストパケットの受信
• リクエストパケットの解析
• レスポンスパケットの作成
• クライアントへのレスポンスパケットの送信
を net/http ライブラリが⾏なっている

View Slide

RFC/I-D に準拠したサーバ実装
なぜ net/http ライブラリの処理が多種多様なクライアントとの通信に使えるか?
=> HTTP の標準化された技術仕様に従った通信や処理を⾏っているから
通信プロトコルはインターネット標準化団体 IETF によって
標準仕様が決められる
RFC(Request For Comment):
IETF の発⾏するインターネット技術仕様などについての⽂書群
⽂書ごとに通番が与えられる
I-D (Internet-Draft):
RFC 登録前の草案⽂書
https://datatracker.ietf.org/doc/html/rfc9112

View Slide

RFC/I-D に準拠したコントローラ実装
ネットワークコントローラ実装において、通信プロトコル⽤のライブラリが
1. あるとき
• 通信部分は既存ライブラリで賄えば良い
• ネットワーク機器との間でどのような情報を受け渡しするかのみ考慮
2. ないとき
• 通信プロトコルライブラリから実装する
• サーバ処理は⾃作プロトコルライブラリを import しつつ書く
本セクション、より正確には
Þ RFC/I-D に準拠したプロトコルライブラリ & コントローラ実装
について⾔及します

View Slide

プロトコルライブラリがない場合...
RFC に従ってパケットの構造とプロトコルセッションの動作を把握して実装する必要有︕
例えば:
• やりとりされるメッセージの種類・⽤途・パケット構造は?
• プロトコルの Capability の指定⽅法は?
• セッション終了の判断は?
実装⽅法
1. 既存製品のコントローラ・ルータ間のセッションをキャプチャしてパケット解析
• 挙動を理解しつつ製品実装を真似したパケットを⽣成するだけのため⽐較的簡単
2. ルータのクライアント実装と RFC/I-D から各挙動をステップバイステップで実装
• RFC を読んで挙動を理解した上で実装しないと動かないので難しいどちらにしても
コードの修正が⾟い... ->->

View Slide

実装中のコード修正
プログラムエラー … コンパイル時・実⾏時にエラーの⾏数とエラー内容を出⼒
プロトコルエラー … パケット解析するしかない...
プロトコルのエラーメッセージ Wireshark の parse エラー
バイト列と RFC を⾒⽐べて各フィールドのデータ・データ⻑・パディングなどが正しいか確認

View Slide

RFC/I-D 実装 == マルチベンダ実装 ?
RFC に沿った実装を⾏えばマルチベンダに対応した実装になる?
HTTP などの枯れたプロトコルの実装に関していえば YES
Ø プロトコルの定義やその挙動が RFC によって詳細に標準化され、また共通認識されているため
⼀⽅で、
新しめのプロトコルに関しては NO
Ø ⼀部、値の定義が TBD (To Be Determined) となっている場合
• 各ベンダーごとにルータのクライアント実装が独⾃で⾏われたりする
Ø プロトコルでの特定の情報のやりとり⾃体が未定義
• 同様に各ベンダーごとに実装が独⾃で⾏われたりする
RFC/I-D のバージョン追跡状況によってルータ側で実装がされていない可能性有

View Slide

マルチベンダに対応したコントローラ実装
セッションごとに Vendor Type のようなものを管理
Vendor Type 判別はセッション確⽴時に利⽤したメッセージなど
から⾏う
良い点:
• マルチベンダ対応ツールとして拡張・利⽤できる
• (RFC 準拠実装が正しく⾏われていれば) ベンダー実装が RFC 準拠に
アップデートされても正常に動作し続ける
悪い点:
• ベンダー実装が “⼀部” RFC 準拠にアップデートされた場合想定しない挙動となる
コード管理に問題もつきまとうが、マルチベンダ環境で動いた時は⼀番楽しい︕

View Slide

OSS 化するにあたって

View Slide

OSS に関与してもらう⼈を増やすために
せっかく OSS 化したので広く関与してもらいたい
• プロダクトを使ってもらうための⼯夫
• コントリビューターを増やすための⼯夫
• プロダクトの品質を⾼めるための⼯夫

View Slide

プロダクトを使ってもらうための
Example
ツールをすぐに試せる環境を準備
ネットワークコントローラとしての課題:
• 管理対象のネットワークそのものがまず必要
• 試す環境の作成はコスト⾼すぎ問題
Example を公開
ワンコマンドでネットワーク & コントローラが準備できる
(⼀部機能に制限があるが) FRRで構成される環境もあり

View Slide

Docker Image を提供中
• 実利⽤時のデプロイ簡略化
• ホスト環境を汚さずにデプロイ
GitHub Actions によってタグを打ったタイミングで作成、アップロードされるように
image は GitHub Container Registry より Download 可能
利⽤開始までの README も完備
プロダクトを使ってもらうための
Docker Image

View Slide

コードの⽤途ごとに配置するディレクトリを決定
プロトタイプ作成段階で勉強会 & 設計会実施
Pola PCE においては
• ディレクトリ構成は Standard Go Project Layout
(https://github.com/golang-standards/project-
layout) を踏襲
• ディレクトリの⽤途・コードの配置・各命名規則は
GoBGP (https://github.com/osrg/gobgp) を踏襲
あらかじめの設計で機能拡張やリファクタリング
のストレス減
最初期のディレクトリ構成案
コントリビュータを増やすための
リポジトリ設計

View Slide

実装の対象となる RFC/I-D が多い
RFC 5440, 8231, 8281, 8664
pce-segment-routing-policy-cp など
各構造体や定数などに対象となる RFC/I-D の番号・
セクションを記載
=> コードや挙動の理解補助
コントリビュータを増やすための
RFC 対応コメント

View Slide

ディレクトリの定義は済んでいるため、細かいファイル単位での整理
before (Pola PCE v1.0.0)
after (Pola PCE v1.2.1)
コード修正や機能追加の際の修正箇所特定が容易に︕
プロダクトの品質を⾼めるための
リファクタリング

View Slide

コード品質評価
コードの品質を定量的に評価したい
Go report Card を⽤いてオンラインで評価
• go vet
• 問題となり得る疑わしいコードがないか
• gofmt
• コードに整形できる箇所がないか
• gocyclo
• 循環的複雑度の⾼い関数がないか
• ineffassign
• 無駄な変数割り当てがないか
• license
• ライセンスがあるか
• misspell
• ミススペルがないか
README にバッジをつけられる

View Slide

単体テスト、結合テスト共に未実装(犯罪)
ü 単体テスト
• 単なるサボり
• ⼈⼿が...機能拡張優先...
• プロトコルエラーの解消に貢献しづらい
• VS Code の Go 拡張機能で⾃動⽣成できるらしい (Go Generate Unit Test)
ü 結合テスト
• ないのがキツすぎる
• 拡張・リファクタリング後の IPv4/IPv6 での動作確認に⼤体 30m ~ 1h ほど
• テストのためのマルチベンダネットワークがそもそも必要
• できれば GitHub Actions で⾃動化したい
ネットワークコントローラのテスト⼿法のアドバイス募集中...︕
Test について

View Slide

Go ⾔語でクラサバシステムを実装してみた感想

View Slide

学習コストについて
開発者 2⼈とも Go をまともに触ったことがなかった
Go 不安ポイント:
• 特殊な基本構⽂
• goroutine と channel による並⾏処理
• interface の⽤途
どのスレッドで何を実⾏するかをイメージして構成を練れば実装は⽐較的容易

View Slide

なぜ Go?
クライアントサーバシステムのサーバ実装と相性が良さそうな標準機能が豊富
goroutine … 指定した関数をマルチスレッドで⾮同期に実⾏するための機能
各セッションごとにスレッドを分けて簡単に管理するなどが可能
channel … スレッド間で情報(データ・シグナル)を共有する機能
分割されたスレッドから分割元スレッドへ同期処理を依頼することが可能
goroutine で簡潔にセッションをスレッド分割しつつ、必要に応じて channel で同期処理が可能

View Slide

サーバ実装のサンプルモデル
サーバ
クライアント
サーバ操作者
gRPC サーバ
クライアント
クライアント
TCP コネクション待受
TCP コネクション
上位層
プロトコル
処理
上位層
プロトコル
処理
上位層
プロトコル
処理
サーバ情報の
受信・更新
コネクション
維持
プロトコルでの
情報交換
①
①
②
③
② ②
③
③

View Slide

Go によるサーバ簡易実装例
サーバメインスレッド
gRPC Server ⽤
スレッド
待機⽤スレッド
error
受信待ち
goroutine での
スレッド分割
channel での
同期処理
メインスレッドから 2 スレッド作成
• gRPC リクエストの待ち受け
• クライアントとの通信待ち受け
どちらかのスレッドで処理が失敗した場合
プログラム終了
実装ポイント① 実装ポイント② 実装ポイント③
TCPコネクション
⽤スレッド1
⽤スレッド2
⽤スレッド3
⽤スレッド
TCP上位層プロトコル
処理⽤スレッド
終了受信待ち
&
Keepalive
TCP コネクション待機スレッドから
クライアント要求に応じてスレッド作成
各コネクションスレッドで処理が失敗・終了
してもコネクション待機スレッドは認知しない
TCP コネクションスレッドから
上位層プロトコルの処理スレッド作成
プロトコル処理スレッドからの
close シグナルを待ちながら Keepalive

View Slide

実装ポイント①
サーバ全体処理: サーバメインスレッド
gRPC Server ⽤
スレッド
goroutine
goroutine
channel channel
error
受信待ち

View Slide

実装ポイント②
TCP コネクション待機処理: TCPコネクション
TCP コネクション⽤
スレッド1
goroutine
スレッド2
goroutine
スレッド3
goroutine

View Slide

実装ポイント③
TCP コネクション処理: TCP コネクション⽤
スレッド
TCP上位層プロトコル
処理⽤スレッド
goroutine
channel
終了受信待ち
&
Keepalive

View Slide

まとめ
• RFC/I-D 準拠実装とマルチベンダ対応実装の⽅法
• RFC 準拠とは
• 必ずしも RFC/I-D 準拠 ≠マルチベンダ対応ではない
• 実装⽅法について
• OSS 化に向けたプロダクト整理
• 公開したプロダクトをさせるために⾏なった⼯夫について共有
• プロダクトが繁栄することを願って...
• Test は近いうちに実装しないといけない
• Go でクラサバシステムを実装して⾒た感想
• ⾮同期処理が簡単に書けるのでサーバ実装との相性は良い
• interface の仕様に馴染むのが個⼈的には難しい

View Slide

※画像背景⽤（淡⾊）
スライドマスターよりコピー＆ペーストにて使⽤ください。

View Slide

※背景画像使⽤イメージ
38

View Slide

マルチベンダに対応したネットワークコントローラを OSS として公開している話 (NTT Tech Conference 2023)

マルチベンダに対応したネットワークコントローラを OSS として公開している話 (NTT Tech Conference 2023)

Motoki Takenaka

More Decks by Motoki Takenaka

Other Decks in Technology

Featured

Transcript