الخلاصة

  • فصلت RFC 3132 بين paging والتسليم: وصول حزمة لمضيف خامل كان يطلق إشارات إضافية لتحديد موقعه وتنبيهه، أما الوصلة الأخيرة فتأتي بعد ذلك.
  • لم تختف كلفة توفير الطاقة؛ انتقلت إلى الشبكة. قلّل الجهاز الاستماع وتحديثات الموقع، فاحتفظت الشبكة بمنطقة تقريبية وبحثت فيها ووفّقت بين حدود الراديو وحدود subnet.

بقي العنوان مستيقظاً بينما نامت القناة

يستطيع المضيف المحمول أن يحتفظ بعنوان IP صحيح، لكنه في dormant mode يقلّل مراقبة قنوات الراديو فلا يستقبل الحركة العادية باستمرار. هذا يوفّر البطارية ويخفّض إشارات تعقّب الموقع، لكنه يغيّر معنى وصول أول حزمة.

نشرت RFC 3132 في يونيو 2001 بوصفها وثيقة Informational. عرّفت paging بأنه الإشارات الإضافية التي تبحث عن المضيف الخامل وتنبهه بسبب حزمة وصلت إليه، كي يعيد إنشاء وصلة القفزة الأخيرة. أما إرسال الحزمة على تلك الوصلة فليس paging.

لهذا كانت الأدلة منفصلة: استلام agent للحزمة لا يعني استلام المستخدم؛ إرسال page لا يثبت سماعها؛ الرد الراديوي لا يثبت عودة مسار L3؛ وعودة المسار لا تثبت التسليم إلى التطبيق. شرحت الوثيقة المشكلة ولم تحدد بروتوكولاً مكتملاً.

لم تحتج كل حالة خمول إلى طبقة جديدة

في الوصلات التي تدعم الخمول من دون paging، كان المضيف يستيقظ دورياً على traffic channel، فيما يخزّن access point الحزم. إذا تحرك وهو نائم أعاد الارتباط عند الاستيقاظ، واستعاد access point الجديد المخزن من القديم. في هذا النموذج عرفت الشبكة موضع الارتباط بدقة كافية، فلم تجد RFC فائدة إضافية لـIP paging.

لكن حجم المخزن ومدة الاحتفاظ كانا من شأن التنفيذ، وبقي overflow وtimeout ممكنين.

في الوصلات التي تدعم paging، يترك المضيف traffic channel ويستمع إلى قناة تنبيه منفصلة باستمرار أو ضمن فترات. تجمع الشبكة نقاط الوصول في paging area، وترسل التنبيه إلى آخر منطقة معلومة أو مقدّرة. يسمح الرد بالمتابعة؛ أما timeout فيجعلها تعتبر المضيف غير قابل للوصول مؤقتاً.

سجلت الوثيقة حافز الطيف المرخّص: تقليل إشارات التحكم على قنوات الحركة يترك سعة أكبر للاستخدام المنتج. كان ذلك تفسيراً تشغيلياً لا قياساً مالياً.

رسم الراديو خريطة غير خريطة IP

يرى Mobile IP عبور subnet بوصفه تغيراً في الموقع الطوبولوجي. ويرى نظام paging عبور paging area بوصفه تغيراً مهماً. لا يلزم أن تتطابق الحدود.

إذا ساوت المنطقة subnet واحدة، أيقظ الراديو المضيف في موقع IP الصحيح. وإذا احتوت subnet عدة مناطق، أمكن لـaccess router أو foreign agent البحث فيها من دون تغيير الموقع IP.

ظهرت الفجوة عندما غطت paging area واحدة عدة subnets. يستطيع المضيف الخامل عبور حد IP من دون مغادرة منطقة الراديو. لا ترى L2 سبباً للتسجيل، بينما يصبح الموقع المحفوظ في IP قديماً. تصل الحزمة إلى subnet السابقة، وقد يأتي الرد على page من subnet أخرى.

