「BGP Over QUIC (BoQ)」という提案仕様が出ている。まだ、議論の呼び水の段階で、提案仕様の細かい部分はとりえる選択肢が書かれている部分もある。。
なお、僕自身はBGPについて詳しいわけではないが、ざっと目を通す。
QUICを使うメリット
RFC9000 で定義されるQUICはUDP上で動作するトランスポートプロトコルであり、TCP+TLSのような通信の信頼性と暗号化機能を提供します。
QUICを使うアプリケーションプロトコルとしては、すでにRFC間近になっているHTTP/3の他に、DNSやSSHなどででの利用が検討されています。
QUICをトランスポートプロトコルとして使うことで多くのメリットが得られます
- TCP + TLSに比べ早いコネクション確立 (TLS1.3と同等のハンドシェイクを行う)
- IPアドレスが変わってもコネクションが切れない
- 通信管理単位であるストリームを活用する。ストリーム毎の信頼性となっており、パケロス時に回復を待たずに、後続のパケットをアプリケーションで処理できるようになっている
- 再送制御の表現力の向上
- トランスポートプロコル領域も含む暗号化、アンプ攻撃対策、
- その他いろいろ
詳しくは、古いですが、以前書いた記事などを参照してください
BGP over QUIC
「BGP Over QUIC」も上記のメリットを享受できます。QUICを利用するために、仕様では以下のことを定義してます。
- QUICストリームにどうマッピングするか
- 1-RTTハンドシェイク及び、0-RTTハンドシェイク時の BGP FSM (ステートマシン)の定義
QUICストリームにどうマッピングするか
トランスポートレイヤのヘッドラインブロッキングを避けるために、QUICのストリームを利用する。
通信をどう、QUICの双方向ストリームにマッピングするかは以下の3つが案として挙げられている。
- アドレスファミリごと
- VRFsごと
- プレフィックス毎
BGP FSM関連
BGPのセッション確立プロセスはBGP FSMで定義されます。トランスポートレイヤでコネクションの確立をしたあとに、BGPセッションが確立されます。
(wikimedia: File:BGP FSM.svg より)
この仕様では、BoQ FSMとして新しく定義してます。
BoQ FSMでは、QUIC 1-RTTハンドシェイクではTCPのものを継承します。クライアントからアプリケーションを最初に送信する0-RTTハンドシェイク用のために、新しいイベントを定義を追加します。
0-RTTハンドシェイクでは、クライアントはQUIC InitialパケットともにBGP Open Dataメッセージを送信し、BGP OpenSent 状態になります。それを受け取ったサーバーは QUIC Handshakeパケットを送信後に、BGP Open を送信し、ステータスを BGP OpenConfirmedに変更します。その後、クライアントもBGP OpenConfirmedになります。
このようにBoQ FSMで0-RTTを利用すると、BGP Connect とBGP Active がスキップされます。
