要約

  • 10月28日付の個人草案は、順序付きのIPFIXテンプレートで繰り返し使う五つの汎用MPLS情報要素を提案する。位置KのIPv4/IPv6次ホップアドレスやプレフィックス長が得られなければ、送信側は同じ属性についてK以降の深い位置も送ってはならない。空きを飛ばせば、収集側はK+1をKと読み違える。
  • 既存の位置別フィールドは残る。仕組みは別の順序保証草案に依存し、未対応の収集側は新しい集合を丸ごと黙って捨てる可能性がある。新しい五項目のIANA番号はなおTBDだ。

欠けたのはラベルではなく、その属性

測定プロセスが三段のラベルを見たとする。第一段と第三段の次ホップアドレスは分かるが、第二段だけ分からない。送信側が二つのアドレスを詰めて送れば、収集側は二回目の値を第二段へ貼る。第三段のアドレスが第二段の名札を付ける。値のバイト列が正しくても、値が示す層は間違う。

新草案の第4.7節は、mplsLabelIPv4Address、mplsLabelIPv6Address、mplsLabelPrefixLengthに連続した出力だけを認める。位置Kで値が使えないなら、Kとそれより深い位置の同じ情報要素を出してはならない。三段目のラベルそのものが消えるわけではない。他の属性は正しく記録できるかもしれない。しかし切れた属性は、三段目を含めてその先の位置を語れない。まばらな位置だけを選んで出す方式は、草案の対象外である。

ラベル種別には別の答えがある。mplsLabelTypeがある段で不明なら、値0、Unknownを置く。段の場所は保ち、種別についてだけ分からないと明示する。アドレスとプレフィックス長には、この草案で同じ代替値が用意されていない。そこで系列を止める。「種別が不明」と「この属性はここから先を位置づけられない」を一緒にすれば、運用者に必要な差が消える。

この面倒な規則には歴史がある。IANAのIPFIX登録簿には、MPLSラベルスタック用の位置別フィールドIE 70から79までが載る。上段、二段目、三段目と別の名前を増やして十段目まで作った。新草案はmplsLabelStackEntryを順序付きの記録で繰り返し、四つの汎用属性も必要に応じて繰り返す。旧フィールドは廃止しない。新しい順序を読めない収集側には、なお旧来の語彙が要る。

サイズも変わる。RFC 3032のラベルスタック項は四オクテットで、ラベル値、トラフィッククラス、最下段を示すビット、TTLを含む。既存の位置別スタックフィールドは三オクテットでTTLを省く。提案する汎用項は四つ全てを運ぶため、深い段のTTLも見えるが、TTLが不要な運用ではラベル一枚ごとに一オクテット増える。観測できる項目と転送量は同じ勘定にはならない。

並び順は三つの工程で守る

RFC 7011はテンプレート内で同じ情報要素を繰り返せるようにしている。ただし通常のテンプレートの並びから、観測順の保証を読み取ることはできない。順序保証の関連草案は、測定プロセスが観測順に記録し、送信プロセスがその順を保って合図し、収集プロセスがn回目をn番目の観測と読む仕組みを提案する。表の列を並べ替えるだけでは、この三者の約束は成立しない。

保証は情報要素ごとに独立する。二回目のmplsLabelStackEntryと二回目のmplsLabelTypeが同じ二段目を記すのは、両フィールドの定義がそれぞれ二回目を二段目へ結びつけるからだ。別種類のフィールド同士が報文上で並ぶ相対順序までは保証されない。隣り合っているから関係がある、と収集側が勝手に補えば、また一つ偽の層ができる。

移行時には受け手の能力が問われる。第7節は、順序付き集合を理解できると分かっている収集側にだけ新しい出力を有効にするよう求める。未対応の収集側は集合全体を黙って失い得る。旧位置別フィールドと新汎用フィールドをしばらく併用する理由がここにある。送信側だけ賢くしても、受信側が聞き取れなければ記録はむしろ減る。

Datatrackerでは、この文書は活発な個人Internet-Draftである。五つの情報要素番号はIANAへの要求表でTBDのままだ。中段の属性を意図的に欠かせた送信側と収集側の試験記録があれば、実際のテンプレートと再構成した段番号を照合できる。

出典