تستطيع إشارات Mobile IP إضافية إصلاح ذلك، لكنها تزيد الرسائل والزمن قبل التسليم الأول. كان تبادل مخصص مع agent داخل المنطقة تحسيناً محتملاً لا حلاً وحيداً. قالت RFC بوضوح إن المشكلة هي العثور على جهاز تحرك وهو خامل، وإن IP paging مجرد حل ممكن.

المنطقة الواسعة ادخرت أولاً ودفعت عند البحث

اعترفت RFC بأن المناطق قد تتداخل، وأن أجهزة في المكان نفسه قد تحمل معرفات مختلفة، وأن بعض المشغلين اعتمدوا heuristics بدلاً من registration وفق دليل سردي محدود. المنطقة الكبيرة تقلّل تحديثات الجهاز وتوسّع fan-out عند وصول الحركة؛ المنطقة الصغيرة تفعل العكس.

ومع تقنيات راديو متعددة، لا يكفي معرفة المكان. قد يفقد المضيف تغطية ويفضّل وصلة أرخص أو أسرع. اقترحت الوثيقة معرفاً في طبقة IP تترجمه نقاط الوصول إلى pages خاصة بكل تقنية، من دون أن تثبت deployment. كذلك افترض ARP وNeighbor Discovery قناة حركة عاملة، وهي القناة التي أوقفها الخمول.

كشفت RFC 3154 أن الإيقاظ معاملة موزعة

أضافت RFC 3154 متطلبات التوسع إلى ملايين المضيفين، وتقليل استهلاك الطاقة، وترشيح broadcast وmulticast وanycast حتى لا توقظ رسالة واحدة أعداداً كبيرة. وجب تمييز dormant عن inactive وعن unreachable، ودعم حالات خمول متعددة والاستقلال عن بروتوكول حركة واحد مع الارتباط بأعمال Mobile IPv4 وIPv6.

وجب أيضاً قبول أي علاقة بين المنطقة وsubnet، واستخدام paging في L2 عند توفره من دون اشتراطه، وتحمل الفشل، وتوثيق التسجيل ومعلومات المنطقة ورسائل paging.

توزعت السلطة بين Host وTracking Agent وPaging Agent وDormant Monitoring Agent. أحدها حفظ الموقع، والثاني اكتشف الحزمة، والثالث أرسل التنبيه، ثم أعاد المضيف وصلة L3. لم يكن «استيقظ» دليلاً ذرياً واحداً.

بقيت المقترحات الخمسة مسودة تقييم

قيّمت Internet-Draft عام 2002 خمسة مقترحات. تظهر النسختان -00 و-01 مسائل ناقصة في تعدد حالات الخمول والاستقلال عن mobility والفشل والإدارة والتكامل. لم تصبح وثيقة التقييم RFC. كما لم تثبت RFC 3132 أو RFC 3154 التنفيذ أو التشغيل البيني أو الانتشار.

توفر RFC 3344 و6275 و3753 سياقاً لاحقاً لـMobile IPv4 وMobile IPv6 والمصطلحات، لكنها لا تثبت اعتماد بنية paging.

تحولت القابلية للوصول إلى سلسلة إيصالات

قد يصح العنوان وتكون القناة نائمة. قد تصح المنطقة وتخفي عدة subnets. قد تخرج page ولا تُسمع. وقد يصل الرد قبل إصلاح المسار.

اختار المضيف الخمول، وحفظ tracking اعتقاداً تقريبياً، وحوّل monitoring الحزمة إلى trigger، ونفذ paging البحث، وأصلحت mobility الموقع. اختار المشغل الحدود والفلاتر والمهل. لم يمتلك طرف واحد حقيقة التسليم كاملة.

لم تثبت الحزمة الأولى وصولها. كشفت الدين الذي قبلته الشبكة مقابل صمت الجهاز: ذاكرة موثوقة، بحث محدود، وأدلة لا تخلط التنبيه بالاتصال والتسليم.

المصادر

  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