HPE Juniper Routing Directorで実現するMPLSトランスポートの可視化と自動化

背景と目的

まず背景として、なぜ通信事業者がコントローラを必要とする状況になりつつあるのかの理由について調査した内容を最初に説明します。

近年、通信事業者ネットワークは以下のように 高度化・複雑化が加速しており、従来のCLIを中心とした運用では限界が見え始めています。

5G導入と極端な要件の多様化

5Gでは高速化に加え、超低遅延・高信頼性を前提としたサービス（自動運転、IoT、大規模AR/VRなど）が増加しています。これに伴い、アプリケーション単位でネットワークリソースを動的に割り当てるスライシングが必要となっています。

マルチベンダ・物理＋仮想＋クラウドの混在

通信事業者ネットワークでは依然として物理装置が主流ですが、仮想アプライアンスやクラウド基盤も拡大しています。その結果、異なる管理方式・技術が混在する環境を統合管理する必要性が高まっています。

運用コスト削減（OPEX）とゼロタッチ化

通信事業者は全国規模の拠点（基地局・POP・DC）を抱えており、手作業による設定変更や障害対応では既にスケールしない段階に来ています。自動化・ゼロタッチ運用が不可欠になりつつあります。

こうした課題に対し、通信事業者向けコントローラは次のような価値を提供することが求められます。

ネットワークサービスのエンドツーエンドでのオーケストレーション

無線（RAN）、トランスポート（IP/MPLS・光伝送）、5G網など、一部から全ての領域までを横断して サービスとして扱い、設計〜構築〜運用〜最適化までを一元管理できます。

動的なリソース制御と自動化

ネットワーク状態をリアルタイムで収集・分析し、以下の自律的な制御（クローズドループ） を実現できます。

• 輻輳 → 経路変更
• 遅延増加 → スライス再構成
• 障害発生 → 自動復旧

マルチベンダ環境の抽象化

コントローラが物理装置を抽象化し、異なるベンダ装置を統一されたAPIで扱うことが可能になります。これによりマルチベンダ環境での運用効率が飛躍的に向上します。

通信事業者向けネットワークコントローラとは何か？

前述のように通信事業者のコントローラに求められる要件には、主要なフレームワークが存在しており、その代表例としてTM Forumが策定する自律化レベル（Autonomous Level：AN Level）があります。この枠組みに照らすことで、ベンダ製品がどのレベルに該当し得るのかを整理できます。

TM Forumは、通信・IT企業800〜850社超が参加する国際的な非営利団体で、業界横断の協調によりネットワーク運用・デジタルサービスの標準化を進めています。
主にOpen Digital ArchitectureやOpen API、自律型運用（Autonomous Networks）などの共通基盤づくりを主導しています

下図のように自律化レベルはレベル0からレベル5まで規定されており、実行、認識、分析/判断、Intent/経験の各側面で手動から自律へと段階的に進化していきます。

図1.

引用：
https://www.netone.co.jp/media/detail/20240603-01/

TM Forumの資料に関しては、下記URLにあります。しかしながら、各資料が分散して配置されているため、必要な情報を収集するにはある程度の検索が必要です。

一例ではありますが、AN Level 4に関するブループリントを下記に示します。無料登録することで、一部の資料に関してはダウンロードが可能です。

Autonomous networks: Level 4 industry blueprint
https://inform.tmforum.org/research-and-analysis/reports/autonomous-networks-level-4-industry-blueprint

私見ではあるもののRDは、AN Level 4の要素技術（Intent-based control、Closed-loop automation、Active Assurance等）を部分的に備えているが、TMFが定義するAN Level 4を単体で満たすものではないと考えています。
また、JuniperのWebサイトのドキュメントでは “closed-loop automation” の記載はあるものの、TM Forum Autonomous Levelsへの公式な位置づけの明記までは確認できませんでした。

https://www.juniper.net/us/en/products/network-automation/routing-director.html

記載個所を下記に抜粋しています（Key Featuresの1つ）。
Deliver reliable and differentiated performance with closed-loop automation

RDが関連すると想定するAN Level 4の内容の一部として、下記4点を挙げました。

1. インテントベース・ネットワーキング

