3.1　経路監視技術

　先に述べたとおりIP-NWではBGPを用いてIPアドレス（経路）情報を交換することで接続性を確保している．これらの経路の安定運用がIP-NWの安定に直結している．例えばASでは経路情報を用いてどのボーダルータ経由で他ASと通信がされているかを監視し，一部のボーダルータに集中することによるパケット紛失等のサービスレベルの低下を回避している．

　また，BGP経路に関してIP-NWの安定を脅かす事象として経路ハイジャックがある．経路ハイジャックとは，BGPの設定ミス等により他ASの経路を不適切に流出してしまうことである．2008年2月に発生したあるISPが誤ってYouTubeの経路を広告し，世界の1/3のユーザが閲覧できなくなった事例が有名である．

　また，経路ハイジャックはNWを広範囲に機能不全に陥れるためその対策が重要となっており，その検知にはIRR（Internet Routing Repository）が重要な役割を果たしている．IRRはISPの経路広告に関するポリシーを登録・公開するためのデータベースで，経路を所有するAS情報が含まれている．BGPで広告された経路のAS番号とIRRの登録内容とに不整合があれば経路ハイジャックとして検出する．その際，広告された経路はどのように伝搬されているか広告元のASからは分からないため，経路ハイジャック検知にはAS外の複数拠点から面的に監視することが効果的である⁽⁶⁾．また，BGPの経路に電子証明書を付与することで，誤った経路情報の伝搬を防ぐRPKI（Resource Public Key Infrastructure）の取組みも進められている⁽⁷⁾．

3.2　フロー監視技術

　IP-NWでは様々なアプリケーションにより複数網を経由して通信が行われており，それらのサービスレベル維持のためトラヒック傾向を把握しておくことが不可欠である．しかし，SNMPによる収集では装置のポートごとのトラヒック収集しかできず，アプリケーション個々の傾向は把握できないため，ルータのNetFlow機能を活用して個々のフローを監視することが行われている．フロー情報には，IPアドレス，ポート番号，AS番号等が含まれており，アプリケーションごと，AS単位，対地別等のトラヒック流量を把握することができ，NWの帯域設計及びトラヒック制御等に活用されている⁽⁸⁾．

　フロー監視の別の活用法として，DDoS（Distributed Denial of Service）攻撃検出がある．DDoS攻撃は100Gbit/sに及ぶトラヒックになることもあり，攻撃対象だけでなくNW側にも深刻な影響を与える．DDoS攻撃ではDNS（Domain Name System）などのプロトコル特性や，TCP（Transmission Control Protocol）のセッション制御の仕組みを悪用しており，検出するためには正常な通信と区別して攻撃フローを検出する異常検出技術が必要となる．異常検出方式としては，攻撃特有の通信パターンを検出するシグネチャ検出と，通常のトラヒック傾向からのかい離度で検出するベースライン検出の二つを組み合わせて実施するのが一般的である．また，検出後の対処としては，エンドユーザでのIPS（Intrusion Prevention System）等のセキュリティアプライアンスによる対処，NW側でのブラックホールルーチングによるパケット廃棄，DDoS緩和装置へのう回ルーティングなどの対策が採られている．更には送信元にできる限り近いポイントでいち早く対処することが重要であることから，複数ネットワークで連携したフィルタリングを実現するDOTS（DDoS Open Threat Signaling）のような検討も行われている⁽⁹⁾．

4.1　大規模NWの状態の把握

　IP-NWの利用者増加及びサービスの多様化に応えるため，キャリヤなど各ASの設備においては，ルータ・スイッチ等の転送装置に加え各種サーバなどの制御装置が用いられ，構成が複雑になり規模の拡大も進んだ．それに伴い障害が発生した際の社会・経済活動への影響も大きくなりNW側にも高い品質が要求されている．品質の確保に向けた障害への対処においては，大規模・複雑なNWの構成情報と，警報やトラヒック等の多量・多種な現況情報を用いた複雑な分析が必要となる

　こうした作業を支援するアプローチとしてNWの可視化がある．これまでも地理情報へのNW装置マッピングや，プロトコル・装置種別での論理的配置手法が提案され用途に応じて用いられてきた．更に，三次元空間上にNW構成や警報などを集約して表示し，時系列再生することで，原因となる箇所や障害が波及する経緯を把握しやすくする手法が提案されている⁽¹⁰⁾．

4.2　サイレント故障検出

