بروتوكول الاتصال من نقطة إلى نقطة عبر الإيثرنت

مجموعة بروتوكولات PPPoE و TCP/IP
طلببروتوكول نقل الملفات (FTP)SMTPHTTP...نظام أسماء النطاقات (DNS)...
ينقلبروتوكول التحكم بالنقل (TCP)بروتوكول UDP
إنترنتالملكية الفكريةIPv6
الوصول إلى الشبكةبرنامج الشراكة بين القطاعين العام والخاص
PPPoE
إيثرنت

بروتوكول الاتصال من نقطة إلى نقطة عبر الإيثرنت ( PPPoE ) هو بروتوكول شبكي يُستخدم لتغليف إطارات بروتوكول الاتصال من نقطة إلى نقطة (PPP) داخل إطارات الإيثرنت . ظهر هذا البروتوكول عام 1999، بالتزامن مع ازدهار تقنية DSL ، كحلٍّ لتمرير الحزم عبر اتصال DSL إلى شبكة IP الخاصة بمزود خدمة الإنترنت (ISP) ، ومنها إلى بقية الإنترنت . أشار كتابٌ في مجال الشبكات صدر عام 2005 إلى أن "معظم مزودي خدمة DSL يستخدمون PPPoE، الذي يوفر المصادقة والتشفير والضغط . " [ 1 ] يتضمن الاستخدام النموذجي لـ PPPoE الاستفادة من إمكانيات PPP لمصادقة المستخدم باستخدام اسم المستخدم وكلمة المرور، عبر بروتوكول PAP أو CHAP . كان بروتوكول PAP هو السائد عام 2007 ، لكن مزودي الخدمة بدأوا بالتحول إلى بروتوكول CHAP الأكثر أمانًا ، لأن PAP بروتوكول نصي عادي. [ ٢ ] في حوالي عام ٢٠٠٠، بدأ بروتوكول PPPoE أيضاً في التحول إلى طريقة بديلة للتواصل مع المودم المتصل بجهاز كمبيوتر أو موجه عبر شبكة إيثرنت محلية، ليحل محل الطريقة الأقدم وهي USB . ولا يزال هذا الاستخدام، أي توصيل المودمات بالموجهات عبر الإيثرنت، شائعاً للغاية حتى اليوم.

في أجهزة المستخدمين ، يمكن تطبيق بروتوكول PPPoE إما في جهاز بوابة منزلية موحدة تتولى وظائف مودم DSL وتوجيه IP ، أو في حالة مودم DSL بسيط (بدون دعم التوجيه)، يمكن معالجة PPPoE خلفه على موجه إيثرنت منفصل أو حتى مباشرة على جهاز كمبيوتر المستخدم. (يدعم PPPoE معظم أنظمة التشغيل، بدءًا من Windows XP [ 3 ] وLinux [ 4 ] وصولًا إلى Mac OS X [ 5 ] ) . ومؤخرًا ، بدأت بعض البوابات المنزلية القائمة على GPON (بدلًا من DSL) باستخدام PPPoE، على الرغم من أن مكانة PPPoE في معايير GPON هامشية، مع أنها مذكورة في توصية ITU-T G.984.1 " الشبكات الضوئية السلبية القادرة على نقل البيانات بسرعة جيجابت (GPON): الخصائص العامة" .

تم تطوير PPPoE بواسطة UUNET و Redback Networks (الآن Ericsson) و RouterWare (الآن Wind River Systems ) [ 6 ] وهو متاح كملف RFC 2516 إعلامي . 

في عالم DSL، من المفهوم بشكل شائع أن PPP يعمل فوق ATM (كـ PPPoA) مع ATM كبروتوكول الطبقة 2 الأساسي ونسخة من DSL كبروتوكول الطبقة 1، على الرغم من عدم وجود مثل هذا القيد في بروتوكول PPP نفسه.

تُفرَّق سيناريوهات الاستخدام الأخرى أحيانًا بإضافة لاحقة تشير إلى بروتوكول أساسي آخر. على سبيل المثال، PPPoEoE، عندما تكون وسيلة النقل هي الإيثرنت نفسها، كما هو الحال في شبكات مترو إيثرنت . (في هذه الحالة، يُشار إلى الاستخدام الأصلي لـ PPPoE باسم PPPoEoA، مع العلم أنه لا ينبغي الخلط بينه وبين PPPoA ، الذي يستخدم تغليفًا مختلفًا لبروتوكول PPP).

وُصِفَ بروتوكول PPPoE في بعض الكتب بأنه بروتوكول " طبقة 2.5[ 2 ] [ 7 ] وهو مشابهٌ بشكلٍ مبسط لبروتوكول MPLS لأنه يُمكن استخدامه لتمييز تدفقات IP المختلفة التي تتشارك بنية تحتية إيثرنت، على الرغم من أن عدم وجود محولات PPPoE التي تتخذ قرارات التوجيه بناءً على رؤوس PPPoE يحد من قابليته للتطبيق في هذا الصدد. [ 7 ]

الأساس المنطقي الأصلي

في أواخر عام 1998، لم يكن نموذج خدمة DSL قد وصل بعد إلى النطاق الواسع الذي من شأنه خفض الأسعار إلى مستويات مناسبة للأسر. وكانت تقنية ADSL قد طُرحت قبل ذلك بعقد من الزمن. [ 8 ] أدرك كل من موردي المعدات المحتملين وشركات الاتصالات أن النطاق العريض، مثل مودم الكابل أو DSL، سيحل في نهاية المطاف محل خدمة الاتصال الهاتفي ، لكن الأجهزة (سواء في منازل العملاء أو شركات الاتصالات المحلية ) واجهت عائقًا كبيرًا يتمثل في التكلفة المنخفضة . أظهرت التقديرات الأولية لنشر DSL بكميات محدودة تكاليف تتراوح بين 300 و500 دولار أمريكي ( 593-988 دولارًا أمريكيًا في عام 2025 ) لمودم DSL ورسوم اشتراك شهرية قدرها 300 دولار أمريكي من شركة الاتصالات، وهو ما يتجاوز بكثير ما سيدفعه المستخدم المنزلي. ولذلك، كان التركيز الأولي على عملاء الشركات الصغيرة والمنزلية الذين...  لم يكن خط T1 بسرعة 1.5 ميجابت/ثانية (بسعر يتراوح بين 800 و1500 دولار أمريكي شهريًا آنذاك) اقتصاديًا، ولكن من كان يحتاج إلى سرعة أعلى مما توفره خدمات الاتصال الهاتفي أو ISDN ؟ إذا ما زاد عدد هؤلاء العملاء، فإن الكميات ستؤدي إلى انخفاض الأسعار إلى مستوى قد يجذب مستخدمي الاتصال الهاتفي المنزلي.

ملف تعريف استخدام مختلف