AN Level 4では、インテント(意図)を入力とし、コントローラがポリシー化・変換し、最適な構成を自動生成・維持することが求められます。
RDは、意図をGUI経由で設定することで、自動生成された設定が装置へと流し込まれることになります。さらにパスプロビジョニングでは、低遅延・高可用性・SLA要件などを意図として与えることで、最適なSR-TEパスの計算や自動設定を行える点を備えています。
例えば、低遅延を満たすための特定経路に対してSR-TEトンネルを自動生成するといった処理が実現できます。

2. AIネイティブなクローズドループ

AN Level 4の中核は、予測的なクローズドループによる制御です。
RDは、AI/ML機能や外部AIOps基盤と連携することで、異常兆候の認識・ルートの再最適化などのクローズドループを実現できます。
AN Level 4が求める「人手介入なしの自律制御」には、RD単体だけなく、外部システムとの組み合わせで到達することが現実的な解になると考えられます。
例えば、ネットワーク内のトラフィックが増加し、動的な帯域制御を行うためにRD経由で外部APIサーバ向けに設定変更要求及び実行といった処理が実現できます。　

3. AIOps機能

RDにはLLMコネクタを利用したAIOps機能が備わっており、オペレータは自然言語によってネットワーク状態や発生中の事象について直接問い合わせることが可能です。この機能はRD単体の処理ではなく、外部のLLMサービス（必要に応じて検索基盤やRAG構成と組み合わせたAIOps基盤）との連携を前提としたアーキテクチャで構成されています。これにより、広範なドキュメント・運用ナレッジを参照しながら、根本原因分析（RCA: Root Cause Analysis）や推奨対処案の提示を迅速に実施できます。
例えば、トラブルシューティング時に対話型チャット形式で出力のアラートに対する質問を行い、回答を得るといった処理が実現できます。

4. アクティブアシュアランス

AN Level 4の要件では、継続的測定と自律最適化があります。
RD内の一機能となっているアクティブアシュアランスを利用し、下記のDay 0〜Day 2の継続測定・SLA監視を行い、自律的最適化につなげることが可能です。
Day 0：サービス設計時の検証
Day 1：導入時の性能保証
Day 2：運用中の継続テスト・SLA検証
例えば、全国の経路遅延を継続測定し、ユーザ体感性能をリアルタイムで評価するといった処理が実現できます。

上記はあくまでも一例でしかなく、通信事業者の要件はさらに多岐にわたり、AN Level 4を実現するためには、1つのベンダの製品や機能で完結するものではないと考えます。

Juniper Routing Directorの概要

※本記事に記載している機能や検証結果は、Juniper Routing Director バージョン 2.6.0の環境に基づきます。

アーキテクチャ

RDの技術基盤は、Kubernetes（K8s）クラスタ上で動作するマイクロサービス群で構成されています。従来のモノリシックなソフトウェア構造ではなく、機能を疎結合なマイクロサービスとして実装することで、特定機能に対する負荷分散（スケーラビリティ）や耐障害性（可用性）を高めた設計となっています。

デプロイメントと管理

一般的にK8s環境の構築・管理は複雑になりがちですが、RDはOVFファイルとしてパッケージ提供されており、VMware ESXiやKVMなどのオンプレミス仮想化基盤へ容易にデプロイできます。
また、運用面ではクラスタ管理や初期設定、日々のメンテナンス作業において、JunosライクなカスタムCLI（Paragon Shell / cMGD）が提供されます。これにより、LinuxやK8sの深い専門知識を持たないネットワークエンジニアでも、使い慣れたJunosのコマンド体系でスムーズに導入・運用できるよう設計されています。

主要機能

RDは、ネットワークのライフサイクル（設計・構築・運用・保証）全体をカバーするために、多岐にわたる機能を統合したプラットフォームです。大きくは以下の機能を有します。

Device Management（装置管理）

ゼロタッチプロビジョニング（ZTP）により、新規導入デバイスの自動オンボーディングと初期設定を行います。デバイスのインベントリ管理、ソフトウェア（OS）の一括アップグレード、設定バックアップといった基本的なデバイスライフサイクル管理機能を提供します。

Observability（可視化・監視）