　オペレータの保守稼働を多く取るインシデントとしてサイレント故障がある．サイレント故障は，NW装置内のバグや設定ミス，内部プロセッサ部の故障等により，装置自身が警報を発することなくサービスレベルが低下する異常である．装置が警報を発しないため，オペレータがサイレント故障を発見・検知することは難しく，事象ごとに個別監視等の対応が取られてきた．NWの大規模化やサービス多様化に伴い，監視箇所が増加し，サイレント故障へのオペレータの対応負担が増大しているという課題がある．

　サイレント故障を検出する方法は，試験用トラヒックを用いるアクティブ検出と，装置のログ情報等を用いるパッシブ検出に大別される．後者では近年，いわゆるビッグデータの潮流ともあいまって，データに基づくサイレント障害検知手法の研究が多く見られる．例えば，ログをテンプレート化し大量のSyslogデータから障害を効率的に抽出する手法，Twitterでユーザのサービス体感品質に関するつぶやきを収集・分析し障害を検知する手法，大規模NWにおける装置間（またはインタフェース間等）のトラヒック量等が有する相関性の崩れを障害として検出する手法が提案されている⁽¹¹⁾．

4.3　インターネット構造解析

　インターネットが商用化された後，各キャリヤは利用者から得た接続料金を設備へ投資することでネットワークの増強を図り，その中で投資体力のあるキャリヤはインターネット全体に接続性を持つまでに成長した．そうしたキャリヤはTier-1と呼ばれ，インターネット全体への接続性を他のASに提供しトラヒックを転送する対価として接続料を得る構造となった．このような全世界に接続性を持つTier-1のASは10社程度になり，その下の階層にTier-2，Tier-3とされる中小規模のASがトリー状に接続するようにインターネットの構成は収れんされていった．2007年での上位10位までのトラヒック占有組織は全てTier-1のASであった．

　コンテンツ事業者も当初はこの階層構造に参加し配信していたが，動画像配信などコンテンツが肥大化するにつれてTier-1のASを経由することは非効率になり，できるだけ利用者の近くからコンテンツを流す必要が出てきた．Hyper Giantsと呼ばれる大手の配信事業者は無料の接続環境を提供し，中小のASはTier-1を経由することなく利用者にコンテンツにアクセスさせるようになってきている．2010年時点ではこのようなコンテンツ配信のトラヒックが全体の15%を占めており配信事業者の存在感が増してきている．

　このようなトラヒック構造の変化はASの設備設計にも大きな影響を及ぼしている．当初は，インターネット全体への接続性を確保することが最優先であったが，コンテンツ配信の比重が高くなり，配信事業者との接続性を考慮して設計することが重要となった．このため，コンテンツ配信のトラヒックを把握するために，DNSやHTTP応答における配信元サーバの指定状況などからCDN制御の挙動を解析する営みなどが行われている⁽¹²⁾．インターネットの構造の変化は，キャリヤのビジネスモデルに大きく影響するため，トラヒックの解析を通じて引き続き注視していく必要がある．

5.1　NW仮想化に向けたNW管理

　NFVとSDNはNW仮想化技術の中核であり，各種NW機能を仮想化して基盤となるハード上へ柔軟に配置するNFVと，NW装置をソフトウェア制御して仮想パスを動的に生成するSDNを用いることで迅速かつ柔軟にサービスを提供できると考えられている．

　キャリヤ網へのNW仮想化技術の導入を促進するために，NFVではETSI（European Tele communications Standards Institute）が中心となり，共通アーキテクチャや方式仕様についてキャリヤとベンダ^(用語)が共同で検討を行っている⁽¹⁴⁾. NW仮想化技術の導入により以下のような効果が期待されている．

・　汎用装置の活用による装置コストの削減

・　NW機能のソフトウェア化による市場ニーズへの迅速な対応や，サービス導入の容易化

・　仮想化によるサーバの自動復旧の実現など，NW管理コストの削減

　この検討内容を早期に具現化するため，OPNFVやOpen-O，OpensourceMANOなどの団体においてオープンソースでNFV管理基盤を実現する取組みが進められている．また，一部のキャリヤではNFVやSDNの実サービスへの導入が始まりつつある^(15),(16)．

　更に，NFVやSDNは第5世代移動通信システム（5G）のコアネットワークへの適用が検討されている．5Gでは物理NW上にスライスと呼ばれる論理NWを作成し，各スライスで自動運転などの低遅延を要するサービスや，高精細動画通信などの広帯域を要するサービスなどを提供することが検討されている．こうした帯域や遅延，及び許容停止時間などの要件はサービスごとに異なることも想定される．こうした要件に対応すべく，スライスへの物理リソースの適切な割当や，サービス品質の管理，及び障害検出・解析・対処の迅速化といった課題に取り組んでいく必要がある．