تكمن المشكلة في أن عملاء الشركات الصغيرة لديهم نمط استخدام مختلف عن مستخدمي الاتصال الهاتفي المنزلي، بما في ذلك:

  • ربط شبكة محلية كاملة بالإنترنت؛
  • توفير الخدمات على شبكة محلية يمكن الوصول إليها من الجانب البعيد للاتصال؛
  • الوصول المتزامن إلى مصادر بيانات خارجية متعددة، مثل شبكة VPN الخاصة بالشركة ومزود خدمة الإنترنت للأغراض العامة؛
  • الاستخدام المستمر طوال يوم العمل، أو حتى على مدار الساعة.

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

يُستخدم بروتوكول PPPoE بشكل رئيسي إما:

  • مع خدمات الإنترنت عبر خط المشترك الرقمي (DSL) التي تدعم بروتوكول PPPoE، حيث يتصل مودم / راوتر ( بوابة منزلية ) يدعم بروتوكول PPPoE بخدمة DSL. في هذه الحالة، يجب أن يدعم كل من مزود خدمة الإنترنت والمودم/الراوتر بروتوكول PPPoE. (يُشار أحيانًا إلى جانب PPPoE عبر DSL في هذه الحالة باسم PPPoEoA ، اختصارًا لـ "PPPoE عبر ATM ").
  • أو عندما يتم توصيل مودم DSL يدعم تقنية PPPoE بجهاز توجيه يدعم تقنية Ethernet فقط باستخدام كابل Ethernet.

سرعة الوصول إلى السوق: البساطة هي الأفضل

تمثلت إحدى المشكلات في إنشاء بروتوكول جديد كليًا لتلبية هذه الاحتياجات في عامل الوقت. كانت المعدات متوفرة على الفور، وكذلك الخدمة، وكان تطوير حزمة بروتوكولات جديدة بالكامل ( كانت مايكروسوفت آنذاك تدعو إلى استخدام تقنية الألياف الضوئية من خلايا الصراف الآلي إلى أجهزة سطح المكتب، [ 9 ] وكان بروتوكول L2TP قيد التطوير أيضًا، ولكنه لم يكن قريبًا من الاكتمال) سيستغرق وقتًا طويلاً للتنفيذ، مما قد يؤدي إلى ضياع فرصة التنفيذ. لذلك، اتُخذت عدة قرارات لتبسيط التنفيذ والتوحيد القياسي في محاولة لتقديم حل متكامل بسرعة وبتكلفة أقل.

إعادة استخدام حزم البرامج الحالية

كان الهدف من بروتوكول PPPoE هو دمج بنية الإيثرنت واسعة الانتشار مع بروتوكول PPP الشائع، مما يسمح للموردين بإعادة استخدام برامجهم الحالية وتقديم منتجاتهم في وقت قريب جدًا. كانت جميع أنظمة التشغيل تقريبًا في ذلك الوقت مزودة بحزمة بروتوكول PPP، وقد سمح تصميم PPPoE بوجود طبقة وسيطة بسيطة لتغليف إطارات PPP داخل إطارات الإيثرنت.

تبسيط متطلبات الأجهزة

تتطلب تقنيات الشبكات الواسعة المنافسة (T1، ISDN) وجود جهاز توجيه في مقر العميل. بينما يستخدم بروتوكول PPPoE نوعًا مختلفًا من إطارات الإيثرنت ، مما يسمح لأجهزة DSL بالعمل كجسر بسيط ، حيث يمرر بعض الإطارات إلى الشبكة الواسعة ويتجاهل البقية. ويُعدّ تنفيذ مثل هذا الجسر أبسط بكثير من تنفيذ جهاز التوجيه.

طلب معلوماتي

تم إصدار RFC 2516 في البداية كـ RFC إعلامي (بدلاً من RFC ذي مسار معياري ) لنفس السبب: كانت فترة اعتماد RFC ذي المسار المعياري طويلة بشكل كبير.

حالات الاستخدام في العصر الحديث

في حوالي عام 2000، استُخدم بروتوكول PPPoE إما (أ) لتوصيل مودم DSL بجهاز كمبيوتر أو موجه، ليحل محل الطريقة السابقة باستخدام USB ، أو (ب) استُخدمت مجموعة بروتوكولات PPP+PPPoE الثلاثية لتوصيل موجه بعقدة شبكة، وهي محول بروتوكول ، تقع في مكان أبعد قليلاً في اتجاه المنبع، إما تابعة لمزود خدمة الإنترنت أو لشركة اتصالات بعيدة المدى بالجملة، والتي بدورها تتصل بشبكات IP الخاصة بمزود خدمة الإنترنت، ثم بالإنترنت. [ 10 ]

لا تزال حالة الاستخدام الأولى، وهي اتصال جهاز التوجيه بالمودم، والتي تتضمن ما يسمى بـ "PPPoEoE" (ثلاثي بروتوكول PPPoE عبر شبكة إيثرنت محلية فعلية)، مستخدمة بشكل كبير اليوم لتوصيل أجهزة المودم بأجهزة التوجيه إذا تم استخدام PPP.

أما حالة الاستخدام الثانية، حيث تُستخدم بروتوكولات PPPoE الثلاثة عبر وصلة إنترنت واحدة أو أكثر تصل إلى مستوى أعلى أو أدنى، فهي، وفقًا للإجماع، لا تزال تُستخدم لأسباب تاريخية فقط. ومع ذلك، لا يزال بروتوكول PPP شائعًا لدى بعض مزودي خدمة الإنترنت، إما كبروتوكول نفق، وهو أمر ضروري عندما يستخدم مزود خدمة الإنترنت شركة اتصالات/موزع خدمات بالجملة، أو لأن ميزات PPP مرغوبة، أو كليهما.

كما ذُكر سابقًا، من الغريب أن رؤوس MAC الخاصة بشبكة الإيثرنت تُستخدم أحيانًا مع رؤوس PPPoE حتى عندما لا يكون بروتوكول الإيثرنت مُستخدمًا، أي غير موجود فعليًا على شبكة الإيثرنت. ويبدو أن هذا لا يخدم أي غرض سوى إضافة عبء إضافي غير ضروري على الرؤوس، ما يُعرف بالتضخم . على سبيل المثال، في حالة PPPoEoA ، التي سنناقشها لاحقًا، حيث لم تكن هناك شبكة إيثرنت فعلية، بل فقط ATM ، لم تُضَف طبقة MAC غير ضرورية لرأس الإيثرنت فحسب، بل أُضيفت أيضًا طبقة تكييف إضافية لشبكة الإيثرنت لجعل الإيثرنت متوافقًا مع ATM.

في حالة الاستخدام الثانية، تضيف رؤوس البروتوكول الإضافية هذه قدراً كبيراً من التضخم وبالتالي تضر بالأداء بمقدار ضئيل.