BGP-LS（BGP Link-State）などで収集した情報に基づき、ネットワークトポロジをリアルタイムで可視化します。Telemetryストリーミングを活用し、インターフェース状態、デバイスの健全性、ルーティング情報などを詳細に監視します。Health Dashboardにより、デバイスやネットワーク全体の健全性を直感的に把握し、根本原因分析（RCA）やトラブルシューティングを支援します。

Network Optimization（パス最適化・制御）

PCEP（Path Computation Element Protocol）を用いて、SR-TE（Segment Routing Traffic Engineering）や MPLS LSP（Label Switched Path）のパスを集中制御します。帯域、遅延、コストなどの制約条件に基づいて最適な LSP パスを自動計算し、ネットワークへ適用します。
メンテナンス時のトラフィック迂回経路を事前に計算・確保することで、実作業の影響を最小化する制御が可能です。

Service Orchestration（サービスプロビジョニング）

L3VPN、EVPN、L2 サーキット（E-LINE、E-LAN）など多様なVPNサービス設定を、GUIベースのワークフローで自動化します。インテント（意図）ベースのプロビジョニングにより、手動設定に伴うミスを抑制し、サービス提供の迅速化を図ります。

Active Assurance（能動的監視）

ネットワークのデータプレーン上でエンドツーエンドのPing、Jitter、パケットロス等のテストトラフィックを生成し、実際のサービス品質（SLA）を継続的に測定・検証します。
測定結果に基づき、ユーザ体感品質（QoE）をリアルタイムに可視化し、潜在的な問題をユーザ申告前に検知します。

Trust & Compliance（信頼性とコンプライアンス）

ネットワークデバイスのハードウェア／ソフトウェアのEoL（End of Life）情報を管理し、ライフサイクル管理を支援します。既知の脆弱性（PSIRT）情報や不具合通知とデバイス設定を照合し、コンプライアンスチェックを通じてセキュリティリスクを特定します。

Planner（設計・シミュレーション）

オフライン環境でネットワークトポロジの設計・検証を行い、最適なネットワーク構成を検討します。障害シミュレーションやトラフィック需要の変化をモデル化し、ネットワークの振る舞いを予測することで、設計段階でのリスク低減に貢献します。

LLM Connector（生成AIアシスタント連携）

近年のネットワークコントローラのトレンドとして、LLM（大規模言語モデル）を活用した自然言語による対話型の運用支援機能の実装が進んでいます。
RDのLLM Connectorは外部の生成 AI モデルと連携し、RAG（検索拡張生成）技術を用いて Juniper の膨大な製品ドキュメントと、RDが収集したリアルタイムのネットワーク状態（アラートやログ）を組み合わせて分析します。
これにより、オペレータはチャット形式でトラブルシューティングの助言や設定手順のサポートを受けられ、専門知識を補完しながら迅速な障害対応や運用業務の高度化を実現できます。

RDで理解するSR-TE・BGP‑LS・PCEPの仕組み

今回の検証を通して特に印象的だったのは、SR-TEの可視化ができるObservabilityに加え、LSPをGUI上からプロビジョニングできる点です。
従来はCLIのshowコマンドで確認していたLSP情報をGUIで直感的に把握でき、さらにGUIからLSPの追加／変更／削除まで行える点は、非常に便利です。しかし同時に、「GUIで設定した内容はどのようにルータへ反映されているのか？」という疑問も生じました。

RDのマニュアルを確認しても、この内部動作については深く解説されている内容は見当たりませんでした。調査の中でBGP‑LSとPCEPがキーワードであることが分かり、RDがSR-TEを制御できる仕組みを把握する上でこれらの役割が重要と理解しました。
今回の検証では、RD ver2.6.0/2.5.0を利用し、以下の構成でSR-TEの動作を確認しました。

• サービス: L3VPN（VPNv4）
• IGP: OSPF
• トランスポート: SR-MPLS
• RDとルータ間: BGP‑LS及びPCEPを使用
• RDが自動でSR-TE LSPを生成
• 対象経路に対し、BGP Color Extended Communityを付与することで、SR-TEを実現
  • BGP Color Extended Communityとは、特定の数値タグ（Color値）をBGP経路に付与する拡張communityです。このColor値を用いて経路とトランスポート（SR-TEなど）を紐づけることができます。結果として、BGP経路で要求されるサービス特性に適したSR-TEが選択・利用され、サービス単位でのトラフィックエンジニアリングを実現できます。

