要約

  • RFC 3132でpagingはpacket配送そのものではなく、packet到着を契機にdormant hostを探してalertし、last-hop connectionを再び作れるようにする追加signalだった。
  • 端末の省電力はnetwork側の仕事を増やした。端末が細かな位置更新を控える代わりに、networkは粗いpaging areaを記憶し、radioの区域とIP subnetのずれを処理した。

省電力は仕事の消滅ではなく移転だった

dormant modeに入ったmobileは、通常IP trafficを運ぶradio channelを継続して監視しない。battery drainは減り、access pointを移るたびに位置を知らせるsignalも減らせる。だが、その節約は「何もしない」ことで成立したのではない。hostが手放した観測と更新をnetworkが引き受けた。

packetが来ても、last hopへそのまま流せない。networkはhostがいそうな区域を選び、まだ聞いているpaging channelで呼び、応答を待ち、traffic channelを戻し、必要ならIP位置も更新する。2001年6月のInformational文書RFC 3132は、このうち位置特定とalertのための追加signalをpagingと呼んだ。

last-hop routingはpagingではない、と文書は明記した。agentがpacketを受けた事実、pageを送った事実、hostが応答した事実、L3 linkが戻った事実、applicationがdataを受けた事実は別々である。この区別がなければ、network内の受領を利用者への配送と誤認する。

pagingを持たないsleep linkには別の答えがあった

RFC 3132は、休眠するradio linkを一括りにしなかった。

専用pagingがないlinkでは、hostがtime slotごとにtraffic channelへ目を覚ます。access pointはその間のpacketをbufferする。休眠中に範囲外へ移ったなら、起きたhostが新しいaccess pointへ再associationし、新しい側が古い側からbufferを受け取れる。このモデルでは、networkが配送に十分な正確さでattachmentを知っているため、IP pagingを加える利点はないと整理された。

もちろんbufferの量と保持時間はimplementation依存だった。overflowやtimeoutは起こり得る。この限定された分析を、後世のすべての省電力linkへ広げることはできない。

paging対応linkでは事情が変わる。休眠中のhostはtraffic channelで送受信せず、専用channelを連続または周期的に聞く。複数のaccess pointがpaging areaを作り、networkは最後に報告された区域、またはheuristicで推定した区域へpageを出す。応答があれば配送へ進み、timeoutなら一旦unreachableと扱う。

licensed spectrumでは、control signalをtraffic channelから外すことで、収益を生むtrafficへ容量を残し、利用者にoverheadを課金せずに済むという動機も記された。ただしRFCは経済効果を測定したわけではない。

同じ移動をradioとIPは別の境界で見た

問題の中心は、paging areaとsubnetが同じ地図ではなかったことにある。Mobile IPにとってsubnet境界を越えることはtopological locationの変化だった。radio pagingにとって重要なのはpaging-area境界だった。

一つのareaと一つのsubnetが一致すれば、既知のIP位置でradio pageを行える。追加のIP pagingは不要だった。

一つのsubnet内に複数のpaging areaがある場合、radio上の区域が変わってもIP位置は変わらない。access routerやMobile IPv4 foreign agentは複数区域へ呼びかければよい。

難しいのは、一つのpaging areaが複数subnetを覆う場合である。dormant hostはradio区域を出ずにsubnet境界を越えられる。L2はarea変更を見ないため、location updateを起こさない。しかしIP側の最後のsubnetは古くなる。最初のpacketは旧subnetへ届き、pageへの応答は別subnetから返り得る。

追加のMobile IP signalで修復は可能でも、最初の配送前にlatencyとmessageが増える。home agentまたはhierarchical agentから区域内のpaging agentへ専用交換を行えば、探索を短くできる可能性があった。RFCはそれを有望なoptimizationとして扱い、唯一解とはしなかった。

きれいな包含図は現場で崩れた

文書はまず単純なsubset関係を仮定し、あとで現実がもっと複雑だと認めた。paging area同士は重なり得る。同じ場所の端末に異なるarea identifierが割り当てられることもある。operatorがarea registrationを使わずheuristicで位置を推測する、というanecdotal evidenceも慎重に記録された。

