The Long And Winding Road

網統合のアプローチと想定される課題

ソフトバンクＢＢ株式会社
ネットワーク本部 技術企画部
西 和人

網統合と私・ 今は無き某社で「広域ＬＡＮサービス」の開発してました（1998年〜2003年）
・ 企業網はFrameRelayなども多かった頃（MPLS/IPVPN前夜〜初期）

日本

初期
10M eth <-> T1
単一センターにEthスイッチ
生イーサ（Tag無し）
No Virtualization
Poor Control Plane (STP☺)

中期
100M eth <-> JT2/OC3 ATM
1G eth <-> OC12EthSW分散して相互接続
Tagged VLAN → QinQ
MSTP, RSTP and etc
Poor Control Plane
Poor Management Plane

東海岸

末期
太平洋と北米大陸を１つのブロードキャストドメインにしてみた（東京からのTCNがちゃんと届いた）
trans-pac: OC3 SONET
US横断： OC3、一部martini

網統合と私当時と今で、何が違うかよくなったこと網統合に使える技術は増えた/ている
選択肢が多様になり、L2サービスをパケット網上に重畳させやすくなった
MPLSサポートの機器も多様になり、遊びやすくなってきた

変わってないことControl / Management Plane の悩み
昔： Poorだった
今： 複雑になった

網統合技術への過度な期待
昔： 「ストレージもやりたいな〜」 → iSCSI over Ethernet over ATM
今： 「ストレージもやりたいな〜」 → FC over PWE3

今も昔も結局Ethernet重畳がメインなんだなぁ
非同期の上にはやはり非同期。扱いやすいメディア。

つらくなったんじゃないか、と思うこと
異技術の相互接続（forwarding plane連結）のシチュエーションが増えそう
Control / Management Plane での Interwork で悩む局面も増えるんじゃない（漠然と）

網統合と私そして現在・・・・
ソフトバンクグループの技術部門の中で、管理系を担当（金・人など）
今日は「業界ウォッチャー」としての立場で、網統合について喋ります

最近の業界停滞気味だったキャリア・ISP向け機器市場がちょっと元気にこないだまで、ベンダーの営業さんはみんな辛そうだったのに・・・
パケットベース、イーサベースの新技術の標準化が活発にどれを選べばいいんでしょう
IMS/FMCといったキーワードが、一般雑誌にも初出はD○MEと日○トレンディ・・・
NGN流行ってますね
やたらと なんちゃらconvergenceという人が多い

最近のソフトバンクグループも「網統合するぞ」と表明しております
他人事ではない「網統合」

網統合のモチベーション• 以前は・・・
・ 今は・・・「ユーザのネットワークとネットワークをつなげる」サービス
どちらかというと新しいビジネスのネタ
大規模キャリア/ＩＳＰ自身にとって、大きなチャレンジ

最近の背景・状況- 従来メディアのパケット化の流れの定着（IP電話、IPTVなど）- 携帯電話、固定電話のパケット対応の流れ（SIP, IMS, IUB, Femtoなど）⇒ サービスのIP化、サービスを支えるコンポーネントのIP化が進展⇒ んじゃ、みんなパケットにしちゃえ
1.
CAPEX/OPEXの抑制・削減
1. 新サービス、新機能の実装

パケット化への複数ネットワークを単一インフラで統合・重畳することによるアセット整理、コスト抑制
網統合をベースにしないと実装困難なサービス・機能への対応
対応

2. 新サービス、新機能の実装
陳腐化・老朽化への対応
網統合をベースにしないと実装困難なサービス・機能への対応
老朽機器をアップグレード、でもレガシー通信技術はサポート

NGNのお題目に使いまわせます
老朽機器をアップグレード、でもレガシー通信技術はサポート
複数ネットワークを単一インフラで統合・重畳することによるアセット整理、コスト抑制

3. 陳腐化・老朽化への対応
CAPEX/OPEXの抑制・削減

網統合は難しい“The Long And Winding Road”“Long”
いろいろと長い•発案からサービスインまでが長い•統合による効果が現れるまでが長い•役に立ちそうな技術が世に出てから製品化されるまでが長い