RDのパスプロビジョニングの裏側の仕組みに関しては、公開されていない情報もあるようなので、一般的な内容を前提として、以下にRDがSR-TE を制御する仕組みについて整理したものを解説します。

RDがSR-TEを制御する仕組み

RDはネットワーク全体を見渡す「集中制御の頭脳」として動作し、BGP‑LSとPCEPを利用してSR-TEを管理します。
RDのSR-TE制御は、以下の4つの技術要素で構成されます。

1. トポロジ収集 (BGP‑LSによるネットワーク可視化)

SR-TEのパス計算を行うためには、RDがネットワーク全体のトポロジを完全に把握している必要があります。
このトポロジ情報をRDに伝える仕組みがBGP‑LSです。
ルータはIGP（ISIS/OSPF）のLSDBをBGP‑LSのアドレスファミリーを使ってRDに送信します。
これによりRDは以下の情報を取得します。

• リンク状態／TE属性（帯域、TE metric、遅延など）
• ノード／リンク／プレフィックス情報（トポロジ再構成に必要な識別子一式）
• SR関連：Prefix‑SID（Node‑SIDを含む）/Adjacency‑SID、SRGB/SRLBなどのセグメント情報

※補足：
RDの設定では、トポロジ収集/最適化ユースケースにおいてルータはRDへBGP-LSで接続することが必要となります。
RDはこれらを基にTraffic Engineering Database（TED）を構築し、SR-TEのパス計算に利用します。

2. パス計算と制御 (PCEPによる動的LSP制御)

RDはPCE（Path Computation Element）として動作し、ルータは PCC（Path Computation Client）としてPCEPセッションをRDと確立します。
PCEの役割：

• TED構築
  • BGP‑LSで収集したトポロジ／TE 情報からTEDを生成し、最適経路を計算。
• PCEPセッションの確立／維持
  • PCCとPCEP を張り、LSP状態同期・制御を実施。
• Stateful PCEによるLSP制御
  • PCCが既存LSPの制御権をPCEに委譲すると、RDは当該LSPのパス更新等の指示が可能。
  • Stateful PCEにより、SR-TEのHeadEndルータは従来のように自前でパス計算を行う必要がなくなり、それらをRD側にオフロードできます。
• LSPの生成
  • 必要に応じて、RDから新規LSPをPCC上に生成/削除。
• トポロジ変化時の再計算
  • TEDの更新に応じて再計算、ポリシーに従い、経路を更新（自動化の範囲は State/Policy に依存）。

RDクラスタとVIP：
RDはK8sベースのクラスタ構成を取り、PCEPの接続先としてVIP（Virtual IP）を提供します。ルータはVIPに接続するため、クラスタ内のフェイルオーバが発生しても同一VIPで制御が維持されます。

3. インテントベースの最適化

RDは、意図と制約を入力すると、それに基づいて最適なパス（SR-TEなどのLSP）を計算・配備できます。
指定可能な代表的インテントの例として、下記が挙げられます。

• 遅延最小
  • 遅延などのメトリクス重視で最適化を実施。
• 特定ノード／リンクの回避
  • 回避制約（アフィニティ等）を設定して経路から除外。
• アプリ/サービス別最適化
  • 意図ベースのパス生成を行い、カラー等でトラフィックをマッピング。

4. 自動再計算

RDは、BGP‑LSで得たトポロジ/TE情報の変化や最適化ポリシーが参照するテレメトリ指標をトリガに、TEDを更新してパスを再計算できます。
代表的な再計算トリガは次のとおりです。

• 遅延の悪化
  • 遅延メトリクスを参照する最適化プロファイル/Path Intentを設定している場合、しきい値逸脱を契機に再最適化を実行可能
• リンク障害/ノードダウン
  • IGP由来のイベントがBGP‑LSでRDに通知され、TED更新→再計算を実施。
  • 再計算結果はPCEP経由でLSPへ即時反映され、最適なSR-TEパスが常に維持されます。

RDを用いたSR-TEが確立するまでのPCEPとBGP-LSの関係をまとめますと、下図となります。ここでは、コントローラはRDを指します。

