SR-TE · PCEP · BGP-LS · EPE

オープンルーター向けの SR-TE コントローラー。

ルーターは自らの位置から最適な経路を選択し、伝送するトラフィックのほぼすべてにとって、それが正しい答えです。ただし、次の 3 つの判断にはネットワーク全体の視点が必要です。経路に沿った帯域の予約、2 つのサービスが同じリンクを共有しないようにすること、そしてサービスがどのピアリングから出ていくかの選択です。Vegvísir Systems の Traffic Dictator は、これらをライブトポロジーに基づいて計算し、OcNOS を搭載した IP Infusion のオープンルーターに経路をインストールします。

動作を見る アプリケーションノートを入手
2オープンプロトコル（双方向）
2ポリシーの配信方式
10共同ラボで検証した機能
トラフィックエンジニアリングの目的

ルーター単体で実現できること、コントローラーが加えるもの。

OcNOS ルーターは、ECMP、TI-LFA によるローカル保護、IGP 内に構築する Flex-Algo プレーンにより、単体で多くの機能を実現します。コントローラーが加えるのは、ネットワーク全体の視点を必要とする判断のみです。 各カードのタグは、どちら側がその機能を提供するかを示します。

1 つの障害が次の障害を招くのを防ぐ

TI-LFA はローカルの修復経路を事前に計算するため、ルーターはネットワークの再収束を待たずに切り替えます。コントローラーは迂回トラフィックを空き容量のあるリンクへ分散させ、最初の障害が 2 つ目の障害を引き起こさないようにします。

OcNOS + コントローラー

遅延に敏感なトラフィックを短い経路に載せる

Flex-Algo は IGP 内に低遅延プレーンを構築します。トレーディング、メディア、モバイルフロントホールのトラフィックはこのプレーンに従い、それ以外のトラフィックは引き続き最小コストの経路を使用します。

OcNOS 単体

販売したサービス向けに帯域を予約

ポリシーは帯域値を保持します。コントローラーは経路をインストールする前に空き容量を確認し、リンクがすでに埋まっている場合はポリシーのインストールを保留します。

OcNOS + コントローラー

費用を払っているリンクを活用

等コストリンクはすでに ECMP で使用されています。コントローラーは不等コストのリンクにサービスを配置し、遊休容量を販売可能な容量に変えます。

OcNOS + コントローラー

バックアップ経路をプライマリ経路のリンクから分離

非重複グループによって分離をポリシーの一部とするため、保護経路が保護対象の経路とリンクを共有することはありません。

OcNOS + コントローラー
エンドツーエンドの仕組み

入力した制約が、ルーターの付与するラベルになるまで。

この設計で両者の間をやり取りするプロトコルは 2 つだけで、どちらも標準規格であるため、 どちらの側も単独で置き換え可能.

本ページで使用する 2 つの用語

セグメントリスト は、ラベルを順序付けて並べたもの。各ラベルはルーターまたはピアリングを示し、ヘッドエンドルーターがこれらをパケットに付与することで、パケットはその順序で各地点を経由します。 ポリシー は、ヘッドエンド、エンドポイント、およびその間のリストを決める制約の組み合わせ。

セグメントルーティングトラフィックエンジニアリングのコントロールプレーン：4 台の OcNOS ルーターが IS-IS セグメントルーティングドメインを構成し、そのうち 1 台がリンクステートトポロジーを BGP-LS で Vegvísir Traffic Dictator コントローラーへエクスポート。コントローラーは計算した SR-TE ポリシーを PCEP でヘッドエンドルーターにインストールし、境界では外部の自律システムがピアリングして BGP Peer SID として表現されます。
両者の接点：OcNOS はセグメントルーティング対応の IS-IS を実行してトポロジーを BGP-LS で公開し、Traffic Dictator は設定された制約の下で経路を計算して PCEP でインストールします。
IP Infusion OcNOS データプレーンとコントロールプレーン

