マネージメントプレーンの設計・構築に関する一検討

社団法人 電子情報通信学会
THE INSTITUTE OF ELECTRONICS,
INFORMATION AND COMMUNICATION ENGINEERS
信学技報
TECHNICAL REPORT OF IEICE
光 IP 統合網におけるコントロールプレーン，マネージメントプレーン
の設計・構築に関する一検討
磯貝彰則†
増田暁生†
塩本公平†
†NTT ネットワークサービスシステム研究所 〒180-8585 東京都武蔵野市緑町 3-9-11
E-mail: †{isogai.akinori, akeo.masuda, shiomoto.kohei}@lab.ntt.co.jp
あらまし 本稿では，バックボーンネットワークにおいて，ネットワークリソースを仮想的に配分し，複数のサ
ービス網を効率的に運用・制御する光 IP 統合網について，コントロールプレーン，マネージメントプレーンを設計・
構築する際の指針を示す。具体的には，各プレーンのネットワーク構成法と運用管理における障害範囲の切り分け
が容易なアドレス設計例を述べ，光 IP 連携サーバとコントロールプレーンの接続方法について述べる。また，コン
トロールプレーンの構成法の違いによる，装置の負荷や光 IP 連携サーバの観点で考察を行った。
キーワード
光 IP 統合網，光 IP 連携サーバ，GMPLS，コントロールプレーン，マネージメントプレーン
Building control and management planes for IP optical networks
Akinori ISOGAI†Akeo MASUDA† and Kohei SHIOMOTO†
†NTT Network Service Systems Laboratories, 3-9-11 Midori-cho, Musashino-shi, Tokyo 180-8585, Japan
E-mail: †{ isogai.akinori, masuda.akeo, shiomoto.kohei }@lab.ntt.co.jp
Abstract We indicate guideline that building control and management planes in IP optical networks. We describe five
requirements, control and management plane separation, control and management plane topology, address setting, connectivity
of IP optical TE server with control plane and packet filtering in control plane. After we introduce above requirements, we
explain a merit by the viewpoint of load and delay.
Keyword IP optical networks, IP optical TE server , GMPLS, Control plane, Management plane
1. はじめに
我々は，GMPLS を用いてバックボーンネットワークを制御
する光 IP 統合網について提案を行っている[1, 2]。光 IP 統合
網においては，光網におけるレイヤ 1 のファイバリソースや
波長リソース，TDM リソースなどの資源を，サービス網へと
その権限を配分付与することにより，サービス網のオペレー
タ が 配 分 さ れ た 権 限 内 で 自 由 な VNT(Virtual Network
Topology)を構築する事が可能となる。我々は，この様な制御
を実現するために，光 IP 連携サーバを開発してきた。光 IP
図 1. 光 IP 統合網と光 IP 連携サーバ
連携サーバは，GMPLS/MPLS プロトコルを用いて光 IP 統合
トラヒック情報や故障情報を収集するため，SNMP[5]を用い
網を複数のサービス網に分ける仮想化制御機能とサービス網
て MIB 情報を取得し，
VNT 再構成のトリガ条件に活用する。
からのパス制御機能を実現する。具体的には，リソース管理
光 IP 統合網は，これらの制御を実現するために，OSPF-TE
のためのトポロジや残余帯域の収集のために，OSPF-TE[3]を
や RSVP-TE などを送受信するためのコントロールプレーン，
用い, 光パス/MPLS パスの設定削除のために RSVP-TE[4]を
TELNET／SSH，SNMP による管理用のマネージメントプレー
用いる。さらに，サービス網のトポロジを自動的に最適化す
ン，実際にデータを送受信するデータプレーンを構成する必
る VNT 再構成機能を有する。これは，トラヒック変動や故障
要がある。光網においては，コントロールプレーンを基にリ
などのトリガで起動し，品質や信頼性に基づいて IP トポロジ
ソースを管理し，サービス網においては，サービス網毎のコ
でのルーチングの最適化を行う。
また，
光 IP 連携サーバでは，
ントロールプレーンを活用して複数の網を重畳して収容する
【アドレスの設定】
ため，これまでのネットワーク運用管理の要件とは異なった
概要：各種アドレス設計は，装置種別やノード情報を識別可
構築手法や運用管理手法が必要となる。我々は，実際に市販
能なルールを定めて付与
の GMPLS ルータと光スイッチを用いて，光 IP 統合網を構築
効果：障害発生時のトレーサビリティ向上
し，単一の光網と複数のサービス網を構築し，実際に運用管
理を行った。
本稿では，実網の運用管理を通じて得た運用管理の知見に
【光 IP 連携サーバと光網／サービス網コントロールプレー
ンの接続】
ついて報告する。以下，本稿の構成は 2 章で光 IP 統合網の構
概要：光 IP 連携サーバは，光パスの有無に関わらず，光網・
築と運用管理のポイントについて述べ， 3 章で具体的な効果
サービス網のコントロールプレーンと接続
について述べる。4 章でコントロールプレーンの構成につい
効果：OSPF-TE によるリソース情報収集に活用
ての考察を述べた上で，5 章でまとめを述べる。
【サービス網コントロールプレーンにおけるフィルタ】
概要：サービス網におけるコントロールプレーン（データプ
レーン上の通信を除く）について，制御用トラヒック以外の
フィルタ制御を適用
効果：サービス網におけるコントロールプレーンに，データ
トラヒックが流れることを防止
3. 設計・構築に関する効果
本章では，前章で述べた光 IP 統合網の設計・構築の指針に
図 2. サービス網における運用画面
2. 光 IP 統合網における構築・設計指針
ついて，以下の詳細を示す。
【マネージメント／コントロールプレーンの分離】
本章では，光 IP 統合網の構築・設計指針について示す。
光 IP 統合網には，GMPLS プロトコルの動作が必要である。
コントロールプレーンについては，光網とサービス網にそ
GMPLS においては，データプレーンとコントロールプレーン
れぞれ存在し，光網では，GMPLS 用途の OSPF-TE，RSVP-TE
の概念が明確に区別されており，ここではアウトバンドによ
パケットが流れ，サービス網では，MPLS 用途の OSPF-TE や
るコントロールプレーンの構築を想定する。加えて，運用管
RSVP-TE が流れる。
理のためのマネージメントプレーンが必要となるが，マネー
マネージメントプレーンについては，光網とサービス網を
ジメントプレーンの障害やコントロールプレーンの障害時に，
問わず共通で必要である。このプレーンには，GMPLS／MPLS
到達性の確保が必要であり，構成として物理的又は論理的に
ルータや光装置などにログインするための TELNET／SSH，
分けて構築することが望ましい。特に，運用管理の観点では，
トラヒック情報を収集するための SNMP などの各種パケット
各インタフェース上を流れるトラヒック量（ログイン制御の
が流れる。以下に，コントロールプレーン，マネージメント
トラヒック，OSPF-TE 等の制御メッセージ量）を SNMP の
プレーンにおける構築・設計の指針を示す。
MIB で取得する場合を想定すると，物理的／論理的に分離す
＜構築と運用管理の要点＞
Ifindex 値を基に IF 固有のトラヒック量の取得等が実現できる
ることによって，装置内で別 IF として認識可能となり，各
【マネージメント／コントロールプレーンの分離】
ため，運用管理の情報としての活用が期待でき，物理的又は
概要：マネージメント／コントロールプレーンは物理的又は
論理気に分離して構築するメリットが大きくなる。
論理的に分離して構築
効果：マネージメントプレーンにおける障害時に，コントロ
ールプレーンでも到達性が確保可能でなり，各 IF のトラヒッ
ク量が SNMP で別に取得可能
【マネージメント／コントロールプレーンの構成】
マネージメントプレーンについては，新たな装置を追加す
る際に，簡単に接続可能であり，運用管理が容易な構成がよ
い。特に，シンプルでフラットなレイヤ２ネットワーク構成
【マネージメント／コントロールプレーンの構成】
はプレフィクス観点でも管理がしやすく，レイヤ３と比べる
概要：マネージメント／コントロールプレーンは，フラット
と，低レイヤであるために，一般的に問題の切り分けも少な
な広域レイヤ２ネットワークで構成
くて済む。これについては，単一セグメントで収容する観点
効果：フラットな IP アドレス空間で構成可能なため，構築や
で，利用するプレフィクスや装置数を考慮した上で設計する
装置の追加・変更時の設定変更が容易
ことが必要となる。
コントロールプレーンについては，マネージメントプレー
ンと同様に，新たな装置の追加や構成変更が容易な形態がよ
い。光網のコントロールプレーンでは，データプレーン上で
隣接関係を持つ装置間（GMPLS ルータと波長装置）の間にコ
ントロールチャネルを構成する必要がある。これは特定の装
又は論理的に分離して構築を行う。
＜マネージメントプレーン IF アドレス：10.2.0.X/24＞
アドレス値として，ルータ ID の X 値をそのまま活用し，上
記のようなアドレス値を付与する。
置によっては該当装置間に Point-to-Point となるように設定が
必要な場合があり，実際に装置間を Point-to-Point に物理接続
する構成では，データプレーンの接続関係が変更した場合な
＜TE-LINK アドレス：10.Xa.Xb.Y （Xa<Xb）＞
リソースの識別子として用いる TE-LINK アドレスの形式
どに，配線の変更や装置の大幅な設定変更が発生する。これ
として，10.Xa.Xb.Y という値を採用する。利用するアドレス
に対し，コントロールプレーンをレイヤ２ネットワークで構
は，ID として見なされ，32 ビットの IPv4 形式をとるが，ル
成し，必要に応じてトンネル技術などを活用して
ーチングに利用する IP アドレスと競合することはない。Xa
Point-to-Point 接続を組むことで，構成変更にも柔軟に対応で
と Xb という値は，
ルータ ID 値の X から構成される値であり，
きる。こちらもレイヤ３ネットワークで構成し，レイヤ３の
大小関係（Xa＜Xb）と決める。Y 値については，Xa と Xb の
トンネル技術で接続関係を変更することは可能だが，マネー
大小関係に基づき，Xa 側（ID の小さい方）に奇数値と Xb 側
ジメントプレーンと同様に問題の切り分けが難しくなる傾向
（ID の大きい方）に偶数値（Xa 数の値＋１）を付与する。
がある。一方，コントロールプレーンでは，OSPF-TE のマル
また，TE-LINK は，1 対のノード間に複数設定できるため，
チキャストパケット（Opaque LSA 等）が流れるため，必要以
装置間のリンク数に基づいて利用するアドレスの値などを定
上に多くの装置を同一のセグメントに配置すると，単一セグ
めることが有効である。上記の例では，Y 値に基づき 256 値
メント内における通信量の観点で増大する問題も発生する。
（最大 128 リンク）が表現可能である。
【アドレスの設定】
【光 IP 連携サーバと光網／サービス網コントロールプレー
光網で設定するアドレスについては，コントロールプレー
ンの接続】
ンアドレスやマネージメントプレーンアドレスを始め，
光 IP 連携サーバは，光網とサービス網のリソース状況を
GMPLS のための TE-LINK アドレスなど，設定しなければな
OSPF-TE の LSA を収集することで把握する。これは，光 IP
らない項目が多く存在する。また，設定値はオペレータにと
連携サーバと各網の間の接続性が必要となることを示す。
って障害発生時の原因箇所の絞り込みが容易であることが望
光網では，GMPLS のコントロールプレーンと接続し，サー
ましく，ここでは，アドレス値は，装置数や取り扱うリソー
ビス網についても，コントロールプレーンと接続する必要が
ス情報を基に利用するアドレス空間を決定した後，ノード識
ある。サービス網においては，制御のための OSPF-TE や
別子も考慮したアドレス設定を行うことで，運用管理を容易
RSVP-TE メッセージはインバンドであり，メッセージはサー
にすることを目的とする。具体例を以下に示す。アドレス空
ビス網のデータプレーン（光パス設定によって構成された IP
間として，光 IP 統合網内では，プライベート IP アドレス空
リンク）上で交換されるために，サービス網におけるデータ
間を用い，光網の装置数は最大でも 254 台以下と想定し，設
プレーンとコントロールプレーンは同一である捉えることが
計する。なお，TE-LINK についてはアドレス 32bit の IPv4 ア
できる。しかし，光 IP 連携サーバは，図 3 に示すように，光
ドレス等と同じ形式をとるが，値は識別子としてのみ利用さ
IP 連携サーバとリーチャビリティが無い対地間に光パスを設
れ，ルーチングには影響を及ぼさない。
定した場合，OSPF-TE によって対地間に IP リンクが出来たこ
とを確認する LSA を収集することができないため，サービス
＜ルータ ID：10.0.0.X/32＞
光装置の種別やルータ毎に判別を容易にするため，X 値とし
て種別毎に範囲を割り当てて付与する。この値は，OSPF-TE
などにおけるルータ ID として利用する。この X 値は他のア
ドレス設計値に対しても積極的に活用することで，装置の識
別を容易にする。
ファイバクロスコネクト装置に割り当てる X の範囲
１≦X≦１０
波長多重装置に割り当てる X の範囲
１１≦X≦２０
GMPLS ルータに割り当てる X の範囲
３１≦X≦５０
網で OSPF-TE の LSA を収集可能にするために，サービス網
に配置されるルータを対象にリーチャビリティを確保できる
ように別途コントロールプレーンを構築する。これにより，
従来光パスの設定のみでは LSA の収集が不可能であった場合
にも，OSPF による IP リンクの情報が収集可能となり，サー
ビス網の OSPF-TE の残余帯域広告に基づく MPLS パスの設定
が可能となる。
＜コントロールプレーン IF アドレス：10.1.0.X/24＞
アドレス値として，ルータ ID の X 値を活用し，上記のよう
なアドレス値を付与する。マネージメントプレーンとは物理
図 3. サービス網におけるコントロールプレーンの接続
【サービス網コントロールプレーンにおけるフィルタ】
5. まとめ
サービス網の OSPF-TE の LSA を収集するためには，上記
本稿では，リソースの配分・管理を行うことでネットワー
に示したとおり，サービス網のルータと光 IP 連携サーバの間
クの仮想化を実現する光 IP 統合網について，実際に光網とそ
に LSA 情報を伝えるための，コントロールプレーンを構築す
の上に重畳するサービス網の設計・構築における指針を示し
る必要がある。サービス網のルータ IF は，OSPF-TE の広告に
た。具体的には，マネージメントプレーンとコントロールプ
より，本来データプレーンを流れるはずのデータトラヒック
レーンの構成を分離することにより，障害時の接続性確保や
がコントロールプレーン上の IF に流れる可能性がある。その
運用管理時のトラヒック管理が可能となることを示し，アド
ため，各ルータにおいては，事前にサービス網のユーザプレ
レスをノードの ID 等の識別子を基に付与することで，障害が
フィクス相当のトラヒックを流さないといったフィルタリン
発生したノードや対象となる TE-LINK の切り分けが容易に
グ制御対処をする必要がある。具体例として，光 IP 統合網と
なるようにした。また，光 IP 連携サーバ特有の問題であるリ
接続するユーザ網で利用するプレフィクス 192.168.101.0/24
ソース管理のためのコントロールプレーン（OSPF-TE）との
が宛先アドレスとして設定されているパケットについては，
接続性の確保やサービス網のコントロールプレーン上にデー
該当 IF から転送を行わないといったフィルタを掛けることで
タトラヒックを流さないためのアクセスフィルタによる対処
実現できる。
法を示した。コントロールプレーン構築の観点では，L2／L3
4. コントロールプレーンにおける考察
ネットワークの構成法の違いによる装置への負荷や，OSPF
固有のタイマに依存した遅延の増大に注目し考察を行った。
【装置への負荷観点】
光網とサービス網のコントロールプレーンの構成について，
レイヤ２ネットワークで構成する場合とレイヤ３ネットワー
文 献
クで構成する場合，各装置が構成する TED/LSDB（Traffic
[1] 大木英司, 島崎大作, 松崎隆一, 井上一郎, 塩本公平，
「IP
Engineering Database／Link State DataBase）情報に差分はない
オプティカルネットワークにおける光 IP 連携サーバによるマ
が，OSPF パケットの流れ方が大きく変わるため，装置への負
ルチレイヤトラヒックエンジニアリング」
，NTT 技術ジャー
荷が変化する。単一のレイヤ２ネットワークで構成した場合
ナル, Vol.19, 2007
は，マルチアクセスネットワークとして，DR（Designated
[2] 大木英司, 島崎大作, 武田知典, 宮村崇, 井上一郎, 塩本
Router）が選出されるため，装置数が多いネットワークにお
公平，
「光 IP 連携サーバのプラットフォーム技術」
，NTT 技
いては，ルーチング処理などのプロセス処理能力が高い装置
術ジャーナル, Vol.20, 2008
又はサーバにプライオリティを高く与え，優先的に DR とす
[3] IETF RFC4203: “OSPF Extensions in Support of Generalized
ることが望ましい。しかし，装置数の増大に伴い，DR におけ
Multi-Protocol Label Switching (GMPLS),” October 2005
る通信負荷は大きくなるため，負荷が大きい場合は，レイヤ
[4] IETF RFC3473: “Generalized Multi-Protocol Label Switching
３接続を含めたコントロールプレーン構成を取ることで，単
(GMPLS) Signaling Resource ReserVation Protocol-Traffic
一の装置への負荷集中の回避をすることが必要となる。
Engineering (RSVP-TE) Extensions,” January 2003
[5] K. McCloghrie, “SNMPv2 management information base for
【リソース情報の広告遅延観点】
レイヤ３ネットワークで構成する際のデメリットとして，
the Internet protocol using SMIv2,” RFC 2011, Nov. 1996.
[6] R.Alnuweiri, L-Y K.Wong, and T.Al-Khasib,“Performance of
レイヤ２ネットワークで構成する場合と比べて，IP のホップ
new link-state advertisement mechanisms in routing protocols with
数が増えるために，トポロジによっては LSA の広告・再広告
traffic engineering extensions,” IEEE Communication Magazine,
時の OSPF 固有のパラメータに影響して広告に時間が掛かり，
May. 2004.
光 IP 連携サーバがリソース情報を把握するまでに時間が掛か
[7] 磯貝彰則, 増田暁生, 塩本公平,” 光 IP 統合網における光
ることが挙げられる。具体的に影響を及ぼす可能性があるパ
IP 連携サーバのネットワーク制御機能と性能評価，
” 電子情
ラメータとして，LSA 広告の最小間隔を示す MinLSInterval
報通信学会ネットワークシステム研究会 2010.03
（デフォルト５秒）や LSA 受信を許容する最小間隔を示す
[8] 磯貝彰則, 増田暁生, 塩本公平,”光 IP ネットワークの制
MinLSArrival（デフォルト１秒）が挙げられる。最悪の場合，
御プレーンにおける VNT 再構成の性能評価，
” 電子情報通
光 IP 連携サーバと広告する装置の間のホップ数に依存して，
信学会総合大会 2010
上記タイマの倍数に依存した遅延が発生する可能性がある。