في حالة الاستخدام الثانية ، يمتد استخدام بروتوكول PPP+PPPoE+Ethernet MAC لمسافة متغيرة في اتجاه المنبع. قد يقتصر على " الميل الأول ": زوج من الأسلاك النحاسية المجدولة في ADSL أو VDSL2 / FTTC التي تتضمن أجهزة المودم فقط، أو قد يُستخدم أيضًا في اتجاه المنبع ليصل إلى خادم الوصول عن بُعد للنطاق العريض (BRAS) أو مُجمِّع الوصول، الذي قد يُدير عملية تسجيل الدخول أو لا، ولكنه بالتأكيد سيكون مُحوِّل بروتوكول من نوع ما. في أحد الأمثلة، يمتد بروتوكول PPPoE في اتجاه المنبع وينتهي عند عقدة تُشغِّلها شركة اتصالات بالجملة، والتي تُحوِّل إلى بروتوكول نفق L2TP الذي يُنشئ نفقًا إلى نقاط التواجد ( POPs ) الخاصة بمزود خدمة الإنترنت .

مراحل

تتكون بروتوكولات PPPoE من مرحلتين متميزتين:

اكتشاف PPPoE

بما أن اتصالات PPP التقليدية تُنشأ بين نقطتي نهاية عبر وصلة تسلسلية أو عبر دائرة ATM افتراضية مُنشأة مسبقًا أثناء الاتصال الهاتفي، فإن جميع إطارات PPP المُرسلة عبر السلك تصل حتمًا إلى الطرف الآخر. أما شبكات الإيثرنت فهي متعددة الوصول، حيث يمكن لكل عقدة في الشبكة الوصول إلى أي عقدة أخرى. يحتوي إطار الإيثرنت على عنوان الجهاز للعقدة الوجهة ( عنوان MAC )، مما يُساعد الإطار على الوصول إلى وجهته المقصودة.

لذا، قبل تبادل حزم التحكم PPP لإنشاء الاتصال عبر الإيثرنت، يجب أن تكون عناوين MAC الخاصة بنقطتي النهاية معروفة لبعضهما البعض حتى يمكن تضمينها في حزم التحكم هذه. تقوم مرحلة اكتشاف PPPoE بهذا الأمر تحديدًا. كما أنها تساعد في إنشاء مُعرّف جلسة يمكن استخدامه لتبادل الحزم لاحقًا، ويُستخدم أيضًا للإشارة إلى إنهاء الجلسة.

يتم نقل حزم اكتشاف PPPoE في إطارات إيثرنت مع ضبط EtherType على 0x8863.

جلسة الشراكة بين القطاعين العام والخاص

بمجرد معرفة عنوان MAC الخاص بالطرف الآخر وإنشاء جلسة، تبدأ مرحلة الجلسة. في هذه المرحلة، تُغلّف أجزاء من بيانات PPP في حزم PPPoE وتُرسل إلى الطرف الآخر. تتفاوض حزم الجلسة الأولى على جلسة PPP كالمعتاد، وبعد ذلك تحتوي معظم حزم الجلسة على أجزاء من بيانات PPP.

يتم التغليف عن طريق إضافة رأس PPPoE المكون من 6 بايت إلى أجزاء PPP ونقلها في إطارات Ethernet مع تعيين EtherType إلى 0x8864.

اكتشاف بروتوكول PPPoE (PPPoED)

على الرغم من أن بروتوكول PPP التقليدي هو بروتوكول نظير إلى نظير ، إلا أن PPPoE هو في جوهره علاقة بين العميل والخادم حيث يمكن للعديد من المضيفين الاتصال بمزود الخدمة عبر اتصال مادي واحد.

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

العميل إلى الخادم: بدء التشغيل (PADI)

PADI تعني بدء اكتشاف PPPoE النشط. [ 11 ]

إذا أراد المستخدم الاتصال بالإنترنت عبر خط DSL، فيجب على حاسوبه أولاً العثور على مُركِّز الوصول DSL (DSL-AC) عند نقطة تواجد مزود خدمة الإنترنت (POP). لا يمكن الاتصال عبر الإيثرنت إلا من خلال عناوين MAC . ولأن الحاسوب لا يعرف عنوان MAC الخاص بمُركِّز الوصول DSL، فإنه يرسل حزمة PADI عبر بث إيثرنت (MAC: ff:ff:ff:ff:ff:ff). تحتوي حزمة PADI هذه على عنوان MAC الخاص بالحاسوب المُرسِل.

مثال على حزمة بيانات PADI:

الإطار 1 (44 بايت على السلك، 44 بايت تم التقاطها) Ethernet II، Src: 00:50:da:42:d7:df، Dst: ff:ff:ff:ff:ff:ff اكتشاف بروتوكول PPP عبر الإيثرنت الإصدار: 1 النوع 1 بدء اكتشاف الكود النشط (PADI) معرّف الجلسة: 0000 طول الحمولة: 24 علامات PPPoE الوسم: اسم الخدمة الوسم: مضيف فريد البيانات الثنائية: (16 بايت) 

يحتوي عنوان المصدر ( Src. ) على عنوان MAC الخاص بالكمبيوتر المُرسِل لحزمة PADI. أما عنوان الوجهة ( Dst. ) فهو عنوان البث عبر الإيثرنت . يمكن لأكثر من جهاز DSL-AC استقبال حزمة PADI. يجب أن تردّ فقط أجهزة DSL-AC التي تدعم علامة "اسم الخدمة" (Service-Name).

من الخادم إلى العميل: عرض (PADO)

PADO تعني عرض اكتشاف PPPoE النشط. [ 11 ]

بمجرد أن يرسل جهاز المستخدم حزمة PADI، يرد جهاز DSL-AC بحزمة PADO، مستخدمًا عنوان MAC المُقدّم في PADI. تحتوي حزمة PADO على عنوان MAC الخاص بجهاز DSL-AC، واسمه (مثل LEIX11-erx لجهاز T-Com DSL-AC في لايبزيغ )، واسم الخدمة. إذا ردّ أكثر من جهاز DSL-AC تابع لنقطة وصول واحدة بحزمة PADO، يختار جهاز المستخدم جهاز DSL-AC الخاص بنقطة الوصول المحددة باستخدام الاسم أو الخدمة المُقدّمة.

فيما يلي مثال على حزمة PADO:

الإطار 2 (60 بايت على السلك، 60 بايت تم التقاطها) إيثرنت II، SRC: 00:0e:40:7b:f3:8a، Dst: 00:50:da:42:d7:df اكتشاف بروتوكول PPP عبر الإيثرنت الإصدار: 1 النوع 1 عرض اكتشاف الكود النشط (PADO) معرّف الجلسة: 0000 طول الحمولة: 36 علامات PPPoE الوسم: اسم AC بيانات السلسلة: lpzbr001 الوسم: مضيف فريد البيانات الثنائية: (16 بايت) 

يحتوي حقل AC-Name -> String data على اسم وحدة التحكم، وفي هذه الحالة "lpzbr001" (وحدة التحكم Arcor DSL-AC في لايبزيغ). أما حقل Src. فيحتوي على عنوان MAC الخاص بوحدة التحكم DSL-AC، والذي يكشف أيضاً عن الشركة المصنعة لها (في هذه الحالة Nortel Networks ).