IP Infusion がハードウェアと OcNOS を統合・検証・サポートする完全なルーターとして提供されるため、ハードウェアとソフトウェアの責任は 1 社のベンダーに集約されます。

  • ネットワークを動かす。 セグメントルーティング拡張付きの IS-IS により、ラベル、ECMP、TI-LFA 高速リルートはすべてルーター自身で動作。
  • ヘッドエンドとして機能。 受け取ったポリシーをインストールしてセグメントリストを付与し、運用状態を報告。
  • 出口にラベルを付与。 外部ピアリングごとに BGP Peer SID を割り当て、コントローラーがそのピアリングをセグメントリスト内で指定可能に。
Vegvísir Systems Traffic Dictator コントロールプレーンのみ

Docker コンテナとして提供され、サーバー上、既存の仮想化環境、またはコンテナをホスト可能なルーター上で動作。自動化向けに HTTP API を備えます。

  • グラフを構築。 Node、Link、Prefix の情報を BGP-LS で受信し、セグメント ID を付加したライブトポロジーを生成。
  • 制約を保持。 明示ホップ、リンクアフィニティ、帯域、非重複グループ、出口ピアを、すべてポリシーの制約として表現。
  • 計算してインストール。 セグメントリストを算出してヘッドエンドへ送り、トポロジーが変化すると更新。
帯域台帳の置き場所

OcNOS は Flex-Algo などの IGP メカニズムを用いて分散型のトラフィックステアリングを実行し、外部の PCE またはコントローラーはネットワーク全体の制約を用いて明示的な SR ポリシーを計算します。 帯域は、単一の視点を必要とする制約です： セグメントルーティングは予約をホップごとにシグナリングしないことで拡張性を得ているため、各ポリシーが確保した帯域の累計は中央で保持します。この値はポリシーごとに設定するもので、現時点では計測トラフィックに応じて自動調整されません。 RSVP-TE は別の方式を採り、各ホップで予約をシグナリングします。

導入から運用までの流れ

セグメントルーティングの有効化から、ネットワークでポリシーが稼働するまでの 4 ステップ。

最初の 2 つはルーター上での一度きりの設定。 残りの 2 つは、ポリシーを作成するたびに繰り返す作業。

01

セグメントルーティングを有効化

すべてのルーターで IS-IS がセグメントルーティング拡張とトラフィックエンジニアリング拡張を伝送するため、リンク帯域と admin group も広告されます。ラベルはセグメントルーティング自体から割り当てられます。

02

トポロジーをコントローラーへエクスポート

1 台のルーターがリンクステートデータベースを BGP-LS に再配布し（ distribute bgp-ls ）、コントローラーとピアを確立します。

03

ポリシーと制約を定義

ポリシーは、ヘッドエンド、エンドポイント、満たすべき制約を指定します。コントローラーはライブトポロジーに基づいて経路を計算し、 セグメントリストを返します。これは、ヘッドエンドがパケットに付与するラベルのリストです。

04

インストールし、最新状態を維持

コントローラーは PCEP でポリシーを送信し、ヘッドエンドはそのポリシーが稼働して転送に使用されていることを報告します。後でトポロジーが変化した場合も、同じポリシーを再構築せずにその場で更新します。

制約ごとの動作

各制約によって、コントローラーが返す経路がどう変わるか。

下の制約を選択すると、生成される経路とラベルを表示します。ここに示すセグメントリストとメトリックはすべて、共同ラボで記録された出力です。

図を横にスワイプして経路をたどる

