KDDIにおけるネットワーク管理～統合IP網の運用上の課題～

2008/10/28
KDDI山形 倫裕agendaz

KDDIの統合網コンセプトz

マイグレーションz

統合網の運用zまとめ

2008/10/28

KDDI Proprietary and Confidential

2

KDDIの統合網コンセプト

網統合のコンセプトz

垂直モデルから水平統合モデルへの移行ServiceとTransportを分離
複数サービスを1つのIP網で提供
Service・・・・ ServiceService

Transport

Voice Data Internet VPN

Voice Data Internetz

VPN

メリットは？


2008/10/28

Opex/Capexの抑制、削減
サービス開発の効率化
老朽機器の更改KDDI Proprietary and Confidential

4KDDIの統合網とは？
z

固定とモバイルの融合が中心z

ネットワークのシンプル化
z

au oneによるサービス/ブランドの統一

同等のサービス/ネットワークが多い

マイグレーション

IP系サービスのコアからAccess/aggregation(レガシー系等)は検討中
PSTN

Accessaggregation

IP/MPLSコア

Internet

Other Network

2008/10/28

KDDI Proprietary and Confidential5

統合IP網への要件
 IP系サービスでは、料金は従量制から定額制へシ
フト

一方、「All IP化」の進展に伴い、通信キャリアのIPネットワークは「生活インフラ＝ライフライン」の位置付けへ いくら帯域を使っても、追加料金を徴収できないモデル

 とは言うものの企業系ユーザ等は、高品質、帯域確保を求められる。

 キャリアとして社会的基盤として高信頼なインフラ提供

 「Best Effort」と言いながら、実際は？？？

 次世代IPインフラ、NGNに関して総務省、標準化、他事業者の動きが活発化

 料金競争の激化に伴い、増収は困難な状況

相反する課題の克服

統合IP網への要 対価を払って頂けるお客様には高品質を提供する等、コスト効率のさらなる追求 ALL IP化に向けた、サービス共通のIPコアインフラとしての高信頼性の実現
 ベストエフォートサービスから脱却した付加価値の提供

コスト削減
コスト削減
2008/10/28

品質向上
品質向上

安全・安心
安全・安心

簡単・便利
簡単・便利

KDDI Proprietary and Confidential

セキュリティ
セキュリティ

相互接続
相互接続
6

マイグレーション

統合化概要z

先にコア網となるMPLS網を構築


各サービス網を順次統合
z

運用体系の変更


サービス別に独立した体制から統合IP網とサービスの連携をできる体制へz

物理的に先に接続

なるべく現行の運用スキームを変更しない

MPLSが動作している網であれば(技術的に)マイグレーションは意外に楽

Cost変更/LSPのexplicit
MPLSを動作させるときの方が大変

2008/10/28

新機能の導入運用手法の大幅な変更
 NWの構成要素が多くなり状況把握方法の変更
 トラフィック迂回作業等の作業手順の変更

KDDI Proprietary and Confidential

8統合網の運用/課題

各サービス網から変更となった主な点
z

LSPの増大/複雑化

サービスを統合すればするほど複雑に障害時のprotectionの確認
Traffic量に合わせて物理Linkが増大z

迂回作業の手順が複雑

Syslogの増大zSyslogが多すぎて障害場所の特定に時間がかかる

統合網での障害はそれぞれのサービスに影響

サービス側との連携が増大zTraffic分散用/backupのLSPが増大

状況確認等の連絡
監視の区分

サービス側からみると、統合網はよくも悪くもBlackBox


FRRが動作するような統合網の障害はサービス側ではわからない場合がある

2008/10/28

障害時間が短縮

統合網で何が起こっているかも把握したい

KDDI Proprietary and Confidential

10品質管理/セキュリティz

統合網への異なる要求

サービス網 #1


独立していたときとあまり変わっていないので今のままでもよいInternetよりは優先したい
Internetからのアクセスは止めたい

サービス網 #2



FRRでunicastの切り替わりが早くなったがMcastの切り替わりを早くしたい
独立していた時に行っていた障害対応を統合網でも行ってほしい
Voiceと映像は優先したいz

Mcastの切り替わり/障害対応のためにHA機能を充実
サービス監視のためにend-end監視の導入z

セキュリティz