من العميل إلى الخادم: طلب (PADR)

PADR هو اختصار لطلب الاكتشاف النشط لبروتوكول PPPoE. [ 11 ]

يُرسل جهاز المستخدم حزمة PADR إلى وحدة التحكم DSL-AC بعد استلام حزمة PADO مقبولة منها. وتؤكد هذه الحزمة قبول عرض اتصال PPPoE المقدم من وحدة التحكم DSL-AC التي أصدرت حزمة PADO.

من الخادم إلى العميل: تأكيد الجلسة (PADS)

PADS تعني تأكيد جلسة اكتشاف PPPoE النشط. [ 11 ]

تم تأكيد حزمة PADR المذكورة أعلاه بواسطة جهاز DSL-AC بحزمة PADS، وتم إصدار مُعرّف جلسة معها. وبذلك، تم إنشاء الاتصال مع جهاز DSL-AC الخاص بنقطة التواجد هذه بشكل كامل.

من أي طرف إلى الطرف الآخر: إنهاء (PADT)

يرمز PADT إلى إنهاء اكتشاف PPPoE النشط. [ 11 ] تقوم هذه الحزمة بإنهاء الاتصال بنقطة التواجد (POP). ويمكن إرسالها إما من جهاز المستخدم أو من DSL-AC.

تكاليف البروتوكول الإضافية

يُستخدم بروتوكول PPPoE لتوصيل جهاز كمبيوتر أو موجه ( راوتر ) بجهاز مودم عبر وصلة إيثرنت، ويمكن استخدامه أيضًا للوصول إلى الإنترنت عبر خط DSL على خط الهاتف ضمن حزمة بروتوكولات PPPoE عبر ATM (PPPoEoA) عبر ADSL . يُعدّ PPPoE عبر ATM الأكثر استهلاكًا للموارد بين طرق توصيل DSL الشائعة، مقارنةً ببروتوكولات أخرى مثل PPPoA (RFC 2364). [ 12 ] [ 13 ] [ 14 ] [ 15 ]

يُستخدم مع DSL – PPPoE عبر ATM (PPPoEoA)

يعتمد مقدار الحمل الزائد الذي يضيفه PPPoEoA على وصلة DSL على حجم الحزمة بسبب (1) تأثير امتصاص حشو خلية ATM (المناقش أدناه)، والذي يلغي تمامًا الحمل الزائد الإضافي لـ PPPoEoA في بعض الحالات، (2) الحمل الزائد لـ PPPoEoA + AAL5 والذي يمكن أن يتسبب في الحاجة إلى خلية ATM إضافية كاملة بحجم 53 بايت، و(3) في حالة حزم IP، قد يتسبب الحمل الزائد لـ PPPoE المضاف إلى الحزم القريبة من الحد الأقصى للطول ( ' MRU ' ) في تجزئة IP ، وهو ما يشمل أيضًا الاعتبارين الأولين لكلا جزئي IP الناتجين. [ 16 ] مع ذلك، وبغض النظر عن تجزئة ATM وIP مؤقتًا، فإنّ حجم بيانات رأس بروتوكول ATM عند اختيار PPP + PPPoEoA قد يصل إلى 44 بايتًا = 2 بايت (لـ PPP) + 6 بايت (لـ PPPoE) + 18 بايت (عنوان MAC لشبكة الإيثرنت، متغير) + 10 بايت (RFC 2684 LLC، متغير) + 8 بايت (AAL5 CPCS). [ 12 ] هذا الحجم هو نفسه الذي يتم الحصول عليه عند استخدام خيار رأس LLC الموصوف في RFC 2684 لـ PPPoEoA. [ 14 ] [ 15 ]

قارن هذا ببروتوكول أكثر كفاءةً بكثير من حيث حجم البيانات في رأس الحزمة، وهو PPP + PPPoA RFC 2364 VC-MUX عبر ATM+DSL، والذي لا يتجاوز حجم البيانات الإضافية فيه 10 بايتات ضمن حمولة ATM. (في الواقع، 10 بايتات = 2 بايت لبروتوكول PPP + صفر لبروتوكول RFC 2364 + 8 (AAL5 CPCS)). [ 13 ] [ 15 ]

يمكن تقليل حجم بيانات AAL5 الإضافية البالغ 44 بايت بطريقتين: (أ) باختيار خيار RFC 2684 الذي يقضي بحذف رمز التحكم في تدفق بيانات MAC الخاص بشبكة إيثرنت (FCS) ذي 4 بايت، مما يقلل الحجم من 18 بايت إلى 14 بايت، و(ب) باستخدام خيار VC-MUX في RFC 2684، الذي لا تتجاوز مساهمته في الحجم الإضافي بايتين فقط مقارنةً بـ 10 بايت في بديل LLC. وقد تبين أن هذا التخفيض في الحجم الإضافي يُحسّن الكفاءة بشكل ملحوظ. باستخدام VC-MUX بدلاً من LLC، يصبح حجم بيانات ATM الإضافية إما 32 بايت (بدون رمز التحكم في تدفق بيانات إيثرنت FCS) أو 36 بايت (مع رمز التحكم في تدفق البيانات). [ 12 ] [ 14 ]

يتطلب بروتوكول ATM AAL5 وجود تذييل "CPCS" بطول 8 بايت في نهاية الخلية الأخيرة (محاذاة لليمين) من سلسلة خلايا ATM التي تُشكل حزمة بيانات AAL5. في حالة LLC، يبلغ إجمالي حجم بيانات ATM الإضافية 44 بايت (2 + 6 + 18 + 10 + 8) في حال وجود FCS لـ Ethernet MAC، أو 40 بايت (2 + 6 + 14 + 10 + 8) في حال عدم وجود FCS. أما في حالة VC-MUX الأكثر كفاءة، فيبلغ حجم بيانات ATM الإضافية 36 بايت (2 + 6 + 18 + 2 + 8) (مع FCS)، أو 32 بايت (2 + 6 + 14 + 2 + 8) ( بدون FCS).

مع ذلك، فإنّ العبء الإضافي الحقيقي من حيث إجمالي بيانات حمولة ATM المرسلة ليس قيمة ثابتة، بل يمكن أن يكون إما صفرًا أو 48 بايتًا (باستثناء السيناريو (iii) المذكور سابقًا، وهو تجزئة IP). وذلك لأنّ خلايا ATM ذات طول ثابت وسعة حمولة تبلغ 48 بايتًا، وقد تتطلب إضافة كمية إضافية من حمولة AAL5 نتيجةً لرؤوس إضافية إرسال خلية ATM كاملة أخرى تحتوي على الفائض. تحتوي آخر خلية أو خليتين من خلايا ATM على بايتات حشو حسب الحاجة لضمان أن يكون طول حمولة كل خلية 48 بايتًا. [ 12 ] [ 14 ]