お金もかかるし関る人も多いし•技術チャレンジのハードルが高い“Winding”
紆余曲折多し使える機器が少ない使える技術の仕様がまだ標準化されていない
スケジュールの途中で採用技術を変えたくなったりする•ゴールがぶれやすい
あれもやりたい、これもやりたい

市場に機械があるようで、ないし網統合は難しい“The Long And Winding Road”
日頃の情報収集と市場調査

結局、日々の積み重ね

ITU-T, IEEE, IETFウォッチングだけでは不十分
要素技術毎に存在するコミュニティへのアプローチが不可欠
機器ベンダー、Sierが解を持っているとは限らない
でもベンダー独自技術が役に立つケースも多い

統合ネットワークのイメージと目的を適切な抽象度で明確化
どういうネットワークを作るのか、そこにはどういうゴールが待ってるのか

統合対象ネットワークの適切な理解
現用機器にどんなサービスがどんな形で絡んでいるか、100%把握していますか？

網統合の難しさ
何を、どこで、どこまでやるか、で複雑さが大きく変化
アプリ、管理系統合
サーバ統合
OSS/BSS統合
管理システム統合
サービスPF統合
・・・・

依存

依存

統合ネットワーク
統合ネットワーク
ゴールのイメージ
ゴールのイメージ
ネットワーク、通信網統合
パケット網統合
固定通話・IP統合
移動体・IP統合
・・・・

依存

トランスポート統合
ファイバー、波長
トンネル・パス・サーキット結合
伝送機器統合パケットベース技術での統合
・・・・

網統合のパターン

同質NWの統合提供されているサービスや性質が類似•技術的な困難なチャレンジというのは、あまりない？

単純統合

統合難易度

低

•どちらかといえば、淡々とやればいいベンダー・設定・設計の差異の吸収など

レイヤー毎に
結合

統合難易度

中

•レイヤ毎に見ると、単純結合機能追加を伴う場合は困難さを増す•パケット化できるところはパケット化したくなる

異質NWの統合提供されているサービスや性質が異なる

従来レイヤーを壊す形で結合

統合難易度

高

•MPLSやパケット・トランスポート中心に網統合•網設計が複雑で、利用できそうな技術が雑多•技術的にもチャレンジを強いられる局面が多い
レガシーメディア、同期通信サポートを伴う場合は特に•サービス統合とトランスポート統合が相互影響•運用が複雑かつ重要に

網統合のパターン（ネットワーク統合）
パケット
パケット

IP

少数網（パケット系）を統合

IP•ノウハウ、実装例は多い•運用に苦労しているケースが多い•スケーラビリティの求め方によってチョイスが変わる

Ether
Ether
Ether

Ether
opticalopticalTDM

多種網を統合TDM• ノウハウ、実装例はない、少ない• パケット網に何を載せるか、載せないかパケット
パケット
IP

FR
ATM

Ether
Ether
SONET
SONET

FR
ATM

opticaloptical
Ether

Ether

IP

同期網を混ぜるか混ぜないかは大問題•統計多重をあきらめる、追い求める•クロックをどうするか

網統合のパターン（サービス統合）

サービス
認証

サービス

課金

番号管理

課金

サービス

サービス

管理

課金

広告

番組

パケット

中継

パケット

IP

中継・交換

交換

トランスポート

トランスポート

トランスポート・RAN

トランスポート・RF

インターネット・イメージ

固定電話イメージ

携帯電話イメージ

放送イメージ• 特定のサービス・アプリに直結していたトランスポートや機能を分解• 分解された要素を「IP・パケット」で縦・横に結合• サービスは統合された「プラットフォーム」で見せる•下位層は上位層から隠蔽サービス（IP, 電話, 携帯, 放送）
プラットフォーム
認証

課金

番号管理

サービスと下位層のbindingをどう扱うかがポイント
広告

番組

IP, Others
newトランスポート

従来トランスポート

プラットフォーム統合イメージ

Memoバーチャルルータによる異サービス統合は面白い
サーバまで仮想OSでvirtualization
ストレージもiSCSI/FCIP/FCoPWでvirtualization

網統合とVirtualization
内部構造の隠蔽・保護
セキュリティ
ユーザビリティコンポーネントを不可視に細かいことは気にしなくてよい•下位層のリソースを扱いやすくする
複数リソースを結合して、単一リソースに見せる（スケールしない）単一リソースを、複数のentityに見せる
複雑に結合された複数のリソースを、単純な単一entityに見せる(ex)リンク・アグリゲーション(ex)バーチャルルータ(、NAT)(ex)トンネル、カプセル化
エミュレーション

