おはようございます！
トラブルを呼ぶ男GMOコネクトでCTOしている菅野（かんの）こと、さとかん です。
現在、モントリオールで開催されているIETF124において、開催されているインターネット技術に関する国際標準か団体であるIETFで開催されたIETF Hackathonについてまとめてみました。
はじめに
2025年11月1日～2日、カナダ・モントリオールで開催されたIETF 124 Hackathonの参加レポートをお届けします。本記事は全3部作の第1弾として、ハッカソンの概要とネットワーク管理・ルーティング関連のプロジェクトを紹介します。
会場風景 ※会場の皆さんの顔にはモザイク処理を施すなど
イベント概要
基本情報
| 項目 | 詳細 |
|---|---|
| イベント名 | IETF 124 Hackathon |
| 開催期間 | 2025年11月1日（土）～2日（日） |
| 開催地 | モントリオール（Montréal, Canada） |
| 成果発表会 | 2025年11月2日（日）14:00 |
| デモイベント | Hackdemo Happy Hour: 11月3日（月）19:00～20:00 |
スポンサー
- Goldスポンサー: Ericsson
- Bronzeスポンサー: ICANN、CNNIC
成果発表会では、30以上のプロジェクトがその成果を発表しました。発表資料はDatatrackerにて公開されています。
Part 1の内容
本記事では、以下のカテゴリのプロジェクトを詳しく紹介します：
- ネットワーク管理とオペレーション (NMOP)
- ルーティングとトランスポート
1. ネットワーク管理とオペレーション (NMOP)
1.1 MCP for Network Management
プロジェクト概要
このプロジェクトの目標は、従来のネットワーク管理スキルにAI LLM（大規模言語モデル） の理解を組み合わせ、自然言語によるインテントベースのネットワーク管理を実現することです。
主な達成事項
-
CLIコマンドのMCPツール化
- 既存のCLIコマンドをMCP（Model Context Protocol）ツールとしてカプセル化
- 自然言語からネットワークコマンドへの変換を実現
-
MCP + CLIによるクエリと設定
- 自然言語でのネットワーク状態の照会
- 自然言語による設定変更の実行
-
MCP + Netconfによるデータクエリ
- YANGモデルデータへのアクセス
- 構造化されたデータの取得
技術的なポイント
自然言語処理とネットワーク管理プロトコルの橋渡しを行うことで、以下のメリットが期待できます：
- 習熟コストの削減: 複雑なCLI構文を覚える必要が減少
- ヒューマンエラーの低減: 意図を自然言語で表現できるため、設定ミスが減少
- 自動化の促進: LLMによる意図解釈により、より柔軟な自動化が可能
今後の展望
- 完全なNetconf設定のためのYANG統合
- MCPサーバーディスカバリメカニズムの実装
関連リンク
1.2 YANG Provenance Signatures Integrated with the Kafka Schema Registry
プロジェクト概要
YANGデータセット（テレメトリー、設定、制御データなど）の起源と整合性を保証する署名（Provenance Signature） を提供することを目的としています。
主な達成事項
-
署名ライブラリの強化
- 最新ドラフトに合わせて署名ライブラリを更新
- YANGスキーマを用いた署名手順の管理を強化
-
Kafka Schema Registryとの統合
- 署名と検証の手順が完全にスキーマベースであることを実証
- ストリーミングデータの整合性検証の自動化
なぜ重要なのか？
ネットワークテレメトリーデータは以下の理由から、デジタル署名による保護が重要なのです：
- 改ざん検知: データの完全性を保証
- 起源の追跡: どのデバイスからのデータかを確実に特定
- コンプライアンス: 監査要件への対応
特に、多数のデバイスからデータを収集するストリーミング環境では、スキーマベースの自動検証が効率的です。
1.3 Validate Network Telemetry Messages Implementations
プロジェクト概要
NetGauzeおよびPmacctによるネットワークテレメトリーメッセージの実装を、YANGスキーマに対して検証することを目的としました。対象ドラフトは draft-ietf-nmop-message-broker-telemetry-message です。
検証結果
Pmacctの課題
-
I-JSON要件の不適合
-
anydataの値がI-JSONの要件（RFC 7951のセクション5.5）を満たしていない -
yanglintでの検証が失敗（数値型ではなくオブジェクト/JSON名が期待される）
-
-
タイムスタンプフォーマットの問題
-
collection-timestampの値がtypedef date-and-time（RFC 9557準拠）に準拠していない - Pmacct側での修正が必要
-
-
名前空間の問題
-
encoding値にietf-subscribed-notificationsの名前空間を含める必要がある
-
NetGauzeの状況
- IETF 123ハッカソンですでにテレメトリーメッセージの実装を完了
-
LibyangがRFC 8791のYANGデータ構造をサポートしていることを確認
実装者への教訓
YANGスキーマに対する検証は、相互運用性を確保するために不可欠です。特に：
- RFC準拠の厳密な実装が重要
- 早期の検証ツール（
yanglintなど）の活用 - 複数実装での相互運用性テスト
関連リンク
1.4 Knowledge Graphs For Network Operations
プロジェクト概要
IETFの既存の成果物、具体的にはSIMAPモデルとNORIA-Oインシデントモデルを融合させた、初期の概念実証（PoC）となるナレッジグラフを作成しました。
主な達成事項
-
SIMAP内の関係情報クエリ
- ネットワークトポロジー情報を知識グラフとして表現
- 複雑なクエリの実行が可能に
-
OSS/BSSとIETFデータのリンク
- トラブルチケットデータとネットワークリソースの関連付け
- ネットワークリソースの所有者を特定するユースケースを実証
ナレッジグラフのメリット
ネットワークオペレーションにおけるナレッジグラフの活用には、以下のメリットがあります：
- 関係性の可視化: 複雑なネットワーク要素間の関係を直感的に理解
- 迅速なトラブルシューティング: 影響範囲の特定が容易
- 知識の統合: 異なるシステムの情報を統合的に扱える
今後の展望
IETFの既存の作業をオントロジーに迅速に統合し、新しい知識で拡張する方法を示すことで、ネットワーク運用の効率化に貢献します。
関連リンク
1.5 Secure Hybrid Network Monitoring
プロジェクト概要
ハイブリッド/混合クラウド環境に展開されたハイブリッドネットワークの特性を、セキュリティの側面から監視するシステムを構築しました。
監視対象の特性
- 地理的位置
- オペレーター情報
- リンク品質
- トンネル特性
実装内容
PCS（Path Characteristics Service）の核となる機能を実装：
-
テレメトリー情報の取得
- パス上のノードからリアルタイムで情報を収集
-
2つのユースケース
- 突発的なパス変更の監視: 予期しないルート変更を検出し、アラート通知
- 計画されたパスの事前評価: 新しいパスの特性を事前に評価
なぜ重要なのか？
ハイブリッドクラウド環境では：
- 複数のクラウドプロバイダーを跨ぐ通信が発生
- セキュリティポリシーの一貫性が重要
- パス変更による意図しないセキュリティ境界の越境を防ぐ必要
このシステムにより、動的に変化するネットワーク環境でもセキュリティ要件を継続的に満たすことができます。
関連ドラフト
このプロジェクトは、以下の2つのInternet-Draftsに基づいています：
-
Secure hybrid network monitoring - Problem statement
- ハイブリッドネットワーク監視における問題提起と要件を定義
- draft-oiwa-secure-hybrid-network
-
Secure Hybrid Network Monitoring - Path Characteristics Service
- PCS（Path Characteristics Service）の具体的な仕様とプロトコル
- パス上のノードからテレメトリー情報を取得する機能を定義
- draft-oiwa-path-characteristics-service
今回のハッカソンでは、これらのドラフトに基づいて、PCSのコア機能である「パス上のノードからのテレメトリー情報取得」を実装し、2つのユースケースで動作を確認しました。
2. ルーティングとトランスポート
2.1 SRv6 SFC Architecture with SR-aware Functions
プロジェクト概要
コントローラを使用してSRv6 SFC（Service Function Chaining） を包括的に管理することを目的としました。
主な達成事項
-
Pola PCEの機能拡張
- SRv6 uSIDルーズソースルーティングパス計算機能を追加
- SRv6対応ネットワーク機能をウェイポイントとして指定可能に
-
GoBGP v4の更新
- BGP-LS Service Segment API を実装
-
M-Planeコンポーネントの実装
- ネットワーク機能のデプロイを自動化
- SRv6 End.ANの設定を完了
SRv6 SFCの利点
SRv6ベースのService Function Chainingには以下の利点があります：
- 柔軟性: ネットワーク機能を動的に組み合わせ可能
- スケーラビリティ: 状態を保持しないステートレスな実装
- IPv6ネイティブ: IPv6との親和性が高い
技術的な詳細
**uSID（Micro Segment ID）**を活用することで：
- SRv6ヘッダーのオーバーヘッドを削減
- より多くのセグメントを1つのパケットに含められる
- ネットワーク機能のチェーン構成が柔軟に
関連リンク
2.2 SIMAP Hackathon
プロジェクト概要
ネットワーク内の情報モデルであるSIMAPの作業を継続しました。
主な達成事項
-
MicroSIDsのサポート
- ラボ環境にMicroSIDsのサポートを追加
- より効率的なSRv6の実装が可能に
-
リンク制御メカニズム
- リンクの有効化/無効化メカニズムを実装
- 動的なトポロジー変更に対応
-
パス計算アルゴリズム
- SRv6 Policyに基づいてパケットの物理パスを計算するアルゴリズムを開発
発見された課題
RFC 8345（IETFトポロジーモデル）を使用してパスのモデリングを開始しましたが、以下の点で拡張が必要であることが判明：
- 複数の候補パスのモデル化
- 異なる重み/優先度を持つセグメントリストの表現
SIMAPの重要性
SIMAPは以下を実現するために重要です：
- ネットワーク全体の統一的な情報モデル
- 異なるベンダー機器間の相互運用性
- 自動化とオーケストレーションの基盤
2.3 KIRA (Scalable Zero-touch Routing Protocol)
プロジェクト概要
スケーラブルなゼロタッチルーティングプロトコルKIRAのRust実装に取り組みました。
主な達成事項
-
より完全な隣接関係の実現
- vicinity（近隣関係）の実装を改善
- より多くのトポロジーでフォワーディングが機能
-
PathCollectionの初実装
- パス情報の収集機能を実装
- ルーティング決定の基盤を構築
発見された課題
大規模トポロジーでのテスト時の問題：
- NeST（Network Stack Tester）などのツールでテスト時
- ノードがタイムリーに応答せず、タイムアウトが発生
- 原因: 単一のマシンで多数のノードを実行したため
- 結論: 実装上の問題ではなく、テスト環境の制約
KIRAの特徴
- ゼロタッチ: 手動設定なしで自動的にルーティングを確立
- スケーラブル: 大規模ネットワークに対応
- Rust実装: メモリ安全性とパフォーマンスを両立
関連リンク
2.4 ILNP (Identifier Locator Network Protocol)
プロジェクト概要
Identifier Locator Network Protocol (ILNP) の作業を継続しました。FreeBSD 14上での実装とテストが行われています。
主な達成事項
-
動的ホストマルチホーミング
- TCPおよびUDPのマルチパスサポート
- TCP CUBICによるマルチパスの動的なパス変更をテスト
-
DASHストリーミングのテスト
- 標準のnginxバイナリとFirefoxバイナリを使用
- DASH streaming over TCP（マルチパス対応）の動作確認
- パフォーマンスの向上を確認
ILNPとは？
ILNPは以下の特徴を持つプロトコルです：
- 識別子とロケータの分離: ホストのアイデンティティと位置情報を分離
- モビリティサポート: シームレスなハンドオーバーが可能
- マルチホーミング: 複数のネットワークパスを同時利用
実用的なメリット
DASHストリーミングでの検証により、以下が実証されました：
- 帯域幅の有効活用: 複数のパスを使った並列転送
- 耐障害性の向上: 1つのパスが失敗しても通信継続
- QoSの改善: 動的なパス選択によるパフォーマンス最適化
関連リンク
2.5 L4S & AccECN Interop Event
プロジェクト概要
L4S（Low Latency, Low Loss, Scalable throughput） 輻輳制御アーキテクチャの相互運用性、TCP AccECN、およびRFC 8888の相互運用性のテストを実施しました。
主な達成事項
-
Chrome CanaryへのL4Sサポート追加
- libwebrtcにL4Sサポートを統合
- 受信側でのRFC 8888フィードバックの送信機能
- 送信側でのL4S輻輳制御（SCReAMモジュールを使用）
-
プロダクション環境でのテスト
- NetflixおよびNVIDIAのプロダクションクラウドゲーミングサーバーとの接続テスト
- Chrome Canaryを使用した実際のユースケースでの検証
L4Sの重要性
L4Sは以下を実現します：
- 超低遅延: リアルタイムアプリケーション向け
- 高スループット: 帯域幅を無駄にしない
- 既存ネットワークとの共存: Classic ECN/Reno TCPとの共存が可能
WebRTCでの意義
WebRTC（ビデオ会議、クラウドゲーミング等）においてL4Sは：
- レイテンシの削減: より自然な会話体験
- ジッターの低減: 安定したビデオ品質
- 帯域幅の効率化: 限られた帯域での品質向上
2.6 Testing Congestion Control and Queue Management Mechanisms
プロジェクト概要
ns-3、NeST、およびL4S対応のWiFi AP（QQ-IW-235）を使用して、FQ-CoDelとFQ-PIEのテストを実施しました。
主な達成事項
-
NeSTベースのAQM評価スイート
- RFC 7928に準拠した評価スイートを完成
- 標準化されたテストケースの実装
-
輻輳制御評価スイートの設計
- RFC 9743に準拠した評価スイートの設計を開始
- より包括的なテストフレームワークの構築
AQM（Active Queue Management）とは？
AQMは以下を実現するキューイング技術です：
- バッファブロートの防止: 過度なキューイング遅延を抑制
- 公平性の確保: 複数のフローが公平に帯域を利用
- レイテンシの低減: 遅延重視のアプリケーションの性能向上
FQ-CoDelとFQ-PIEの比較
両者ともフローキューイングとAQMを組み合わせていますが：
FQ-CoDel:
- Controlled Delayアルゴリズムを使用
- キュー遅延に基づいてドロップを決定
FQ-PIE:
- Proportional Integral controller Enhancedを使用
- キュー長とドロップ確率を調整
関連リンク
まとめ
IETF 124 Hackathon Part 1では、ネットワーク管理とルーティング技術の最新動向を紹介しました。
主なトレンド
-
AI/LLMの活用
- MCPによる自然言語ネットワーク管理
- インテント駆動型の運用自動化
-
SRv6の進化
- Service Function Chainingへの応用
- MicroSIDsによる効率化
-
低遅延技術
- L4Sの実用化
- マルチパスルーティングの進展
-
相互運用性の重視
- YANGスキーマによる検証
- 複数実装間でのテスト
次回予告
Part 2: セキュリティ・PQC・暗号編では、以下のトピックを紹介します：
- PQ in X.509（耐量子暗号の相互運用性）
- TEEP/VERAISONによるセキュアプロビジョニング
- COSE PQC
- その他セキュリティプロジェクト
お楽しみに！と言ってもすぐに投稿する予定です！
参考リンク
最後に、GMOコネクトでは研究開発や国際標準化に関する支援や技術検証をはじめ、幅広い支援を行っておりますので、何かありましたらお気軽にお問合せください。
一緒に働きたい人も気軽にコンタクトを取ってください！