مثال: في حالة إرسال حزمة بيانات IP بحجم 1500 بايت عبر بروتوكول AAL5/ATM باستخدام PPPoEoA وRFC2684-LLC، مع إهمال حشو الخلية الأخيرة مؤقتًا، يبدأ الحجم بـ 1500 + 2 + 6 + 18 + 10 + 8 (ملحق AAL5 CPCS) = 1544 بايت في حال وجود FCS لشبكة Ethernet، أو 40 بايت في حال عدم وجود FCS + 2 + 6 + 14 + 10 + 8. يتطلب إرسال 1544 بايت عبر ATM استخدام 33 خلية ATM، كل منها بسعة 48 بايت، لأن سعة الحمولة المتاحة البالغة 32 خلية × 48 بايت لكل خلية = 1536 بايت غير كافية. قارن هذا بحالة بروتوكول PPP + PPPoA، حيث يبلغ حجم الحزمة 1510 بايت (1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (تذييل CPCS))، وهو ما يتناسب مع 32 خلية. لذا، فإن التكلفة الحقيقية لاختيار PPPoEoA مع RFC2684-LLC لحزم IP بحجم 1500 بايت هي خلية ATM إضافية لكل حزمة IP، بنسبة 33:32. [ 12 ] [ 13 ] [ 14 ] وبالتالي، بالنسبة لحزم بحجم 1500 بايت، يكون PPPoEoA مع LLC أبطأ بنسبة 3.125% تقريبًا من PPPoA أو الخيارات المثلى لرأس PPPoEoA.

بالنسبة لبعض أطوال الحزم، ستكون الزيادة الفعلية في الحمل الزائد الفعلي لتقنية DSL الناتجة عن اختيار PPPoEoA مقارنةً بـ PPPoA معدومة، إذا لم يكن الحمل الزائد الإضافي في رأس الحزمة كافيًا لاستدعاء خلية ATM إضافية عند طول تلك الحزمة. على سبيل المثال، حزمة بطول 1492 بايت مُرسلة باستخدام PPP + PPPoEoA مع RFC2684-LLC بالإضافة إلى FCS تُعطينا حمولة ATM إجمالية قدرها 1492 + 44 = 1536 بايت، أي ما يعادل 32 خلية بالضبط. وفي هذه الحالة الخاصة، لا يزيد الحمل الزائد عن الحمل الزائد في حال استخدام بروتوكول PPPoA ذي الكفاءة العالية في استخدام رأس الحزمة، والذي يتطلب حمولة ATM قدرها 1492 + 2 + 0 + 8 = 1502 بايت، أي ما يعادل 32 خلية أيضًا. [ 12 ] [ 14 ] تمثل حالة طول الحزمة 1492 بايت الكفاءة المثلى لبروتوكول PPPoEoA مع RFC2684-LLC من حيث النسبة، ما لم يُسمح بحزم أطول.

يُعدّ استخدام بروتوكول PPPoEoA مع خيار رأس VC-MUX في RFC2684 أكثر كفاءةً من خيار LLC، حيث أن حجم بيانات ATM الإضافية، كما ذُكر سابقًا، لا يتجاوز 32 أو 36 بايت (بحسب ما إذا كان ذلك مع أو بدون خيار Ethernet FCS في PPPoEoA). وبالتالي، فإن حزمة بيانات بطول 1500 بايت، تشمل جميع البيانات الإضافية لبروتوكولي PPP وPPPoEoA باستخدام VC-MUX، تُعادل حمولة ATM إجمالية قدرها 1500 + 36 = 1536 بايت في حال وجود FCS، أي ما يعادل 32 خلية ATM بالضبط، مما يوفر خلية ATM كاملة. [ 12 ] [ 14 ]

مع الحزم القصيرة، كلما زاد حجم بيانات الترويسة، زاد احتمال إنشاء خلية ATM إضافية. في أسوأ الأحوال، قد يتم إرسال ثلاث خلايا ATM بدلاً من اثنتين بسبب زيادة حجم بيانات الترويسة من 44 بايت إلى 10 بايت، مما يعني زيادة وقت الإرسال بنسبة 50%. على سبيل المثال، يبلغ طول حزمة TCP ACK عبر IPv6 60 بايت، ومع زيادة حجم بيانات الترويسة بمقدار 40 أو 44 بايت لبروتوكول PPPoEoA + LLC، يتطلب ذلك ثلاث حمولات لخلايا ATM، كل منها بحجم 48 بايت. في المقابل، يتسع بروتوكول PPPoA، مع زيادة حجم بيانات الترويسة بمقدار 10 بايت، أي 70 بايت إجمالاً، في خليتين. لذا، فإن التكلفة الإضافية لاختيار PPPoE/LLC بدلاً من PPPoA هي زيادة حجم البيانات المرسلة بنسبة 50%. مع ذلك، يُعد استخدام PPPoEoA + VC-MUX خيارًا مناسبًا: فمع زيادة حجم بيانات الترويسة بمقدار 32 أو 36 بايت، تتسع حزمة IP في خليتين.

في جميع الحالات، يُعدّ اختيار PPPoA (RFC2364) VC-MUX الخيار الأمثل للوصول إلى الإنترنت عبر ADSL باستخدام تقنية ATM. مع ذلك، إذا كانت تقنية PPPoE مطلوبة، فإن الخيار الأفضل دائمًا هو استخدام VC-MUX (بدلاً من LLC) بدون FCS لشبكة Ethernet، مما يُعطي حمولة بيانات إضافية لتقنية ATM تبلغ 32 بايت = 2 بايت (لـ PPP) + 6 بايت (لـ PPPoE) + 14 بايت (لـ MAC لشبكة Ethernet، بدون FCS) + 2 بايت (RFC 2684 VC-MUX) + 8 بايت (لـ AAL5 CPCS).

لسوء الحظ، تتطلب بعض خدمات DSL استخدام رؤوس LLC غير الضرورية مع PPPoE، ولا تسمح بخيار VC-MUX الأكثر كفاءة. في هذه الحالة، يُحسّن استخدام طول حزمة بيانات مُصغّر، مثل فرض حد أقصى لوحدة النقل القصوى (MTU) يبلغ 1492، الكفاءة مع الحزم الطويلة حتى مع رؤوس LLC، وكما ذُكر سابقًا، لا يتم توليد أي خلية ATM إضافية غير ضرورية.

التكاليف الإضافية على شبكة الإيثرنت

في شبكة إيثرنت محلية، يكون الحمل الزائد لبروتوكول PPP + PPPoE ثابتًا عند 2 + 6 = 8 بايت ، ما لم يحدث تجزئة IP.

MTU/MRU