検証済みラボトポロジーの簡略図上で操作する、インタラクティブな制約ピッカー R1 から R4 までの 4 台のルーターと、1 つの外部自律システム。左側の R3 がヘッドエンド。2 つのリンクグループにタグが付与されています。BLUE グループは R3 と R1 間、R1 と R2 間、R3 と R4 間を、YELLOW グループは R3 と R2 間、R2 と R4 間をカバーします。右側では R2 が AS 101 とピアリングしています。制約を選択すると、コントローラーが計算した経路が強調表示され、生成されたセグメントリストが表示されます。同じ内容は図の横にもテキストで記載しています。 admin-group BLUE admin-group YELLOW eBGP ピアリング 40 Gbps 確保 40 Gbps 確保 R3 ヘッドエンド R1 16001 R2 16002 R4 16004 AS 101 25600 宛先 宛先
コントローラーの計算結果

OcNOS がインストールする内容
経路
セグメントリスト
集約メトリック

5 つの制約と、それぞれが返す経路

BLUE リンクのみを通る（リンクアフィニティ制約）
経路：R3 から R4。セグメントリスト 16004。集約メトリック 10、1 ホップ。経路上のすべてのリンクに BLUE タグが必要で、R3 から R4 への直結リンクはこれを満たすため、ノードセグメント 1 つで足ります。ポリシー R3_R4_BLUE, affinity-set BLUE_ONLY.
YELLOW リンクのみを通る（リンクアフィニティ制約）
経路：R3 から R2 を経て R4。セグメントリスト 16002, 16004。集約メトリック 20、2 ホップ。すべてのリンクに YELLOW タグが必要なため、直結リンクは除外され、コントローラーは R2 経由でルーティングします。ネットワーク内のメトリックは一切変更していません。ポリシー R3_R4_YELLOW, affinity-set YELLOW_ONLY.
40 Gbps を予約（帯域制約）
経路：R3 から R2 を経て R4。セグメントリスト 16002, 16004。集約メトリック 20、40 Gbps を確保。同じ経路に帯域を付加したもので、コントローラーはインストール前に両リンクが 40 Gbps を伝送可能か確認し、予約を自身の台帳に記録しました。ポリシー R3_R4_YELLOW, bandwidth 40 gbps.
出口ピアを選択（イグレスピアエンジニアリング）
経路：R3 から R2 を経て AS 101。セグメントリスト 16002, 25600。集約メトリック 10、1 ホップと出口。25600 は R2 が AS 101 とのピアリング用に割り当てた BGP Peer SID であり、セグメントリストの最後で出口を指定します。ポリシー R3_R2_EPE.
その出口へ BLUE リンク経由で（アフィニティとイグレスピアエンジニアリング）
経路：R3 から R1、R2 を経て AS 101。セグメントリスト 16001, 16002, 25600。集約メトリック 20、2 ホップと出口。2 つの制約を同時に適用します。出口は引き続き AS 101 で、そこへの経路は BLUE リンク上にとどまる必要があるため、コントローラーは R1 経由の遠回りの経路を選びます。ポリシー R3_R2_EPE_BLUE, affinity-set BLUE_ONLY.

ここに示すセグメントリスト、メトリック、ポリシー名はすべて、IP Infusion と Vegvísir の共同アプリケーションノートによるものです。いずれも同ノートに、コントローラー上の次のコマンドのライブ出力として掲載されています： show traffic-eng policy <name> detail 。Traffic Dictator の構文は次で公開されています： vegvisir.ie/documentation.

イグレスピアエンジニアリング

イングレスルーターが、パケットの出口となるピアリングを選択。

トラフィックエンジニアリングは通常、自社ネットワークの境界で終わりますが、イグレスピアエンジニアリングはその先の 1 ホップまで対象を広げ、パケットがどのピアリングから出ていくかをイングレスルーターが選択します。トランジットがピアリングより高コストな場合、この選択がコスト削減につながります。