サービス間インフラのアクセスを遮断2008/10/28

統合コアとinternetサービスの境界でfilter

KDDI Proprietary and Confidential

11

QoS/Traffic管理
z

QoS


サービス単位でExpをアサインz

各サービスで行っているような細かいQoSは統合網では厳しい

LSP単位＋interface単位でのtraffic管理




z

今後のサービスとExpを考慮するとExpの値が不足
 Queueのアサインも考慮が必要

外部ツールでinterfaceとそこを通過するLSPの合計を管理
Multicast trafficも合わせて管理
通常時にinterfaceのtrafficがあふれないように管理

今後はサービス単位で細かくトラフィックを管理/監視したい

効率的な設備投資に活用
サービス単位でのtraffic変動による異常検知

2008/10/28

サービス毎に異なるLSPを選択
xflow
KDDI Proprietary and Confidential12障害管理/作業管理z

それぞれの監視で障害を社内に同報各サービス/統合網とリンクがとれていない

各サービスは独自に監視しているため、同一障害でも断時間が異なる
z

サービス側で障害を検出できないケースも存在

作業管理

各サービスからは各々の作業を連絡

統合網側で他サービスへの影響を確認 → 必要あれば他サービスへ連絡

統合網作業は各サービスへ連絡

伝送側の作業は統合網側での影響が大きい

統合網側の負担2008/10/28

KDDI Proprietary and Confidential

13

課題z

いろいろと見直しが必要


LSPの見直し

物理トポロジーはシンプルでも中は複雑
 LSP間のload sharing
 Backup path

見直し間隔が短縮

2008/10/28(見直さないと次に進めない)

運用監視の見直し
サービス側との連携
伝送との連携KDDI Proprietary and Confidential

14LSPの見直しz

LSP間のload sharing

Linkの追加に伴いLSPが増大

Link aggregation/Bundle
RSVP signaling with bandwidth：：Backup path

Node downとなる障害の頻度はほとんどなし 機器単体の信頼性が向上

2008/10/28

Node protectionって本当に必要？
Link protectionだけの方がいいのでは？

KDDI Proprietary and Confidential

15

サービスとの連携
z

異なるサービス/運用をどうしていくか？


サービス単位の組織
サービス単位のOSS/NMS

serviceservicez

まずは人の連携から
z

境界を設け責任範囲を明確に相互理解も必要
ノードへのログインは双方可能

いざやってみると意外とできるが‥‥

サービスがもっと増えたら人だけでは限界
工数は増大(correlation関係が特に)

2008/10/28

人の連携でお互いの状況を確認

service

統合網service

作業/作業管理
障害管理等

KDDI Proprietary and Confidential

16

サービスとの連携(cont.)z

一元的な監視/管理の必要性


システム




オペレータ


service

2008/10/28

既存の連携
新規に構築
スキルアップが必要 網全体の理解が必要

統合網-システムでどこまで行うか-オペレータがどこまで行うか⇒整理が必要service

統合網

serviceservice

統合網

serviceservice

KDDI Proprietary and Confidential

17伝送との連携z

統合網の障害/作業による影響度が増大
IP/MPLSのレイヤーの考慮だけでは不十分


HA機能を駆使下位レイヤーも含めて考慮が必要異ルート/異システム
IPノード

IPノード

同じPOPではシステムを分けたい

伝送区間
2008/10/28

KDDI Proprietary and Confidential

複数の伝送路の場合は異ルートにしたい18

まとめまとめz

統合網の運用は大変

何かと連携が増える
オペレータのスキルアップが必須




z

現実的に統合網のみ/サービスのみと明確に区別できない
サービス側の理解(サービス概要,技術等)も必須

OPEXの抑制/削減とはなっていない

網統合には運用整理が必須


同系統のサービスで問題が少ないと思われる統合でも連携の課題が多い
システム/体制面の整理が必須

共通の意識を持つ


2008/10/28

後手にまわるとサービスに影響“何をいつまでにどのように統合する”と言った具体的なイメージ
 データプレーンの連携は割と共有してもらえる コントロールプレーン/マネージメントプレーンの連携は整理が必要

KDDI Proprietary and Confidential

20

ご清聴ありがとうございました

2008/10/28

KDDI Proprietary and Confidential

21