RFC 3108：forwardが両側を指したとき

要約

RFC 3108のSDPでは、記述対象のATM nodeから離れる向きがforwardだった。bearer signalingでは、setupを開始した端点から受信側へ向かう流れがforwardだった。backward setupでは、同じparameterが層をまたぐと逆の名になる。
4 byteのeecidは、service-level callと後着のbearer requestを一対一で相関した。これはnode内のjoin keyであり、利用者のidentityでも、globalなconnection名でも、media成功の証明でもない。

同じ回線に二つの原点があった

あるgatewayから外へ出るtrafficをforwardと呼ぶ。別のprotocolは、bearer setupを送った装置から出るtrafficをforwardと呼ぶ。callを始めた側とbearerを始めた側が一致している間、二つの矢印は重なって見える。役割が入れ替わると、同じ線上で矢印が反対を向く。

2001年5月にStandards Trackとして公開されたRFC 3108は、RFC 2327のSDP syntaxをATM/AAL2 bearer connectionへ拡張した。address、adaptation layer、traffic descriptor、QoS、bearer type、channel、service selectionのためのattributeを定義し、SIP、MGCP、Megaco/H.248などのcontrol exchangeで使えるようにした。

しかし本質はattributeの数ではなく、service-level call controlとbearer setupが独立していたことにある。音声やmultimedia callを開始したgatewayが、必ずATM SVCも開始するとは限らない。

RFC 3108のSDP conventionでは、対象となるATM nodeから離れる方向がforward、近づく方向がbackwardである。service callやbearerを誰が開始したかは関係しない。一方、ATM/AAL2 signalingではsetup requestの送信側から受信側へ向かう方向をforwardとした。

backward bearer establishmentでは、serviceを開始したgatewayがbearer setupを受け取る。そこから外へ出るPCRはSDPではforwardだが、ATM setupではbackwardになる。gatewayはdirectionをswapしなければならない。byteを忠実に保つことが、意味を壊す場面だった。

directionはmetadataではなくstateだった

atmQOSparmsやatmTrfcDescにはdirectionFlagがあり、f、b、fbを取る。ほかの値が未指定、非該当、暗黙、別経路で既知のためでも、direction自体は必須だった。

そこにはpeak cell rate、sustainable rate、burst size、delay variation、transit delay、acceptable loss ratioが入る。逆向きに適用すれば、容量やquality constraintが別のflowへ渡る。それでもsyntaxは正しく、log上の数値も同じままである。

必要なのは、値とともに座標を保存することだった。どのnodeを記述したSDPか、service callのoriginはどこか、bearer setupのoriginはどこか、現在のfieldを支配するprotocolは何か。これらを失ったforwardは完全な証拠ではない。

$は一部のfieldで選択をreceiverへ委ね、は文脈により複数の意味を持った。parserが合法性を確認しても、hardwareに何がinstallされたか、policyが何を許可したか、applicationに意味があったかは分からない。

将来届くrequestを認識するためのkey

call contextはcontroller経由で先にgatewayへ届き、ATM setupは後からnetworkを通って届く。その二つを結ぶため、RFC 3108はeecid、end-to-end connection identifierを使った。関連するATM/ISUP contextでは4 byteのbnc-idと同義だが、SDPは中立的な名称を選んだ。

forward setupでは、call-terminating gatewayが値を選び、SDPでoriginating側へ送り、その側が開始したbearer setupから同じ値を受け取る。backward setupでは、call-originating gatewayが選び、terminating側へ送り、その側が開始したsetupで取り戻す。

つまりsetupを受ける予定のnodeが、自分のtableで検索できるkeyを先に発行した。uniquenessはそのnode内だけでよく、Internet全体の名前ではない。割り当てたnodeがreleaseとreuseを管理し、RFCはconnection終了まで保持することを推奨した。

matchが証明するのは相関だけである。eecidはpersonを示さず、subscriberをauthenticateせず、circuitを作らず、mediaを測らない。setup/connectがbearer stateを作り、双方向packetとapplication measurementが結果を示す。

bearer message内でのencodingもSDPが全面的に定義したわけではない。RFCはいくつかのinformation elementを例示したが、transportのauthorityは各bearer protocolに残した。同じkeyを共有しても、二つのrecordは別のままだった。

descriptionをchainしても実体は生まれない

call establishment exampleでは、controllerがservice情報を交換し、gatewayへinstructionを出す。その後、一方のgatewayがeecidを含むATM setupを送る。receiverが以前のcontextを見つけ、connectを返す。その先で初めてmediaがbearerを使える。

SDPはdescriptionの証拠、control ackはinstruction受領の証拠、setupは試行の証拠、connectはlogical bearer stateの証拠である。どれも単独では双方向media、実測delay、loss、user experienceを証明しない。

chain attributeは、連続するSDP descriptionがalternativeなのか、IPとATMのように同じconnectionの異なるlayerなのかを区別した。各layerのdescriptionを単純に保ちながら前後を結べる。しかしdocumentのlinkはrunning layerの証明ではない。

後世の仕様も時系列を守る必要がある。RFC 3264がoffer/answerを定義したのは2002年で、RFC 4566とRFC 8866はさらに後のSDP revisionである。lineageは示せても、RFC 3108のdeploymentや2001年の全exchangeを証明しない。

securityは外側のprotocolに依存した

RFC 3108は、ATM/AAL2 bearer encryptionがRTP payload encryptionのようにはconventionalizeされておらず、bearer signaling authenticationも同様だと記した。SDPのk= lineはkeyや取得方法を表せるが、fieldの存在はprotectionの作動を示さない。

descriptionはsubscriber premisesのuntrusted equipmentから来る可能性があった。そのため独自securityをSDP内へ加えるのではなく、encapsulating protocolやlower layerへ依存した。SIP、MGCP、MegacoはIPsec authenticationとoptional encryptionを利用できた。「利用できる」は「利用した」ではない。

調査ではoriginal SDP、sender、reference node、call/bearer role、翻訳前後のdirection、eecid allocator・scope・lifetime、setup/connect/release、security association、installed QoS、counter、双方向packet、application outcomeを別々に残す必要がある。

残った教訓は言葉のprovenanceである

ATMが過去の技術に見えても、この問題は古くない。distributed systemはlocal、active、primary、owner、forwardといった普通語をlayer間で再利用する。文字列は同じでも原点が変わる。messageがauthenticで改ざんされていなくても、次のcontrol surfaceでは意味が反転し得る。

RFC 3108のgatewayは、どちらか一方を上位のauthorityにできなかった。両方が自分のlayerでは正しかったからである。必要だったのはtranslation、provenance、そしてrecordを混同しないcorrelationだった。

二つの層はforwardと言った。wireについて争ったのではなく、矢印をどこから引くかが違った。descriptionからbearer stateへ、さらにobserved mediaへ進む間、その違いを保つことがrunning realityへの条件だった。

二つの層が「forward」と呼び、逆方向を指した――RFC 3108

なぜ重要か

要約

同じ回線に二つの原点があった

directionはmetadataではなくstateだった

将来届くrequestを認識するためのkey

descriptionをchainしても実体は生まれない

securityは外側のprotocolに依存した

残った教訓は言葉のprovenanceである

出典

プロフィールの詳細

Strategic Circle

Leadership Alliance

Strategic Circle 向けブリーフィング

Leadership Alliance 解説