عندما يرسل مودم DSL يدعم بروتوكول PPPoE أو يستقبل حزم بيانات إيثرنت تحتوي على حمولة PPP + PPPoE عبر وصلة الإيثرنت إلى جهاز توجيه (أو جهاز كمبيوتر واحد يدعم PPPoE)، فإنّ PPP + PPPoE يُضيف حمولة إضافية قدرها 8 بايتات = 2 بايت (PPP) + 6 بايتات (PPPoE) ضمن حمولة كل حزمة بيانات إيثرنت. قد يعني هذا الحجم الإضافي فرض حد أقصى مُخفّض لطول الحزمة (يُسمى " MTU " أو " MRU " ) يبلغ 1500 - 8 = 1492 بايتًا على سبيل المثال، وذلك على حزم IP المُرسلة أو المُستقبلة، بدلاً من الحد الأقصى المعتاد لطول حمولة حزمة بيانات الإيثرنت البالغ 1500 بايتًا والمُطبّق على شبكات الإيثرنت القياسية. تدعم بعض الأجهزة معيار RFC 4638، الذي يسمح بالتفاوض على استخدام إطارات إيثرنت غير قياسية بحجم 1508 بايت، والتي تُسمى أحيانًا " إطارات جامبو صغيرة "، مما يسمح باستخدام حمولة PPPoE كاملة بحجم 1500 بايت. تُعد هذه الميزة مفيدة للعديد من المستخدمين في الحالات التي تختار فيها الشركات المُستقبلة لحزم IP (خطأً) حظر جميع استجابات ICMP من الخروج من شبكتها، وهي ممارسة سيئة تمنع اكتشاف MTU للمسار من العمل بشكل صحيح، وقد تُسبب مشاكل للمستخدمين الذين يصلون إلى هذه الشبكات إذا كان حجم MTU لديهم أقل من 1500 بايت.

مودم ADSL لتحويل PPPoE إلى PPPoA

يوضح الرسم التخطيطي التالي سيناريو يعمل فيه مودم ADSL متصل بشبكة إيثرنت كمحول بروتوكول PPPoE إلى PPPoA ، بينما يقدم مزود الخدمة خدمة PPPoA ولا يدعم PPPoE. لا يوجد بروتوكول PPPoEoA في سلسلة البروتوكولات هذه. يُعد هذا تصميمًا مثاليًا وفعالًا من حيث استخدام البروتوكولات لمودم ADSL منفصل متصل بجهاز توجيه عبر الإيثرنت.

في هذه التقنية البديلة، يُعدّ بروتوكول PPPoE مجرد وسيلة لتوصيل مودمات DSL بجهاز توجيه يدعم الإيثرنت فقط (أو بجهاز كمبيوتر مضيف واحد). ولا يتعلق الأمر هنا بالآلية التي يستخدمها مزود خدمة الإنترنت لتقديم خدمات النطاق العريض.

تعمل أجهزة المودم Draytek Vigor 110 و 120 و 130 بهذه الطريقة.

عند إرسال حزم البيانات المتجهة إلى الإنترنت، يقوم موجه الإيثرنت الذي يدعم بروتوكول PPPoE بإرسال إطارات الإيثرنت إلى مودم DSL (الذي يدعم بروتوكول PPPoE أيضًا). يقوم المودم باستخراج إطارات PPP من داخل إطارات PPPoE المستلمة، ثم يرسل إطارات PPP إلى وحدة DSLAM عن طريق تغليفها وفقًا لبروتوكول RFC 2364 (PPPoA)، وبالتالي تحويل PPPoE إلى PPPoA.

بنية الوصول إلى الإنترنت عبر خط المشترك الرقمي (DSL)
جهاز كمبيوتر أو بوابةمودم DSLDSLAMخادم الوصول عن بعد(مزود خدمة الإنترنت)
( IP )(IP)
إيثرنتبرنامج الشراكة بين القطاعين العام والخاصبرنامج الشراكة بين القطاعين العام والخاصبرنامج الشراكة بين القطاعين العام والخاصبرنامج الشراكة بين القطاعين العام والخاص
PPPoEPPPoEقانون حماية الأشخاص ذوي الإعاقةقانون حماية الأشخاص ذوي الإعاقةL2TPL2TP
إيثرنتإيثرنتAAL5AAL5العمود الفقريالعمود الفقريالملكية الفكريةالملكية الفكرية
صراف آليصراف آلي
DSLDSL

في الرسم التخطيطي، قد تكون المنطقة الموضحة باسم "العمود الفقري" هي نفسها منطقة ATM في الشبكات القديمة، إلا أن بنيتها تعتمد على مزود الخدمة. في رسم تخطيطي أكثر تفصيلاً ومخصصاً لمزود خدمة محدد، ستُضاف خلايا جدولية أخرى في هذه المنطقة.

غرائب

نظرًا لأن الاتصال المباشر بين نقطتين يتميز بوحدة نقل قصوى (MTU) أقل من وحدة نقل الإيثرنت القياسية (عادةً 1492 مقابل 1500 في الإيثرنت)، فقد يتسبب ذلك أحيانًا في مشاكل عند تعطيل اكتشاف وحدة النقل القصوى للمسار بواسطة جدران الحماية ذات الإعدادات غير المناسبة. على الرغم من أن وحدات النقل القصوى الأعلى أصبحت أكثر شيوعًا في شبكات مزودي الخدمة، إلا أن الحل المعتاد هو استخدام "تقييد" أو "إعادة كتابة" حجم مقطع TCP الأقصى (MSS)، حيث يقوم مُركِّز الوصول بإعادة كتابة حجم المقطع الأقصى لضمان إرسال نظراء TCP حزم بيانات أصغر. مع أن تقييد حجم مقطع TCP الأقصى يحل مشكلة وحدة النقل القصوى لبروتوكول TCP، إلا أن بروتوكولات أخرى مثل ICMP وUDP قد تتأثر.

يسمح RFC 4638 لأجهزة PPPoE بالتفاوض على MTU أكبر من 1492 إذا كانت طبقة Ethernet الأساسية قادرة على الإطارات الضخمة .

يميز بعض الموردين ( مثل سيسكو [ 17 ] وجونيبر ) بين PPPoE[oA] وPPPoEoE ( بروتوكول PPPoE عبر الإيثرنت)، وهو بروتوكول PPPoE يعمل مباشرةً عبر الإيثرنت أو شبكات IEEE 802 الأخرى أو عبر الإيثرنت الموصول بتقنية ATM ، وذلك لتمييزه عن PPPoEoA (بروتوكول PPPoE عبر ATM)، وهو بروتوكول PPPoE يعمل عبر دائرة افتراضية ATM باستخدام RFC 2684 وتغليف SNAP لبروتوكول PPPoE. (يختلف PPPoEoA عن بروتوكول نقطة إلى نقطة عبر ATM (PPPoA)، الذي لا يستخدم SNAP).

بحسب وثيقة من سيسكو، فإن "PPPoEoE هو نوع مُعدّل من PPPoE حيث يُستخدم بروتوكول نقل الطبقة الثانية الآن إيثرنت أو شبكة VLAN 802.1q بدلاً من ATM. تُستخدم طريقة التغليف هذه عادةً في بيئات Metro Ethernet أو مُضاعِف الوصول الرقمي لخط المشترك (DSLAM). ويُعدّ نموذج النشر الشائع هو استخدام هذه الطريقة في المباني متعددة المستأجرين أو الفنادق. ومن خلال توفير الإيثرنت للمشترك، يصبح عرض النطاق الترددي المتاح أكثر وفرة، وتزداد سهولة تقديم الخدمات اللاحقة." [ 17 ]