上位層
単純化
隠蔽

仮想化により、Resource usabilityが増す

全体の系としては、複雑さを増す
危険性がないか

網統合技術同士のインターワークどうする？
forwarding/control/management のplane毎統合・インターワーク

シンプルな「系としてのネットワーク」とは？
深すぎるスタック、中途半端な仮想化、完全に媒体特性をエミュレートしきれるか

網統合技術のパターンは雑多
ＩＰ
ETH
WDM

＋

ＩＰ

WDM

ネットA

ネットB

ＩＰ

ＩＰ

ETH
WDM

＋

ネットA

ETH
WDM

ふつう

統合ネット

× 魔法の技術 ＝

Tpt.
WDM
ネットB

***PWE

PWE

PWE

MPLS

MPLS

MPLS

どれ？
他にも一杯＝ETH

ＩＰ

ＩＰ
ETH

SDH
WDM

ＩＰ

ＩＰ

ＩＰ

ETH

ETH

PBB-TEPBB-TE

T-MPLS

T-MPLS

WDM, other

WDM,other

WDM,other

WDM,other

*ＩＰ
**

*

分析・モデリング
詳細設計前の、概要設計の段階が肝関係する全ての人が混乱しがち

1. 統合対象となっているネットワーク機器とサービスの依存関係整理
2. 統合後のネットワークと、その上で実装される機能サービスの依存関係整理
3. 高い抽象度になっているモデルを徐々にブレイクダウン⇒ ここでどのような網統合技術が適切かをチョイス・検討⇒ 識別されたコンポーネント毎にキャパ、機能などのパラメータを追加

当たり前の設計ステップの中で、機器とサービスの依存関係の識別を

設計書

・・の前に

○○サービス××サービスコンポーネントコンポーネント
Type: Server
Type: Router
Role: Accounting Role: Service Edg…
…

コンポーネントコンポーネント
Type: Router
Type: Server
Role: User Edge Role: Management…
…

コンポーネント
Type: ADM
Role:Tokyo Ring.1…

オフトピック - 最近の勘違い
IPネットワーク系の設計担当への質問
質問者「IPv6とか将来バックボーンインフラとか検討されてるんですよね？」
担当者「ま、まぁ、そうですけど・・・」
質問者「CSCFってなんですか？」
お門違い「IPv6と将来バックボーン」から、IMSに行き着く稀有な例（ある意味、理解してる）
最近の技術の複雑さと、全体像・関連性の不明瞭さを表している
某地方ISPさんからの質問
おんなじ誤解は、網統合の企画時・設計時において
質問者「うちのバックボーンもQoSもっとちゃんとやった方がいいんですかね？」
社内でも社外でも起こりうる
私「お、何か新しいことでもお考えですか」
質問者「ええ、FMCしようかと思って」 モバイルもWi-Fiもやってないじゃん・・・
最近のメディアでのキーワードの氾濫により、誤解が蔓延している（ここまでひどくないけど）キーワードの定義が曖昧なまま使われてることも多い某Sierさんとの飲み会での会話
Sierさん「うちで扱ってる製品、NGN対応って唄ったら売れますかね」

好きにして・・・

運用は難しい異種ネットワークをエミュレーション、トンネルしながら統合する
通信技術によって異なるOAMとアラート発報スタイル
ベンダーによって異なるNMS、OSSインタフェイスとの差異
Event Correlationが複雑

統合ネットワークにおけるトンネル・パス・サーキットの包括的な監視
MPLSだけみても、そもそもLSPの管理が限界だったりしないだろうか
みんな結構自作ツールでやってるのかな
MIBがあってもそれだけでは・・・？？

BFDとかLSP PingとかVCCVとかEnd-End OAM

LinkInter-domain

Inter-domain

Link

Link

Link

運用の統合からはじめよう•OSS/NMSの更改・統合は割りと時間がかかる
大規模であれば、ベンダーお任せのケースもあるでしょう
開発も入るし•OAMがイマイチなケースもあるでしょう
自作ツールとNMSの結合なんてこともしなくてはいけない•設定管理も複雑にNETCONFとか使えるものはあるでしょうか
？？
生死監視

