要約

  • BACPは同時要求の競合を解き、BAPは行動前の応答を必須にした。その後のCall-Statusが、実際の発呼の成否と再試行予定を報告した。
  • Request-Ackは有効な命令の受領であり、linkやpayloadの成功ではない。ISDN TAによるinterceptのため、BAP datagram全体は圧縮も暗号化もできなかった。

RFC 2125の設計は、混雑を測るところからではなく、両端が同時に正反対または同じ操作を始める場面から読むと分かりやすい。二つのpeerが同時に回線を増減しようとすれば、局所的な最適化は競合になる。

RFC 1990は複数PPP linkを一つのMultilink bundleとして再構成する規則を定めた。RFC 2125はmember数を制御するBACP/BAPを別に定めた。RFC Editorの記録とIANA PPP registryは、その標準上の位置と割当値を残している。

Favored-Peerは勝者を一時的に決める

必須optionのFavored-Peerでは、双方が非ゼロの4-octet Magic-Numberを提示する。同種の要求が同時に出たとき、小さい値を送った側が優先される。同値なら別の値で再交渉する。

ここで決まるのはraceの順序だけである。相手のidentity、運用上の正当性、回線の所有、測定algorithmの品質は証明されない。

Ackの後に、まだ発呼が残る

自分が発呼する前にはCall-Request、相手に発呼してほしいときにはCallback-Requestを送る。すべてのRequestとIndicationは、actionより先にResponseを必要とした。Request-Ackはvalidかつreceived、Request-Nakは今は拒否、Request-Rejは未対応、Request-Full-Nakはbundleの上限または下限を示した。

発呼を実行した側は、その都度Call-Status-Indicationを送る。失敗時にはretryの有無も示し、retryしたなら次の結果を再び報告する。最初の要求と同じIdentifierを使うので、許可と結果は結びつく。しかし別packetである以上、同じ事実ではない。

証拠は段階を持つ。BACP Open、Favored-Peerのrace解決、Request-Ack、Call-Status、LCPによるmember確立・終了、新member上のMultilink fragment、applicationの完了である。前段は後段を自動的に証明しない。

利用率と物理資源は同じ理由ではない

利用率を理由にlinkを落とす場合、Link-Drop-Queryで相手の同意を求める。受信側は自身のmonitoringに基づいて答え、受信trafficだけを根拠にしてはならない。どちらかの監視側が必要と判断する間はlinkが残る。

一方、portやB-channelを別用途に戻すというlocal resource conditionでは、LCP Terminate-Requestを直接送る。Queryへの応答が再試行上限まで得られない場合も強制終了が回復策になり得た。協調的な効率判断と資源のlocal custodyは意図的に非対称だった。

Requestの再送は同じIdentifierを使う。response lossによる重複を新規操作と区別するためである。帯域不足時こそ制御が必要なので、BAP packetには通常dataより高い送信優先度が推奨された。

可視性を選んだ互換性

Multilinkを理解しないclientの前でISDN terminal adapterが制御する構成があった。そのadapterがBAPをinterceptできるよう、datagram全体は圧縮も暗号化も禁止された。PPPの一部field compressionは交渉済みなら使える。しかもSecurity Considerationsは、security issuesを論じないとだけ記した。

したがってBACP Open、Ack、成功Call-Statusから、機密性、認証された権限、利用者同意、安定した総帯域、payload deliveryを導くことはできない。

Lu HengのRunning-Code Primacy、Minimum Initial Specification、Reality Layersは、ここでは明示した現代的な分析軸である。共通仕様を薄く保ち、local heuristicをlocalに残し、symbolic permissionをexecuted outcomeとして扱わないという読み方だ。

出典