2023-07-05-7 JANOG52 参加レポート
JANOG52 Meeting in Nagasaki に参加しました。
ほとんど個人用のメモですが、以下の用途に参考になるかもしれません。
- 発表を聞いたけど、用語が多くてよく分からなかった -> 用語のディティールを知りたい・調査するとっかかりがほしい
Day1
ケーブル敷設船きずな見学会
海底ケーブルを敷設・保守する、NTT-WEM (ワールド エンジニアリング マリン) の運用する船、きずなを見学させてもらいました。
船の所有について
2017 年 3 月 31 日 に竣工し、NTT ファイナンスが保有して、NTT-WE にリースで貸し出しています。
船舶や飛行機では投資家などから資金を募って、購入資金を集めるファイナンスが一般的ですが、本船はどのようなオーナーがいるのか気になりますね。
今回船内の写真は撮影禁止なため、Web で見つかった記事のリンクを記載します。
海底ケーブル
多芯ファイバー・電力線・外皮を備えたものを海底ケーブルに使用します。
距離が遠い場合はリピータを使用し、光を増幅して中継します。
リピータは電力を消費するため、電力線はここで使用されます。
電圧が 10,000-15,000V 程度と高く、電流は少なくて良いそうです。
海底ケーブル自体の所有は海底ケーブルの運用会社となっており、NTT-WEM では所有していない扱いになっているそうです。
保守
保守契約を結んだ海底ケーブルの運用企業から障害連絡を受けると、
- 関係省庁へ手続き
- 食料・水・燃料などの確保
- 保守対象のケーブルを積載
などの準備を行い、海底ケーブルの交換を行うとのことです。
ケーブルは敷設時期・保有/運用企業により異なるため、保守ではケーブルを搭載しておらず、出港時に交換対象のケーブルを積み込みます。
数は少ないようですが、光ファイバ以外に同軸の海底ケーブルも存在するとのこと。
災害対応
大規模災害時、
- 資機材・燃料
- DoCoMo の船上基地局
- 会議室・医務室・宿泊施設
などを被災地域に提供できるとのこと。
実際の活動例としては、北海道胆振東部地震があり、今後は首都圏直下型地震や南海トラフ巨大地震などを想定して備えているそうです。
推進装置
主推進機は微出力の調整に優れる電気駆動を採用しており、船首のスラスターで左右移動、船尾に 360 ℃回転可能なスクリューを駆動し、微細な機動を行えるようになっています。
ディーゼルエンジンなどの内燃機関は、出力の微調整が難しく、狙った緯度・経度に停泊したいケーブル船の推進機には向いていないとのこと。
ややこしいですが、内燃機関を搭載しないわけではなく、ダイハツ ディーゼル 6DCM-32e 3,500ps x4 基を搭載して発電を行い、スラスターを電気駆動します。車でいうとホンダ アコード ハイブリッドやノート e-Power などのシリーズ ハイブリッドが近い方式だと言えます。
- エンジンで発電
- 電気推進機を駆動
- プロペラを回転
一般的な船尾の舵は、推進時に向きを変化させる (推進しないと転舵できない) ものであるため、搭載されていません。
DPS (Dynamic Positioning System)
風・潮流などの影響を計算して GPS の位置情報を補正し、推進機と連動して特定の位置に船を保持できるシステム。
リアルタイムでズレを測定し、その他の外乱要因も補正できるそうです。
ROV (Remote Operated Vehicle) CaRBIS- Ⅳ
海底の確認やケーブルの切断・引き上げを行う、200 馬力の無人潜水機のこと。
船上の建物であるコントロール ルームから、液晶 9 画面とコンソールで操作します。
ケーブル クリッパーは 27 トンのケーブル引き上げ能力を持ち、これはケーブル エンジンと同じ能力になっています。
またウォーター ジェットで海底の砂を巻き上げて、ケーブルを埋設させる装備なども備えています。
他には金属探知機・マニピュレータ・カメラ・磁気センサーなどがあります。
海底ケーブルの障害原因
近海では漁で碇を下ろす・網に引っかかって誤って切断してしまう、浅海では地震・台風・潮流でケーブルがこすられて破損、といった原因があるそうです。
深海では潮流の影響が少ないため、逆に細いケーブルを使用してコストを下げられたりするとのこと。
深海探査機などでは深海のほうが水圧でコストがかかるため、これは意外でした。
航海期間
大体 40 日程度のミッションを行えるような資材を搭載できるそうです。
ケーブルタンク
2,500km のケーブルを収容でき、4 回で日米間 10,000km のケーブルを敷設できるようなスケールとなっています。
実際には米国側のケーブルは米国側から敷設・メンテナンスを行うほうが効率的なため、数分の一 + 余長程度のキャパシティがあれば問題ないようです。また、きずなは保守がメインの船であるため、キャパシティは低めと思われます。
ケーブルの積載はまだ自動化できていない分野で、どうしてもねじりなどでキレイに巻けないため、手動で巻いています。
光のリピータは組み込まれた状態でケーブル タンクに搭載されるため、敷設時はリニア ケーブル エンジンなどで巻き込み事故が起こらないように低速化して作業するそうです。スキー場のリフトのように、乗り込むときだけ低速化されるのに近いですね。
ドラム ケーブル エンジン
直径 2.7m の金属ドラムを使ったケーブル巻き上げ機です。ケーブルの敷設は海底の高さを考慮して行う必要があるため、送り出す速度を変化させて対応します。
巻き上げ時は横幅に対して均等に巻き上げ・敷設するため、2 つのフリーティングナイフライニングで均等になるように巻き付けます。
障害切り分け
リピータがある場合はどのリピータ間で障害が起きているか、リモートで電力を流してもらい流れた電流を ROV で確認するなどの手法を用いて、障害箇所を切り分け・特定していくとのこと。
リピータは 40-100km 程度の間隔で 1 つ設置されるパターンが多いそうで、切り分けは大変だと思います。
ケーブル交換
ケーブルは ROV のケーブル カッターで障害箇所を切断し、ケーブル クリッパーで引き上げて、新ケーブルで障害区間を除いて接続します。
交換は大体以下の手順となるようです。KDDI のオーシャンリンクの場合は以下。
- 障害ポイントの左右どちらかを切断
- 障害ポイントを特定
- 正常な部分 #1 のみの片側はブイをつけていったん沈めてしまう
- 船上に引き上げて、障害箇所を含むようにもう一箇所を切断し、異常な部分を含むケーブルを分離
- 新規ケーブルを正常な部分 #2 と接続
- 新規ケーブルと正常な部分 #1 と接続
Day2
モバイルコアネットワークのパブリッククラウド搭載に向けた取り組みとその課題 ～ちょっと気になったので5GCをAWSに載せてみた～
5GC の設備をオンプレミスから自社仮想基盤・AWS の両方にプロビジョニングできるようにする
- 自社仮想基盤で動作 -> 障害時にコールド スタンバイの AWS にプロビ
- AWS 利用料が削減できる
AWS Graviton2 CPU に移行して省電力化
ShowNet でキャリア 5G と ローカル 5G の使い分けを実験
- Qmonus で加入者情報・スライスを統合制御
- ネットワーク スライスを高速と通常に分けて、スループットを高速 / 低速制御
SRv6による社内検証網の提供と、SR-MPLS/SRv6双方を運用してみてわかったこと
SRv6 は個人的にメリットがあまり理解できてない分野です。
技術的に SID を付与することで送信元情報をベースにルーティングできる (一般的には宛先ベース) のはわかるのですが、現実にどのようなメリット・ユースケースがあるのでしょうか ?
Segment Routing
送信元ノードで指定した SID をパケットに埋め込むことで、送信元に応じてルーティングを経路制御できる経路技術
SRv6 MUP (Mobile User Plane)
2023/02 ソフトバンクでフィールドトライアルを開始。
SRv6 SID IPv4 射影アドレス
行き : ノード#1 の送信元アドレスは SR ヘッダの中に埋め込まれる
戻り : 送信元アドレスは宛先ノード#2 が埋め込んでくるため、SR ヘッダの v6 アドレスに射影アドレスとしてエンコードされる
Flex-Algo
アンダーレイ上に複数のトポロジを生成
遅延を Metric にすることも可能
キャリアバックボーンネットワークへのホワイトボックスルータ商用化に向けた取り組み
事例の URL に対して、某ルータ メーカーからのアクセスがかなりあったとのこと。
ホワイトボックス ルータの導入は、世界で AT&T が一番で、KDDI が 2 例目。日本では最初の事例となる。
筆者の所感としては、非常に強力なコンセプトなため、今後採用例が増えていくと思います。
後述のクラスタ型アーキテクチャは、マーチャント シリコン採用シャーシ型スイッチを複数のボックス スイッチにバラしたものになると思いますが、シャーシ型よりも柔軟性に優れるメリットがあると考えられます。
課題としては、
- キャリア自身の責任範囲が増えるため、技術力が必要とされる
- ハードウェアとソフトウェア間でトラブルが発生したとき、調査・切り分けが困難
- キャリア自身がハードウェアとソフトウェアで切り分けを行い、各メーカーへエスカレーションを行う必要がある
- 例) ハードウェアは DELTA -> Broadcom , ソフトウェアは SONiC コミュニティ
- キャリア自身でもコードを書く覚悟が必要かも
などがあると思います。
Open ROADM
光伝送で波長を Add / Drop できる ROADM を、オープン アーキテクチャのハードウェアとソフトウェアで実装するコンセプト。
今までのルータ
ピアリングルータ・コアルータ・エッジルータで別々の機種が必要になる。
コアルータのアップグレードは、ルーティング エンジン・ラインカード・ファブリックを全取っ替えになってしまい、シャーシしか共通して使えるコンポーネントがなかった。
Telecom Infra Project (TIP)
ホワイトボックス ルータを標準化する団体。800 社以上が参加し、日本からもモバイル キャリアなどから参加している。
Disaggregated Open Routers (DOR)
KDDI , Vodafone が議長となって牽引、欧米の主要 8 者が集結した団体。
TIP ガバナンス モデル
従来はキャリアが個別に行っていた検証について、キャリア間で検証結果を共有する。
各国空軍の戦闘機開発のように、個別開発から共同開発になるコンセプトと近い。
TIP DOR の活動内容
技術仕様策定・製品開発・検証・商用化し、世界に浸透・普及。
共通化してハードウェアとソフトウェアを各セグメントにルータを展開することで、スケール メリットを得る。
オープンルータの適用範囲
Cell Site Gateway
Open BNG
Aggregation Router
Edge Router
Core Router
ルータアーキテクチャの比較
シャーシ型
- 従来のルータ メーカーのルータ
クロス ファブリック型
- DC の IP Clos
- 機器は個別管理
- QoS , Deep Buffer , Large TCAM なし
クラスタ型
- 複数の物理ルータを、1 つの論理ルータとして扱うアーキテクチャ
- コントロール プレーンは、物理ルータとは別のサーバ上に展開され、複数の物理ルータをデータプレーンとして動作する
- パケットはセル化されて転送される、ファブリックと同様の動作を行う
- ファブリック ホワイトボックスとパケット フォワーダー ホワイト ボックス
- コントロール プレーンとデータ プレーンが分離
- データ プレーンは後方互換性を持つ
- Spine-Leaf 間のトランシーバ台が安い
- QoS , Deep Buffer , Large TCAM あり
DDBR の優位性
1 つのアーキテクチャで検証・運用ナレッジ・予備品を共通化。
スケールアップ・スケールアウトが容易。
DDBR SW の機能
シンプルに保つのをポリシーに。
DDBR の実装
HW/SW で複数ベンダがサポート。サポートベンダには TIP 認定バッジを授与。
機器の見える化・運用の自動化が容易なアーキテクチャ。
DDBR 導入のユースケース
コア・エッジ・ピアリング ルータ。
シンプルなソフトウェア機能・パケットフォワード機能。
アクセス ネットワークよりも、バックボーン ネットワークのほうが適している。
- アクセス層ではユーザ側の要件に柔軟に対応するために、必要とされる機能が多い
KDDI の DDBR 商用化について
ピアリング ルータ、スタンドアローンでの適用、すでにインターネットのトラフィックをさばいており、商用化できている。
キャリアバックボーンからIP Clos Fabricへの移行による5GSAネットワークの進化
コア設備を 5G 専用で動作させる、5GSA を IP Clos ファブリックで設計・構築した事例の発表でした。
5G / BGP-EVPN / CGN / FW とキャリア NW の良いまとめになっていると思いました。
CGN - Full Cone NAT
- EIM (Endpoint Independent Mapping) : 同一の送信元 IP は同一グローバル IP に変換
- EIF (Endpoint Indedependent Filtering) : EIM で通信済みの IP に対して、不特定多数の IP からの通信を許可
EIM かつ EIF であるとき、Full Cone NAT となる。
EVPNマルチホーミングと RFC8584のお話
EVPN マルチホーミング タイプ 4 Ethernet Segment Route
PE 間のリンクを持たないことで、MLAG に頼らずに L2 冗長化を実現する。
まとめ
ルーティングで負荷分散を行うため、
- PE のノード数が 2 台よりも多くできる
- 遠隔冗長できる
- 異バージョン冗長が組める
- プロトコルの挙動はバージョンごとに異なるため、不具合となる場合も想定される
- 密結合よりは相当マシ
- 異機種冗長が組める
- 異メーカー冗長も可能
Vlan Aware Bundle のバッドプラクティス - SB 川上さんの質問
Vlan allowed を冗長の片系のみ若番を追加 or 削除すると、DF の選出が正常に行われなくなり、片側で BUM が全く転送されなくなるといった障害が発生します。
使用しない Vlan1 を追加しておく回避策や、RFC8584 でこの挙動に対する改善が行われるといった対策があります。