ピアリング障害後の、帯域を考慮したイグレスピアエンジニアリング 4 台のイングレスルーターがそれぞれ 30 Gbps を同じ宛先自律システムへ送信し、100 Gbps のプライベートピアリング 2 本で負荷分散しています。1 本のピアリングに障害が発生します。帯域を考慮しない場合、120 Gbps すべてが残る 100 Gbps のピアリングに流れ込み、輻輳が発生します。帯域制約がある場合、コントローラーは収まる分だけを受け入れ、残りをトランジットアップリンクへ送ります。 イングレスルーター 4 台、各 30 Gbps 120 Gbps 流入 プライベートピアリング A 100 Gbps、ダウン プライベートピアリング B 100 Gbps、90 Gbps を受け入れ 3 ポリシーを収容 トランジットアップリンク 第 2 候補パス 4 本目はこちらへ AS 200

メカニズムの動作例であり、ラボでの測定値ではありません。

4 台のルーターがそれぞれ 30 Gbps を 1 つの宛先へ送信し、 100 Gbps のプライベートピアリング 2 本 に分散しています。これらはトランジットより低コストなため優先されるピアリングです。その後、うち 1 本に障害が発生します。

標準の BGP では 120 Gbps 全体が残るピアリングに流れ込み、そこを通るすべてのサービスが一斉に劣化します。

帯域制約により、コントローラーはピアリングが伝送可能な分だけを受け入れます。そのため 3 つのポリシーは残るピアリングに収まり、4 つ目は第 2 候補パスでトランジットを経由します。

結果として発生するのは少量のトランジット費用のみで、ピアリング上のそれ以外のトラフィックは稼働を継続します。

ピアリングごとに固有のラベルを付与

egress-engineering を境界ルーターで設定すると、そのピアリング用の BGP Peer SID が割り当てられて広告されるため、コントローラーはセグメントリストの最後に出口を配置可能。

リンクアフィニティは境界まで適用

BGP Peer SID はリンク属性を持たないため、コントローラー上で出口ピアにアフィニティと帯域を割り当て、広告された SID と照合します。

空き容量のある最寄りの出口を使用

エンドポイントを null としたポリシーは最寄りの適切な出口を要求するため、コントローラーはヘッドエンドに最も近い条件を満たす出口を選び、トラフィックはバックボーンを横断する前にネットワークから出ていきます。

共同検証の範囲外のコントローラー機能：null エンドポイントにはカラーステアリングが必要ですが、共同ラボでは全体を通じてサービスループバックステアリングを使用しました。

ピアリング障害はポリシー状態で確認可能

ネイバーがダウンするとピア SID が取り消されてイグレスポリシーは失敗し、その失敗がポリシー状態に報告されます。

共同で構築・テスト

共同ラボで検証した内容とその結果。

IP Infusion と Vegvísir Systems がこの設計を共同で構築し、公開しました。以下の表に、検証した各機能と各テストの結果を示します。

ルーターUfiSpace S9510-28DC
ルーターソフトウェアOcNOS 6.6.0
コントローラーTraffic Dictator 1.6
公開2025 年 8 月
共同検証で確認した 10 の機能。
機能 実施方法 結果
トポロジーエクスポート 1 台のルーターで IS-IS レベル 2 データベースを BGP-LS に再配布 R3 は 34 件のリンクステート情報（ノード 5、リンク 10、プレフィックス 19）をエクスポート。コントローラー側のテーブルでも受信を確認。
明示パス ポリシーで指定した厳密ホップと 2 Gbps の予約 セグメントリスト [16001, 16002, 16005] をインストール。
帯域制約 候補パスに設定した帯域値 明示パスポリシーの 2 Gbps の予約は計算時にチェックされ、コントローラーのデータベースに記録されました。経路上の各リンクで未予約帯域の減少として確認できます。アフィニティポリシーでは同じメカニズムを 40 Gbps で使用しました。
リンクアフィニティ 同じルーターペア間に admin group ごとに 1 つずつ設定した、計 2 つのポリシー BLUE の結果は [16004] （メトリック 10）、YELLOW の結果は [16002, 16004] （メトリック 20）。エンドポイントは同じで経路は異なり、メトリックの変更は一切なし。
サービスマッピング 個別のサービスループバック上の 2 つの L3VPN 顧客 各 VRF はそれぞれのポリシー上で解決。VRF101 での ping をトランジットルーターでキャプチャし、想定どおりのトランスポートラベルと VPN ラベルを確認。
経路の多様性 同じ非重複グループに配置した 2 つのポリシー アフィニティや明示パスを一切設定せずに、2 つのポリシーは常に異なるリンクを使用。
ECMP とエニーキャスト SID ノードフラグをクリアした状態で 2 台のルーターが広告する共有プレフィックス SID 2 つのセグメントリストが 1 つに集約され、転送テーブルの容量を節約。
イグレスピアエンジニアリング 外部ピアリング用に割り当てた BGP Peer SID と、そのピアリングへのステアリング セグメントリスト [16002, 25600]。最後のラベルはルーターではなくピアリングを示します。アフィニティを追加した結果は次のとおり： [16001, 16002, 25600].
コントローラーのフェイルオーバー ポリシーを委任した状態でプライマリコントローラーを停止 ルーターはすべてのポリシーを 2 台目のコントローラーに再委任。両者の間で状態の同期は一切なし。
全コントローラーの喪失 すべてのコントローラーを停止 ポリシーは取り消され、サービスルートは IS-IS セグメントルーティング上で解決、ネクストホップは不変。テーブル読み取り時点で代替エントリはインストール済みでアクティブ。