パス管理

課金・認証

トラブルチケット

運用統合はお早めに•金も時間もかかる•統合作業開始時には、運用統合できてないと•企画設計段階から運用と仲良しに

End-End OAM

LinkInter-domain

Inter-domain

Link

Link

Link

オフトピック - UMLと設定管理

出典:
Distributed Management Task ForceCIM (Common Information Model) 2.16
Network Specification - BGP

オフトピック - UMLと設定管理

出典:
Distributed Management Task ForceCIM (Common Information Model) 2.16
Network Specification - MPLS

MPLSは便利につかえる
1. フレキシブルな仮想ネットワーク・プラットフォームだった
L3 VPN / CsC / VR / Pseudowire

2. 運用を向上させる機能があった
よかったものFast Reroute / TE

3. ISPバックボーンに実装しやすかったルータを総入替えしたりしなくてよかった

4. L2 transportサービスをパケット網で提供できるようになった
VPNの延長としてのEthernetを中心に
Ether-A
privateIP-A
private
IP-B

ＭＰＬＳ
ＭＰＬＳ

IPVPN / VR

便利に使えているノウハウもたまってきた

privateIP-B
privateIP-A

Ether-nEther-A
Ether-nEther-B

ＭＰＬＳ
ＭＰＬＳ

ATM

Ether-nEther-A
Ether-nFR
EoMPLS / (H)VPLS
Pseudowireさて、これらはどうか
T-MPLSFor Any L2

PBB
For Ethernet Service•ITU-T由来（w/ IETF） OAMや各種拡張が徐々に出始めている•IETF MPLSをtransport適応させた / Pseudowire??コントロールプレーンは、GMPLS/ASONで・・・•IEEE802.1q、802.1ad、802.1ahと”Tag”の概念をストレートに拡張。
•Tagのスタッキングとmac-in-macによる、でかいヘッダが特長。
•TE機能の拡張も検討？？OAMとコントロールプレーン• レガシーネットワーク（FR, ATM他）をどういうレベルでサポートしたいか• MPLS PWとのインターワークをどうとるか• プラットフォーム機器でのサポートはどうか（トランスポート、ＩＰ）

つぶらな瞳で考えること
なんか最近似たような技術が多くない？
• どっかから、何かを借りてきて、「新しいコンセプト」と言ってみる• 「transportからのアプローチ」「電話からのアプローチ」• ITU-T, IEEE, IETFで仕様が入り乱れ、綱引きもある

あれもある、これもある•「あれもできる」「これもできる」と言われる•「これはできない」とあんまり言ってくれない•しかも実際の機器に実装されるのは、結構先の話だったりすることもある•異種技術のインターワークで、 OAMが複雑になる、運用が死ぬ、ってことはないのか「ここはBFDね」「ここはpingね」「ここはVCCVね」「ここは Y.ほにゃららね」「ここは・・・なにもない」

他の技術と疎に関連した技術が多く、志向性が微妙にみな違う
実は、これが統合の最大の悩みでは？
技術A

技術B技術C

まとめ
網統合におけるポイント
明確かつ具体的なイメージが共有できるモデル作り
統合対象のスコープのイメージの明確化（物理、論理、運用）

垂直方向での「サービスと下位コンポーネントの依存関係」分離と整理
単純に網をくっつけて終わり、というわけにはいかない
それでいいケースもある
無理やり「パケット網」に重畳しても、意味が無いケースはありうる（例: MSTP買えばいいじゃん）

ベンダーさんを早めにリードする•••

使いたいときに、技術仕様は確定していないことが多い
使いたい技術が、採用したいベンダーでサポートしてないことが多い
特にレガシーメディアを重畳したい場合には、インタフェイス自体が無いケースもある

運用は早め早めに手をつける••

どうせOAMで悩む、サポートツールを作る、開発もいる
運用設計を後回しにすると、後日喧嘩になる ☺

Thank you＆Enjoy•Scalability Analysis of L2 and L3 MPLS VPN Technologies.
Service Provider Perspective.
•ロジカルルータを利用したマルチレイヤ・サービス・ネットワーク構築技術•MPLSによるLegacy Network Migrationの課題•網統合における課題を再考する