図2.

参考：設定フローと詳細ドキュメント
Dynamic Topology Workflow
https://www.juniper.net/documentation/us/en/software/juniper-routing-director2.7.0/user-guide/topics/task/dynamic-topology-workflow.html

Add a Tunnel
https://www.juniper.net/documentation/us/en/software/juniper-routing-director2.7.0/user-guide/topics/task/add-tunnel.html

Optimize your Network with Routing Director
https://community.juniper.net/blogs/masagung-nugroho/2025/09/25/optimize-your-network-with-routing-director

RDの外部連携について

RDはポータル上の各機能がAPIとして提供されるAPI-first の設計であり、GUIで実施できる操作はAPI経由でも実行可能です。
そのため、運用自動化や外部システム連携（OSS/BSS 連携など）を前提に、RDの機能を“部品化”して組み込める点が特徴です。

Webhookを使用したイベント駆動向けの機能

RDでは、アラートやイベントをトリガとして外部システムへ通知できる仕組み（Webhook）を利用できます。
これにより、イベント発生を起点にチケット起票・通知・自動復旧ワークフローの起動など、外部の運用基盤と連携したイベント駆動型の運用を組み立てやすくなります。

TSDBのデータ取得について

RDは装置から収集したTelemetryなどを蓄積し、時系列データとして参照できる形で保持します。外部からはAPIでデータを取得できるため、定期的に値を取得してダッシュボードへ取り込む、閾値判定して運用処理へつなげる、といった使い方が可能です。

図3.

APIを使用したサービスインスタンスの作成及び変更例

前述のとおり、RDの各種機能はAPI経由で外部システムから操作可能です。
本稿ではその一例として、サービスオーケストレーション機能におけるサービスインスタンスの作成／変更をAPI経由で実行するケースを示します。
RDのサービスオーケストレーション機能では、「サービスモデル（テンプレート）」と「顧客情報（パラメータ）」を紐づけ、設定生成から監視開始までの一連の処理をワークフローとして実行します。
外部システムからREST APIを介して当該ワークフローの実行要求を行うことで、サービス開通（プロビジョニング）処理の自動化が可能となります
外部システムからのリクエスト例
具体的には、以下のようなJSON形式のパラメータを送信することで、サービスインスタンスの作成や変更をリクエストできます。

図4.

更新時の挙動に関する注意点:
RDのサービスインスタンス更新では、変更内容を含むサービス定義をもとに、サービスプロビジョニングのワークフローが再実行されます。
そのため、部分的な設定変更であっても、更新時には以下の手順を踏み更新を行う必要があります。
① 現在のサービス定義をGET APIで取得
② 取得した定義を編集（変更したい値のみ修正）
③ 編集後のサービス定義（全パラメータ）で更新リクエストを実行

留意点
ドキュメントだけではTSDBのフィールド名などを追い切れない場合があります。実運用で必要な項目を確実に把握するには、GUI操作時に呼び出されるAPIのリクエスト内容を確認しながら、利用するフィールドを特定していくアプローチが現実的です。

参考
RoutingDirector ユーザガイド：https://www.juniper.net/documentation/us/en/software/juniper-routing-director2.6.0/user-guide/index.html

まとめ

RDに関する案件検証や製品・技術調査を通じて、通信事業者が目指すAN Level 4の一端を体感することができました。RDが備える自動化・最適化機能は、AN Level 4に近づくための重要な要素を含んでおり、将来の自律型ネットワークの方向性を理解する上で大きな示唆を得られました。
一方で、現状の機能はAIを活用した高度な仕組みを持ち始めているものの、完全な自律制御を実現するにはAPIサーバなどの外部システムとの連携が必須であり、単体ではまだ発展途上であることも確認できました。
今回の検証を通じて、完全なAN Level 4やその先のLevel 5を実現するにはまだ多くの進化が必要である一方、現在の技術が確実に前進していることも実感できました。今後の機能拡張や実装の進化に期待しつつ、引き続き動向を追っていきたいと思います。

※本記事は同じチームの佐藤との共著となります。
東日本第2事業本部
サービスプロバイダー事業戦略部 第2チーム
佐藤　剛士

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。