区域を大きくすればhostの更新は減るが、packet到着時のsearch fan-outは増える。区域を小さくすれば探索は狭くなるが、移動中のsignalが増える。省電力とはcostを無くすことではなく、continuous trackingとon-demand searchの間で配り直すことだった。

異なるradio technologyが混在すると、networkは場所だけでなくinterface preferenceも推定しなければならない。屋内へ移ったhostは一方のcoverageを失い、より安い、または高速な別linkを選ぶかもしれない。RFCはIP-layer paging identifierを各access pointがradio固有のpageへ写す案を描いたが、deploymentを証明してはいない。

ARPやNeighbor Discoveryもtraffic channelが使えることを前提とするため、sleep中のhostを自然には見つけられなかった。

RFC 3154はwake-upを複数agentへ分解した

2001年8月のRFC 3154はrequirementsとfunctional architectureを示した。単純に見えるalertは、million-scale、filter、failure、authenticationを持つdistributed transactionへ広がった。

protocolはdormant modeの省電力を壊さず、broadcast・multicast・anycastのすべてでhostが起きないようfilterを持つ必要があった。dormantとinactive、完全なunreachableを区別し、複数の休眠方式を扱い、特定mobility protocolから独立しながら当時のMobile IPv4とMobile IPv6へbindingを定義することも求められた。

areaとsubnetの任意mapping、L2 pagingの選択的利用、network element failureとmessage lossへの耐性、location registration・area information・paging messageのauthenticationも必要だった。security exchangeがbatteryを過度に使えば目的に反する。

責任はHost、Tracking Agent、Paging Agent、Dormant Monitoring Agentに分かれた。位置を記憶する役、packet arrivalを検出する役、alertする役、L3 linkを戻す役が異なる。「起きた」という一語では、このchainのどこまで成功したか分からない。

五つのproposalは一つのstandardではなかった

2002年のworking-group Internet-Draftは五つのprotocol proposalをrequirementsと照合した。保存された-00と-01 revisionには、multiple dormant mode、mobility independence、failure、administration、MIPv4/MIPv6連携などの不足や未記述が並ぶ。

assessmentはInternet-Draftのままで、RFCではない。RFC 3132とRFC 3154もInformationalであり、implementation、interoperability、adoption、deploymentを証明しない。RFC 3344、6275、3753はMobile IPv4、Mobile IPv6、用語の後続文脈であって、paging構想の実装証明ではない。

reachableという一語では足りなくなった

正しいaddressを持つhostがtraffic channelを聞いていない。正しいpaging areaを知っていてもattachment pointは分からない。正しいpageを送っても応答は保証されない。radio応答があってもIP routeはまだ古いかもしれない。

hostは休眠を選ぶ。tracking systemは粗い位置を持つ。monitoring機能はpacketをtriggerへ変える。paging infrastructureはsearchを実行する。mobility procedureはrouteを直す。operatorはarea、filter、timeoutを設計する。成功のauthorityは一箇所にない。

RFC 3132が残したのは、最初のpacketが届いたという話ではない。packetはnetworkに、静かなhostを探す責任が発生したことを知らせた。端末のbatteryを守るためにnetworkが引き受けたのは、信頼できる記憶、範囲を限定した探索、そしてalertからdeliveryまでを混同しない証拠だった。

出典

  1. https://www.rfc-editor.org/rfc/rfc3132.txt
  2. https://www.rfc-editor.org/info/rfc3132
  3. https://www.rfc-editor.org/rfc/rfc3132.html
  4. https://www.rfc-editor.org/rfc/rfc3154.txt
  5. https://www.rfc-editor.org/info/rfc3154
  6. https://www.rfc-editor.org/rfc/rfc3154.html
  7. https://www.rfc-editor.org/rfc/rfc2002.txt
  8. https://www.rfc-editor.org/rfc/rfc3344.txt
  9. https://www.rfc-editor.org/rfc/rfc6275.txt
  10. https://www.rfc-editor.org/rfc/rfc3753.txt
  11. https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-00.txt
  12. https://www.ietf.org/archive/id/draft-ietf-seamoby-paging-protocol-assessment-01.txt