5.2　IoT/M2Mへの対応

　IP-NWを活用した今後の主要なアプリケーションの一つとして，IoT（Internet of Things）・M2M（Machine-to-Machine）が挙げられる．IoT/M2Mにおいては，大量の異種デバイスから得られる膨大なデータを機械学習を含む様々なアプリケーションに提供することで，高度なデータ分析やデバイス制御など多様なサービスが提供できると期待されている．

　現状のIoT/M2Mサービスは，静的に配置された各種センサや既設デバイスを利活用した個別ソリューションとして，実世界の状況把握や課題分析の支援を実現している．しかし，将来的には，交通では車や街路，製造・流通では部品や製造機械・製品など時々刻々とデバイスやNWの接続構成が変化する状況において，多様なデバイスから得られるデータを活用するとともに異なるシステムを複合してサービスの高度化を図る必要がある⁽¹⁷⁾．また，自動運転のように低遅延のリアルタイム性を要求するアプリケーションも提供されると想定される．したがって，IoT/M2Mサービスを一貫性をもって継続的に提供するためには，アプリケーションから透過的にデバイスやNWにアクセス可能とし，NW層からアプリケーション層までを一気通貫したデバイス管理や通信管理が必要になると考えられる．すなわち，以下のような要件に対応した基盤技術の実現が重要であると考えられる．

①　アプリケーションからNWやデバイス・データを統一的に管理し，相互利用を可能とするインタフェース・機能群の実現

②　アプリケーションの機能群をNW上に適切に配置することによって，低遅延でのサービス提供を実現するインフラ機能の提供

　①の要件に対応した取組みとしてoneM2M⁽¹⁸⁾があり，CSE（Common Service Entity）と呼ばれる共通的な機能群を具備したミドルウェアの機能要件を定義することで，様々なIoT/M2Mサービスから多様なデバイスを共通化して利用可能とすることが目指されている．デバイス管理モデルとしては，既存のOMA（Open Mobile Alliance）で規定されるDM（Device Management）や，BBF（Broadband Forum）で規定されるTF-069などを援用することで早期の仕様化が図られている．また，データ管理に対してはセマンティクスの取組みが進められており，データの多様さを吸収したデータの利活用が検討されている．

　②の要件に対しては，エッジコンピューティング技術への取組みがあり，ETSI MEC⁽¹⁹⁾において標準化が進められている．V2X（Vehicle-to-everything）通信のような処理の地域性を生かした低遅延性が求められるアプリケーションをユースケースとして，エッジサーバにおける技術要件やアーキテクチャを明確化し，プラットホーム仕様やAPI仕様の標準化が進められている．

　このように，IoT/M2Mサービスの提供に向けたミドルウェアやインフラの標準化が進められているが，NW層からアプリケーション層までの統合的な管理を実現するためには，これらIoT/M2Mにおける標準化の取組みと，本稿で述べたIP-NWにおける管理の取組みを融合した技術の実現が重要になると考えられる．

5.3　B2B2Xへの対応

　従来からキャリヤは，NWによりつながることをサービスとして提供してきた．現在では，NWはクラウドやアプリケーション，デバイスなどと組み合わせて使われる時代となり，キャリヤのみでエンドユーザの多様な要求に応えることが難しくなっている．そのためこれまでと違い，製造業や，交通，農業，ヘルスケア，自治体など多様な業種と協業して，新たな価値を加えてサービス提供をすることが期待されており，そうした他の業種と協力してサービスを提供するB2B2Xモデルが指向され始めている．

　B2B2Xモデルでは，サーバ，アプリケーション，ネットワーク，デバイスといったFirstBのリソースを組み合わせて，MiddleBの事業者がサービスを提供する．このB2B2Xモデルの実現に向けて，TMForum（Tele Management Forum）では，DSRA（Digital Service Reference Architecture）の検討が進められている．DSRAには，プラットホームのアーキテクチャや，サービス実現に必要な利用者の認証や課金，設定，サービス状態管理等の機能・API群，及びFirstBの組合せであるカタログの概念が含まれている．こうしたモデルの推進においては，B2B2Xサービスごとの課金や保守等の要件の違いに関する管理基盤側での柔軟な対応や，複数FirstBを一気通貫した故障管理・性能管理などの実現が重要になる．