検証は 1 つのプラットフォームで実施しました。検証したアーキテクチャは標準の IS-IS、BGP-LS、PCEP であるため設計はそのまま適用可能です。プラットフォームとリリースの対応状況は、 ハードウェア互換性リスト と フィーチャーマトリクス で、対象機種について確認してください。

障害時の動作

コントローラーを 1 台失った場合と、すべて失った場合の動作。

いずれの場合もトラフィックは流れ続けます。 コントローラーを 1 台失った場合、ルーターはポリシーを別のコントローラーへ移し、 すべてを失った場合、サービスは IGP がすでに計算していた最短経路にフォールバックします。

コントローラーを 1 台失った場合、ルーター自身がポリシーを再委任

各ポリシーは作成したコントローラーに委任され、そのコントローラーが応答しなくなると、ルーターが別のコントローラーに再委任します。このメカニズムはコントローラー間ではなくルーター内で動作するため、 コントローラー同士が状態を共有することはありません。そのため 3 台目を追加しても、状態同期のコストは発生しません。

障害が発生したコントローラーから稼働中のコントローラーへ移る PCEP 委任 1 台のルーターの上に 2 台のコントローラー。ポリシーは最初にプライマリコントローラーに委任されます。プライマリが応答しなくなると、ルーターはその委任を取り消し、同じポリシーを 2 台目のコントローラーに再委任し、2 台目がポリシーの更新を継続します。2 台のコントローラー間では何も同期されません。 コントローラー A 応答停止 コントローラー B ポリシーを保持中 OcNOS ヘッドエンド 転送を継続 委任 取り消し 再委任 ルーターが実行 両者間の状態共有なし

すべてのコントローラーを失った場合、すべてが IS-IS 上で再び解決

ポリシーは取り消され、サービスルートは代わりに IS-IS セグメントルーティング上で解決されます。 BGP ネクストホップは変わりません.

