In-Situ OAMと既存プロトコルの関係

前回見たIOAMのデータ構造は様々なプロトコルの埋め込みが検討されている。 RFC9378の5章に記載があるのが以下のプロトコルである。

IPv6とNSHはStandard RFCで、それ以外は今のところ個人ドラフトである。

IPv6は既にLinuxに実装されている。以下のリンクが参考になる。IOAMの強みは実装が既にあることである。

RFC9259がある中でSRv6がExpireしているのが意外であるが、RFC9486のIPv6のIOAMを併用すればSRv6環境でも使えるだろうし、そもそもuSID(Compress SID)でSRHを使わない環境が多くなっていくとするとSRHで実現する必要性も薄い。(議論の経過は追いかけていないので勝手な推測である。) VXLAN-GPEのDraftも、03は2020/5/7にExpireしており、04が2023/11/26に作成されているところを見ると、他のプロトコルも突然更新がされる可能性もある。

GENEVEもExpireしているのでVXLAN-GPE用のIOAMを調査してみる。なおVXLAN-GPEは(NVO3の標準はあくまでGeneveであるため)Informational Trackで進んでいるのにもかかわらず、VXLAN-GPE用のIOAM個人ドラフトはStandard Trackで進んでいる。

VXLAN-GPEのIOAMのOSS実装はVPPで行われている。 https://github.com/FDio/vpp/blob/master/src/plugins/ioam/lib-vxlan-gpe/

VXLAN-GPE用のIOAMヘッダ構造はVXLAN-GPEヘッダも含めて記載では以下の通りになる。 VXLAN-GPEヘッダのNext PotocolはIOAMを示す0x81(提案ドラフトの提案値)で、RFC9305(LISP-GPE)に対する提案値と同一である。

IOAMのヘッダ構造構造(IOAM-Type, IOAM HDR len, Reserved, Next Protocolの並び順)は、NSH用のIOAM(RFC9452)と同一になっている。

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    Outer Ethernet Header                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Outer IP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Outer UDP Header                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
|R|R|Ver|I|P|R|O|          Reserved             |  NP=TBD_IOAM  |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ GPE
|     Virtual Network Identifier (VNI)          | Reserved      |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
| IOAM-Type     | IOAM HDR len  |    Reserved   | Next Protocol |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  I
!                                                               |  O
!                                                               |  A
~                 IOAM Option and Data Space                    ~  M
|                                                               |  |
|                                                               |  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<-+
|                                                               |
|                                                               |
|                     Payload + Padding (L2/L3/ESP/...)         |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

各フィールドの意味は以下である。

フィールド 意味
IOAM-Type RFC9197 Section 7.2のTrace Type
IOAM HDR len 8bit符号なし整数。4Octet単位。最初の4Octetを含まない(つまりIOAM Option and Data Spaceの長さと解釈できる)。
Next Protocol 8bit符号なし整数。GPEのNext Protocol

VXLAN-GPEのO bitはOAM bitだが、VXLAN-GPE用のIOAMのドラフトによると、IOAMをユーザパケットに付与した場合はO bitは設定しない(=0にする)。IOAMデータのみのパケットにはO bitは設定する(=1にする)規定となっている。

中継(トランジット)デバイスで、IOAMのデータを変更してはいけないケースは、インターネットなどに展開されて、ドメイン全体でVXLAN-GPEのUDPポート番号である4790が同一の意味を持たない場合のみ記載されている。(それ以外の場合は記載がないため変更してもよいと解釈できそうである。)

さて、ここまでRFCやDraftを調べて書いてきたが、 http://events17.linuxfoundation.org/sites/events/files/slides/In-band_OAM.pdf を資料として発見した。これを読むとIOAM大体わかる感じである。