英語が苦手でもグローバル人材を目指して

これまでNFVをベースとした仮想化の説明をしてきたが、肝心のVNFについて説明していなかったことに気づいた。今日はそもそも”VNFとは何か？“について解説してみる。 Network Functionを仮想化した“VNF“ 『 電気通信のつながるしくみと設備構成 』(NTT東日本)や『 結局モバイルNWのお仕事って何？ 』の通り、テレコムやモバイルのNWは加入者設備・加入者線(・基地局)・伝送路・交換機によって構成されており、これらの設備(のいくつか)をNetwork Functionと呼んでいる。 VNF (Virtual Network Function)とは、このNetwork Functionを仮想化したものであり、主にVM型とコンテナ型がある。ETSI-NFVの仕様としては特定のタイプのNetwork Functionに限定している訳ではないが、NFVは元々 aTCA の有力な後継機として始まったこともあり、暗黙的にモバイルコア(交換機)を最初のターゲットして検討している。 上記図の通り、aTCAとNFVの関係をまとめると、概ね1 Chassisが1VNFインスタンスであり、1 Baldeが1VNFC (VNF component)となっている。もちろん、APLの性質によっては1VNF = 1VNFCとして設計することも可能である。 components aTCA NFV blade APL APL APL MW MW MW OS CGL Guest OS HW aTCA VM NW segment VLAN + L2SW Virtual Link (VL) port port Connection Point (CP) + Top Of Rack (TOR) HW manager HW OAM Charssis manager VIM HW control Charssis manager N/A ...

  今回のNFV#36(12/1〜10)もコロナの影響でeMeeting (電話会議)となった。今回はNFV-Workshopのようなイベントは無かったようだが、いくつかの仕様検討は大きく進んだ。 最新のNFV仕様の全体像は こちら (ETSI-NFVのOpen area)で、前回NFV会合の説明や現在のNFVのリリース機能の状況は NFV中間会合(10月)サマリ を確認して頂きたい。 NFV#36のサマリ NFV#35やNFV中間会合(10月)と比較した重要な活動結果としては、 Release3のed361がFinalize Review (12月Finalize/1月Publish)となりFEAT03(NFVI Upgrade)がサポートされるようになる。 Release4のNormative WIとしてPaaS (特にOAM系)、MDA(Machine Learning)、Intent mgmtが提案された。 Release5のNew Work ItemのVNF Configuration、NFV for vRAN、Fault ModelのUsecaseが概ねで揃ってきた。 会合参加者の目線からすると、開発で注目されている技術や各標準化団体の境界案件のような重要な案件の進捗はeMeetingが続いたことでどんどん遅くなってきている。ロビー活動ができないことで、様々な他社案件に対して疑心暗鬼になったり警戒してしまったりして、協力し合うという空気感が薄くなってきているように感じる。また、もう一つ大きな問題として、ETSI-NFVの認知度向上やベンダを含めた製品化を牽引してきたような重要メンバーが高齢化し引退を始めている。これまでにNSDやVLのInformation Modelの設計を牽引したHPEのMarc氏、ETSI-NFVのアピールに貢献したCable LabのDon氏が引退し、そして今回ETSI-NFV NOCの重要メンバーでありZSMのChairも務めたKlaus氏が引退を表明した。今後年齢的にETSI-ISG ChiarのBruno氏、NOC ChairのDiego氏も引退話が出始めるかもしれない。 Release3：LCMの高度化 IFA&SOLの第3版(ed361)のCRが全て承認されFinal Reviewになった。 FEAT03...

3GPP、ETSI-NFV、O-RANと様々な団体で証明書に関する議論が起き始めている。何故今証明書が重要なのかを、テレコムの進化や運用や観点から考えてみたい。 識別子としての証明書 「 時代を映すインフラ 」(国立情報学研究所)や「 知識の森 第5群4編ノード技術 」(IEICE)の通り、元々テレコムにおいては、端末〜端末間をPoint to Pointの専用線で繋ぐ思想だった。その識別子がチャネル/VCI→IPと変わってきただけで、根本的なNWトポロジー(構成や機能分担)はあまり大きく変わっていない。 テレコムの運用においては、この交換機等のNW設備の“箱“を専用線で繋げる発想であったため、NW設計も保守運用の考え方も、この箱と専用線単位となっている。「 テレコムアプリの実装の特徴と監視方法②〜EM編〜 」にも記載している通り、EMは各設備のFCAPSを装置単位に管理している。通信方式がIPになったとしてもこの考え方は大きくは変わっておらず、IPアドレスで設備を識別・管理し、VLANで専用線を管理している。 5GC以降、「 REST指向での標準仕様設計方法 」の通りSBAやRESTと言ったよりダイナミックでフレキシブルなプロトコルを利用されるようになり、ここで装置の識別子が装置から証明書に変わってきた。 5Gにおいては、Serviceベースでの仕様となりNF(Network Function)の構成やNWの接続先をDynamicに変更しやすくなった。その結果、従来のようなIPアドレスによる装置単位の監視保守は維持できず、リソースを管理するResource Manager (5GCではNRF)が動的に増減・変更されるNFを管理するようになった。これにより、監視方法もトラヒック管理方法も変わってきている。また、IPアドレスで装置を管理することが困難になり新たな識別子の管理方法として 証明書 が利用されるようになった。 証明書の利用方法 3GPP TS 33.501 や ETSI GS NFV-SOL 013 の通り、SBAにおいてはmutual TLS (mTLS)による認証＆セキュア通信と、OAuthによる認可が通信のベースになっている。この時、各NFを識別しているのは”証明書”となる。SEの道標というサイトにおいて、mTLSとOAuthによる認可認証の仕組みは ...