R3（コントローラー停止前）
P>  172.16.101.4/32   out-label 3       out-intf cd1   nexthop 10.100.3.2
P>  172.16.102.4/32   out-label 3       out-intf cd0   nexthop 10.100.6.4
P は SR Policy エントリ。2 つのサービスが 2 つの異なるエンジニアリング経路を使用。列は show mpls forwarding-table の完全な出力から要約しています。
R3（コントローラー停止後）
B>  172.16.101.4/32   out-label 24962   out-intf cd0   nexthop 4.4.4.4
B>  172.16.102.4/32   out-label 24963   out-intf cd0   nexthop 4.4.4.4
B は IS-IS セグメントルーティングで解決された BGP エントリ。VPN ルートの BGP ネクストホップは変わりません。変わるのは解決方法で、ポリシーではなく IS-IS セグメントルーティング上で解決されるため、送出ラベルとインターフェースが異なります。テーブル読み取り時点で、両エントリの経過時間は 16 秒でした。列は完全な出力から要約しています。
SR-MPLS、TI-LFA、Flex-Algoアンダーレイそのもの：IGP によるラベル、高速リルート、低遅延プレーン。 RSVP-TE と、今なお優位な場面シグナリングによる帯域アドミッション、DS-TE、オートバンド幅と、それらを維持すべき場面。 SR コアの設計デュアルプレーン、SRGB の計画、この設計が依拠するピアリングエッジ。 OcNOS の SRv6IPv6 データプレーンと、SR-MPLS と併用する際の位置付け。
設定例（両側）

ルーター側の設定は通常の IS-IS と BGP に、PCEP ブロックを 1 つ追加するだけ。

以下は共同検証からの抜粋にコメントを加えたものです。Traffic Dictator は業界標準の CLI を採用しているため、 コントローラーの設定もルーターの設定と同様に読みやすく、1 人のエンジニアが両側を担当可能です。

ポリシーをルーターへ届ける 2 つのプロトコル

PCEP 検証済みの組み合わせ

ステートフルであるため、コントローラーはルーターがポリシーをインストールして転送に使用しているかを把握できます。ヘッドエンドごとに 1 セッションが必要です。共同検証で使用したのはこの方式です。

BGP SR-TE セッション数が最少

ポリシーは BGP ルートとして伝送されるため、各ヘッドエンドへのセッションを必要とせず、既存のルートリフレクターを利用します。大規模ネットワークでは、数セッションで済むか数百セッションが必要かの違いになります。

OcNOS · BGP-LS エクスポート 
! feed the IS-IS link-state database into BGP
router isis 1
 distribute bgp-ls
!
router bgp 65002
 bgp router-id 3.3.3.3
 neighbor 192.168.123.1 remote-as 65001
 !
 address-family link-state link-state
 neighbor 192.168.123.1 activate
 exit-address-family

各行の役割

  1. distribute bgp-ls でエクスポートは完結：IS-IS がデータベースを BGP に引き渡します。
  2. コントローラーは、独自の自律システムに属する 1 つの BGP ネイバーにすぎません。
  3. link-state アドレスファミリはトポロジーを伝送します。伝送される情報は 3 種類：Node（システム ID とセグメントルーティンググローバルブロック）、Link（メトリック、帯域、admin group、隣接 SID）、Prefix（プレフィックスとその SID）。
  4. この設定が必要なのは 1 台のルーターのみ。IS-IS レベル全体がすでにそのルーターに渡しているリンクステートデータベースを、そのルーターが再広告するためです。

共同アプリケーションノート（IP Infusion、Vegvísir Systems、2025 年 8 月）より抜粋。最新の構文は次で確認してください： documentation.ipinfusion.com.

トラフィックエンジニアリングに関するよくある質問