من الممكن العثور على مودمات DSL، مثل Draytek Vigor 120، حيث يقتصر بروتوكول PPPoE على وصلة الإيثرنت بين مودم DSL وجهاز التوجيه الشريك، ولا يستخدم مزود خدمة الإنترنت بروتوكول PPPoE على الإطلاق (بل يستخدم بروتوكول PPPoA ). [ 18 ]

استخدامات ما بعد تقنية DSL وبعض البدائل في هذه السياقات

حصلت شركة ZTE على براءة اختراع لطريقة معينة لاستخدام PPPoE بالتزامن مع GPON (والتي تتضمن إنشاء VLAN عبر OMCI ) . [ 19 ]

يُقال أن PPPoE عبر GPON يتم استخدامه من قبل مزودي خدمات التجزئة مثل Internode التابعة لشبكة النطاق العريض الوطنية الأسترالية ، [ 20 ] وOrange الفرنسية، [ 21 ] وAntel الأوروغوايانية، [ 22 ] و Globe Telecom الفلبينية [ 23 ] وAruba FTTH الإيطالية [ 24 ] على شبكات OpenFiber العامة GPON.

يستبعد RFC 6934، بعنوان "قابلية تطبيق آلية التحكم في عقدة الوصول على شبكات النطاق العريض القائمة على تقنية PON"، والذي يدعو إلى استخدام بروتوكول التحكم في عقدة الوصول في شبكات PON - من بين أمور أخرى - للتحقق من وصول المشتركين وإدارة عناوين IP الخاصة بهم، والذي كان مؤلفه الأول موظفًا في شركة Verizon، بروتوكول PPPoE كتغليف مقبول لشبكات GPON: "يعتمد تغليف البروتوكول في شبكات GPON على تغليف متعدد البروتوكولات عبر طبقة التكيف ATM 5 (AAL5)، المحددة في [RFC2684]. ويشمل ذلك بروتوكول PPP عبر الإيثرنت (PPPoE، المحدد في [RFC2516]) أو بروتوكول IP عبر الإيثرنت (IPoE). أما تغليف البروتوكول في شبكات GPON فهو دائمًا IPoE." [ 25 ]

يوفر معيار 10G-PON (XG-PON) (G.987) مصادقة 802.1X المتبادلة بين وحدة الشبكة الضوئية (ONU) ووحدة خط المحطة الضوئية (OLT)، بالإضافة إلى طريقة OMCI الموروثة من G.984 . [ 26 ] كما يدعم G.987 مصادقة أجهزة أخرى في مقر العميل غير وحدة الشبكة الضوئية (مثلًا في مبنى متعدد الوحدات السكنية)، مع العلم أن هذا الدعم يقتصر على منافذ الإيثرنت، والتي تُدار أيضًا عبر 802.1X. (في هذه الحالة، من المفترض أن تقوم وحدة الشبكة الضوئية بفحص رسائل RADIUS المغلفة ببروتوكول EAP لتحديد ما إذا كانت المصادقة ناجحة أم لا). [ 27 ] يوجد دعم محدود لبروتوكول PPPoE في معايير OMCI ، ولكن فقط من حيث قدرة وحدة الشبكة الضوئية على تصفية وإضافة علامات VLAN لحركة البيانات بناءً على تغليفها (ومعلمات أخرى)، مما يشمل PPPoE ضمن البروتوكولات التي يجب أن تكون وحدة الشبكة الضوئية قادرة على تمييزها. [ 28 ]

تنص وثيقة TR-200 الصادرة عن منتدى النطاق العريض بعنوان "استخدام EPON في سياق TR-101" (2011)، والتي تتعلق أيضًا بـ 10G-EPON ، على ما يلي: "يجب أن يكون كل من OLT وONU متعدد المشتركين قادرين على أداء وظيفة PPPoE Intermediate Agent، كما هو محدد في القسم 3.9.2/TR-101." [ 29 ]

يشير كتابٌ عن الإيثرنت في المرحلة الأولى إلى إمكانية استخدام بروتوكول DHCP بدلاً من PPPoE لتهيئة مضيف لجلسة IP، مع التنويه إلى أن DHCP ليس بديلاً كاملاً لـ PPPoE في حال الرغبة في إضافة طبقة تغليف (مع أن جسور VLAN قادرة على أداء هذه الوظيفة)، كما أن DHCP لا يوفر مصادقة (للمشترك)، مما يوحي بضرورة استخدام معيار IEEE 802.1X للحصول على "حل متكامل" دون الحاجة إلى PPPoE. [ 30 ] (يفترض هذا الكتاب استخدام PPPoE لميزات أخرى في بروتوكول PPP إلى جانب التغليف، بما في ذلك IPCP لتهيئة المضيف، و PAP أو CHAP للمصادقة).

توجد أسباب أمنية لاستخدام بروتوكول PPPoE في بيئة وسائط مشتركة (غير DSL/ATM)، مثل شبكات الاتصالات عبر خطوط الطاقة ، وذلك لإنشاء أنفاق منفصلة لكل عميل. [ 31 ]

يُستخدم بروتوكول PPPoE على نطاق واسع في خطوط WAN، بما في ذلك FTTx . وقد دمجت العديد من بوابات FTTx السكنية التي توفرها شركات تزويد خدمة الإنترنت وظائف التوجيه.

انظر أيضاً