SR-TE コントローラーとは何ですか？
SR-TE コントローラーは、ルーターに代わってセグメントルーティングのトラフィックエンジニアリング経路を計算し、インストールするコントロールプレーン要素です。トポロジーを学習し、帯域、リンクアフィニティ、経路の多様性などの制約を適用した上で、各ヘッドエンドルーターにセグメントリストを渡します。
セグメントルーティングの運用にコントローラーは必要ですか？
いいえ。セグメントルーティングはコントローラーなしで動作します。SR 拡張を備えた IS-IS または OSPF だけで接続性、ECMP、TI-LFA によるローカル保護が得られ、Flex-Algo はコントローラーを一切使わずに IGP 内で低遅延プレーンやアフィニティプレーンを構成します。コントローラーを追加するのは、ホップ単位の明示パス、ネットワーク全体での帯域予約、出口ピアの選択、あるいはリンクを共有しないことが保証された 2 つのサービスが必要な場合です。
Traffic Dictator は必須ですか？ 別のコントローラーも使用できますか？
OcNOS は標準の BGP-LS と PCEP に対応しているため特定のコントローラーに依存せず、同じ理由で Traffic Dictator もマルチベンダーに対応しています。共同設計で OcNOS と Traffic Dictator を組み合わせているのは、IP Infusion と Vegvísir がこの設計を共同で構築・公開し、両側の設定とラボ結果を提示しているためです。他のコントローラーを使用する場合も、ルーター側は変わりません。
このソリューションの各部分は、どこが提供・サポートしますか？
各部分はそれぞれのベンダーが提供します。IP Infusion はルーターと OcNOS を 1 つの統合システムとして提供し、Traffic Dictator は Vegvísir Systems が提供します。両者は共同で設計・テストされ、共同アプリケーションノートとして公開されています。お問い合わせいただければ両側のスコープ検討を支援し、コントローラーについては Vegvísir をご紹介します。
SR-TE コントローラーを追加するには、既存のルーターを置き換える必要がありますか？
通常は不要です。PCEP または BGP SR-TE に対応したルーターはポリシーを直接受け取れるため、対応するヘッドエンドにコントローラーを導入し、それ以外のネットワークは現在と同じく IS-IS セグメントルーティングで転送を継続します。いずれにも対応しない機器はヘッドエンドにならないだけで、ヘッドエンドである必要もありません。そのため混在環境も対象に含めたまま、自社のスケジュールで機器を入れ替えられます。
サービスを再構築せずに RSVP-TE から移行できますか？
はい。共同設計でカラーステアリングではなくサービスループバックステアリングを採用しているのはそのためです。PCEP は RSVP-TE トンネルとセグメントリストの両方を伝送し、サービスループバックはどちらでも機能するため、サービスの設定を変更せずに 1 つずつセグメントルーティングへ移行可能です。移行完了後は、より柔軟なモデルであるカラーステアリングが選択肢になります。
帯域予約を計測トラフィックに追従させることはできますか？
現時点では対応していません。ポリシーは設定された帯域値を保持し、コントローラーは経路をインストールする前にその容量が空いていることを確認します。これは共同ラボで 2 Gbps と 40 Gbps で検証した動作です。計測値に基づいて予約を自動調整するのは RSVP-TE の動作で、MPLS-TE のページで解説しています。Traffic Dictator は現時点でこれに対応しておらず、Vegvísir Systems は顧客の要望に応じて開発を行うため、必要な場合は早めにご相談ください。
この設計で SRv6 トラフィックエンジニアリングはサポートされていますか？
共同検証の対象は SR-MPLS のみで、制約となったのはコントローラーではなく、テスト対象のルーターリリースでした。OcNOS 自体は SRv6 データプレーンをサポートしているため、SRv6 トラフィックエンジニアリングについては、想定する特定のリリースとプラットフォームでご確認ください。
資料のダウンロード

ラボの全容をご覧になりますか？

本ページより踏み込んだ、短い技術資料：セグメントルーティングのアプリケーションノート。

アプリケーションノート

セグメントルーティング アプリケーションノート

エンジニアリングの詳細解説：検証済みラボ、両側のすべての設定、BGP-LS と PCEP のセッション出力、計算されたセグメントリスト、障害テストを順を追って掲載。

アプリケーションノートを入手
次のステップ

概念実証（PoC）へ。

Vegvísir Systems は Traffic Dictator を評価および概念実証向けにライセンス不要で公開しており（ポリシー数は 100 まで）、OcNOS は仮想マシンとして入手可能です。ステアリングしたい内容をお知らせいただければ、適切な組み合わせでスコープを検討し、その後本番環境の規模を見積もります。

OcNOS 仮想マシンを入手 エンジニアに相談する 購入方法