مراجع

  1. جيمس بوني (2005). نظام التشغيل Cisco IOS باختصار . دار نشر O'Reilly Media، صفحة 88. ISBN  978-0-596-55311-1.
  2. 1 2 فيليب غولدن؛ هيرفيه ديديو؛ كريستا س. جاكوبسن (2007). تطبيق تقنية DSL . تايلور وفرانسيس. ص 479. ISBN  978-1-4200-1307-8.
  3. "كيفية إنشاء اتصال PPPoE في نظام التشغيل Windows XP" . مؤرشف من الأصل بتاريخ 3 ديسمبر 2013. تم الاطلاع عليه بتاريخ 11 ديسمبر 2013 .
  4. "تكوين نظام لينكس" . www.tldp.org . تم الاطلاع عليه بتاريخ 26 مارس 2019 .
  5. "الاتصال بالإنترنت باستخدام PPPoE (نظام التشغيل Mac OS X الإصدار 10.5 والإصدارات الأقدم)" . دعم Apple . تم الاطلاع عليه بتاريخ 26 مارس 2019 .
  6. استحوذت شركة Wind River Systems على شركة RouterWare, Inc. (Findarticles.com، 5 يوليو 1999). تم الاطلاع عليه بتاريخ 27 سبتمبر 2011. مؤرشف بتاريخ 26 مايو 2005 في أرشيف الإنترنت (Wayback Machine) .
  7. 1 2 مايكل بيك (2005). إيثرنت في الميل الأول : معيار IEEE 802.3ah EFM . ماكجرو هيل بروفيشنال. ص 27. ISBN   978-0-07-146991-3.
  8. ريتشارد د. جيتلين؛ سايليش ك. راو؛ جان جاك فيرنر؛ نيكولاس زيرفوس (8 مايو 1990). "طريقة وجهاز لنقل الإشارات الرقمية عبر نطاق ترددي واسع بين، على سبيل المثال، مكتب مركزي للهاتف ومباني العملاء" . براءة اختراع أمريكية رقم 4,924,492 .
  9. "شركة TouchWave تتعاون مع شركة Telogy Networks لتطوير برمجيات اتصالات VoIP المدمجة" . Business Wire . 5 أكتوبر 1998. تاريخ الاطلاع: 16 ديسمبر 2008 .
  10. "ما هو بروتوكول الاتصال من نقطة إلى نقطة عبر الإيثرنت (PPPoE)؟" . TechTarget . 20 أغسطس 2025. تم الاطلاع عليه بتاريخ 21 يناير 2026 .
  11. 1 2 3 4 5 ماماكوس، ل.؛ سيمون، د.؛ ويلر، ر.؛ كاريل، د.؛ إيفارتس، ج.؛ ليدل، ك. (فبراير 1999). "طريقة لنقل بروتوكول PPP عبر الإيثرنت (PPPoE)" . tools.ietf.org . doi : 10.17487/RFC2516 . تاريخ الاسترجاع : 26 مارس 2019 .
  12. 1 2 3 4 5 6 7 ديرك فان أكن، ساشا بيكلبين، تكاليف التغليف في شبكات الوصول ADSL، مؤرشف في 12 أبريل 2021 في Wayback Machine ، يونيو 2003
  13. 1 2 3 كايسي، مانو؛ غروس، جورج؛ ماليس، أندرو؛ ستيفنز، جون؛ لين، آرثر (يوليو 1998). "PPP عبر AAL5" . tools.ietf.org . doi : 10.17487/RFC2364 . تم الاطلاع عليه بتاريخ 26 مارس 2019 .
  14. 1 2 3 4 5 6 7 جروسمان، دان؛ هينانين، جحا (سبتمبر 1999). "تغليف البروتوكولات المتعددة عبر طبقة التكيف ATM 5" . Tools.ietf.org . دوى : 10.17487/RFC2684 . تم الاسترجاع في 26 مارس 2019 .
  15. 1 2 3 "مقالة سيمون فارنسورث" . farnz.org.uk . تم الاطلاع عليها بتاريخ 26 مارس 2019 .
  16. تكاليف التغليف الإضافية في شبكات الوصول ADSL.
  17. 1 2 "فهم تجميع الوصول إلى النطاق العريض" (ملف PDF) . أنظمة سيسكو . 2 مايو 2005.
  18. "Vigor120 - DrayTek Corp" . مؤرشف من الأصل بتاريخ 23 فبراير 2014. تم الاطلاع عليه بتاريخ 10 فبراير 2014 .
  19. "نظام شبكة ضوئية سلبية قادر على نقل البيانات بسرعة جيجابت، وبروتوكول نقطة إلى نقطة عبر طريقة تكوين الإيثرنت المُطبقة من خلاله" . google.com . تم الاطلاع عليه بتاريخ 26 مارس 2019 .
  20. "Internode :: الدعم :: الأدلة :: الوصول إلى الإنترنت :: NBN :: FTTP" . www.internode.on.net . مؤرشف من الأصل بتاريخ 13 سبتمبر 2013.     
  21. تم إطلاق مجتمع TP-Link الجديد رسميًا! - مجتمع TP-Link . community.tp-link.com . مؤرشف من الأصل بتاريخ 26 مارس 2019. تم الاطلاع عليه بتاريخ 26 مارس 2019 .
  22. "مقدمة عن Básica a Wi-Fi" . أنتيل (بالإسبانية). أنتيل.
  23. "يوتيوب" . www.youtube.com . مؤرشف من الأصل في 8 يونيو 2014. تم الاطلاع عليه في 26 مارس 2019 .
  24. ^ "تكوين جهاز التوجيه والمودم ADSL | دليل أروبا" . Guide.aruba.it . تم الاسترجاع في 10 مارس 2022 .
  25. بيطار، نبيل ن.؛ وادوا، سانجاي؛ هاج، توماس؛ هونغيو، لي (يونيو 2013). "RFC 6934 - قابلية تطبيق آلية التحكم في عقدة الوصول على شبكات النطاق العريض القائمة على الشبكات الضوئية السلبية (PONs)" . datatracker.ietf.org . تاريخ الاسترجاع: 26 مارس 2019 .
  26. ديف هود وإلمار تروجر (2012). الشبكات الضوئية السلبية القادرة على نقل البيانات بسرعة جيجابت . جون وايلي وأولاده. ص 200. ISBN  978-1-118-15558-5.
  27. ديف هود وإلمار تروجر (2012). الشبكات الضوئية السلبية القادرة على نقل البيانات بسرعة جيجابت . جون وايلي وأولاده. ص 207 و274-275. ISBN  978-1-118-15558-5.
  28. ديف هود وإلمار تروجر (2012). الشبكات الضوئية السلبية القادرة على نقل البيانات بسرعة جيجابت . جون وايلي وأولاده. ص 261 و271. ISBN  978-1-118-15558-5.
  29. "موارد منشورة من منتدى النطاق العريض - موارد - ويكي منتدى النطاق العريض" (ملف PDF) . www.broadband-forum.org . تاريخ الاطلاع: 31 مارس 2025 .
  30. مايكل بيك (2005). إيثرنت في الميل الأول : معيار IEEE 802.3ah EFM . ماكجرو هيل بروفيشنال. ص 241. ISBN   978-0-07-146991-3.
  31. كزافييه كارسيل (2009). اتصالات خطوط الطاقة في الممارسة العملية . دار أرتيك هاوس. ص 235. ISBN  978-1-59693-336-1.
  • RFC 2516 - طريقة لنقل بروتوكول PPP عبر الإيثرنت (PPPoE) 
  • RFC 3817 - بروتوكول النفق من الطبقة الثانية (L2TP) مرحل الاكتشاف النشط لبروتوكول PPP عبر الإيثرنت (PPPoE) 
  • RFC 4638 - استيعاب وحدة عبور قصوى / وحدة استقبال قصوى (MTU/MRU) أكبر من 1492 في بروتوكول نقطة إلى نقطة عبر الإيثرنت (PPPoE) 
  • RFC 4938 - امتدادات بروتوكول PPP عبر الإيثرنت (PPPoE) لتدفق الرصيد ومقاييس الارتباط 
  • براءة اختراع أمريكية رقم 6891825 - طريقة ونظام لتوفير وصول متعدد المستخدمين إلى شبكة تبديل الحزم
  • TR-043 - بروتوكولات واجهة U للوصول إلى شبكات البيانات باستخدام ATM/DSL، الإصدار 1.0، أغسطس 2001