المحتويات

المقدمة

إفتراض

ملخص عن التقنية

مزايا وعيوب بنية PPPoA

المزايا

مساوئ

اعتبارات التنفيذ لبنية PPPoA

بنية شبكة PPPoA نموذجية

اعتبارات التصميم لبنية PPPoA

النقاط الرئيسية لبنية PPPoA

إدارة IP

كيفية الوصول إلى وجهة الخدمة

الوصف التشغيلي لبنية PPPoA

القرار

معلومات ذات صلة

المقدمة

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

إفتراض

وتفترض البنية الأساسية الحاجة إلى توفير إمكانية الوصول السريع إلى الإنترنت والوصول إلى الشركات إلى المشترك النهائي باستخدام PPPoA كعمود فقري أساسي. سنناقش هذه البنية استنادا إلى القنوات الافتراضية الخاصة (PVCs)، وهي الطريقة المستخدمة في عمليات النشر الحالية في معظم الأحيان. ستتم مناقشة البنية التي تستخدم الدوائر الافتراضية المحولة (SVCs) في ورقة عمل منفصلة.

يستند هذا المستند إلى عمليات النشر الحالية بالإضافة إلى الاختبارات الداخلية الخاصة بالبنية.

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

ملخص عن التقنية

يوفر بروتوكول الاتصال من نقطة إلى نقطة (PPP) (RFC 1331) طريقة قياسية لتضمين بروتوكولات الطبقة العليا عبر إتصالات من نقطة إلى نقطة. إنه يقوم بتوسيع بنية حزمة التحكم في إرتباط البيانات عالية المستوى (HDLC) باستخدام معرف بروتوكول 16 بت الذي يحتوي على معلومات حول محتوى الحزمة.

تحتوي الحزمة على ثلاثة أنواع من المعلومات:

- بروتوكول التحكم في الارتباط (LCP) - يقوم بالتفاوض على معلمات الارتباط أو حجم الحزمة أو نوع المصادقة

- بروتوكول التحكم في الشبكة (NCP) - يحتوي على معلومات حول بروتوكولات الطبقات العليا بما في ذلك IP و IPX وبروتوكولات التحكم الخاصة بها (IPCP ل IP)

- إطارات البيانات التي تحتوي على بيانات

يستخدم PPP عبر طبقة ملاءمة ATM 5 (AAL5) (RFC 2364) AAL5 كبروتوكول إطار، والذي يدعم كلا من PVC و SVC. تم تنفيذ PPPoA في المقام الأول كجزء من ADSL. يعتمد على RFC1483، يعمل إما في بروتوكول الوصول إلى الشبكة الفرعية للتحكم في الارتباط المنطقي (LLC-SNAP) أو في وضع VC-Mux. يغلف جهاز أماكن عمل العميل (CPE) جلسة PPP استنادا إلى RFC هذا للنقل عبر حلقة ADSL وتجميع الوصول إلى خط المشترك الرقمي (DSLAM).

مزايا وعيوب بنية PPPoA

ترث بنية PPPoA معظم ميزات PPP المستخدمة في نموذج الطلب. وترد أدناه بعض النقاط الرئيسية.

المزايا

- تعتمد المصادقة لكل جلسة على بروتوكول مصادقة كلمة المرور (PAP) أو بروتوكول المصادقة لتأكيد الاتصال بقيمة التحدي (CHAP). وهذه هي الميزة الأكبر ل PPPoA حيث تتغلب المصادقة على ثقب الأمان في بنية جسر.

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

- حفظ عنوان IP في CPE. وهذا يسمح المزود خدمة أن يعين فقط واحد عنوان ل CPE، مع ال CPE يشكل لشبكة عنوان ترجمة (NAT). يمكن لجميع المستخدمين الذين وراء CPE واحد إستخدام عنوان IP واحد للوصول إلى وجهات مختلفة. يتم تقليل المصاريف الإضافية لإدارة IP لموفر الوصول إلى الشبكة/موفر خدمات الشبكة (NAP/NSP) لكل مستخدم فردي أثناء حفظ عناوين IP. وبالإضافة إلى ذلك، يمكن أن يوفر مزود الخدمة شبكة فرعية صغيرة من عناوين IP للتغلب على قيود ترجمة عنوان المنفذ (PAT) و NAT.

- توفر بطاقات NAP/NSPs إمكانية الوصول الآمن إلى بوابات الشركة دون إدارة مصابيح PVC الشاملة واستخدام توجيه من الطبقة 3 أو أنفاق بروتوكول إعادة التوجيه/الاتصال النفقي من الطبقة 2 (L2F/L2TP). وبالتالي، يمكنهم توسيع نماذجهم التجارية لبيع خدمات الجملة.

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

- يمكن أن يزيد NSP عن اشتراكه عن الحد بواسطة نشر فترات انتهاء المهلة في وضع الخمول والجلسة باستخدام خادم خدمة مصادقة المستخدم عن بعد (RADIUS) القياسي في مجال الصناعة لكل مشترك.

- قابل للتطوير بدرجة كبيرة حيث يمكننا إنهاء عدد كبير جدا من جلسات بروتوكول الاتصال من نقطة إلى نقطة (PPP) على موجه تجميع. يمكن التعامل مع المصادقة والتفويض والمحاسبة لكل مستخدم باستخدام خوادم RADIUS الخارجية.

- الاستخدام الأمثل للميزات الموجودة على بوابة تحديد الخدمة (SSG).

مساوئ

- جلسة واحدة فقط لكل CPE على قناة ظاهرية واحدة (VC). بما أن username وكلمة شكلت على ال CPE، كل مستعمل خلف ال CPE ل أن VC خاص يستطيع نفذت فقط مجموعة واحد من الخدمات . لا يمكن للمستخدمين تحديد مجموعات مختلفة من الخدمات، على الرغم من إمكانية إستخدام مجموعات VCs متعددة وإنشاء جلسات PPP مختلفة على مجموعات VCs مختلفة.

- زيادة تعقيد إعداد CPE. يجب أن يكون موظفو مكتب المساعدة لدى مزود الخدمة أكثر دراية. بما أن ال username وكلمة يكون شكلت على ال CPE، المشترك أو ال CPE بائع يحتاج أن يجعل setup تغير. إن إستخدام VCs متعددة يزيد من تعقيد تشكيل. ومع ذلك، يمكن التغلب على هذا الأمر من خلال ميزة التكوين التلقائي التي لم يتم إصدارها بعد.

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

- إذا تم توفير عنوان IP واحد إلى CPE و NAT/PAT يتم تنفيذه، فإن بعض التطبيقات مثل IPTV، والتي تقوم بدمج معلومات IP في الحمولة، لن تعمل. وبالإضافة إلى ذلك، إذا تم إستخدام ميزة شبكة IP الفرعية، فيجب أيضا حجز عنوان IP ل CPE.

اعتبارات التنفيذ لبنية PPPoA

تشمل النقاط الرئيسية التي يتعين النظر فيها قبل تنفيذ بنية PPPoA ما يلي:

- عدد المشتركين الذين ستتم صيانتهم حاليا وفي المستقبل، لأن هذا يؤثر على عدد جلسات PPP المطلوبة.

- ما إذا كان يتم إنهاء جلسات PPP في موجه التجميع الخاص بمزود الخدمة أو يتم إعادة توجيهها إلى بوابات الشركة الأخرى أو إلى موفري خدمة الإنترنت (ISPs).

- ما إذا كان مزود الخدمة أو وجهة الخدمة النهائية يوفر عنوان IP إلى CPE الخاص بالمشترك.

- ما إذا كانت عناوين IP المقدمة عامة أو خاصة قانونية. هل سيقوم CPE ب NAT/PAT أم سيتم إجراء NAT في وجهة الإنهاء؟

- ملفات تعريف المشتركين النهائيين والمستخدمين المقيمين وعملاء المكاتب المنزلية الصغيرة (SOHO) والمستخدمين عن بعد.

- في حالة وجود أكثر من مستخدم واحد، ما إذا كان جميع المستخدمين بحاجة إلى الوصول إلى نفس الوجهة النهائية أو الخدمة النهائية، أو أن لديهم جميعا وجهات خدمة مختلفة.

- هل يقدم مزود الخدمة أي خدمات ذات قيمة مضافة مثل الصوت أو الفيديو؟ هل يتطلب مزود الخدمة من جميع المشتركين الانتقال أولا إلى شبكة معينة قبل الوصول إلى وجهة نهائية؟ عندما يستخدم المشتركون SSG، هل سيقومون باستخدام خدمات المرور، أو تجميع PPP المنهي (PTA)، أو جهاز وسيط، أو وكيل؟

- كيف يقوم موفر الخدمة بتصنيف المشتركين - استنادا إلى معدل ثابت أو إستخدام جلسة عمل أو الخدمات المستخدمة.

- نشر وتوفير CPEs و DSLAMs ونقاط تجميع التواجد (POPs).

- نموذج العمل ل NAP. وهل يتضمن النموذج أيضا بيع خدمات الجملة مثل تأمين الوصول إلى الشركات والخدمات ذات القيمة المضافة مثل الصوت والفيديو؟ هل برامج العمل الوطنية وبرامج العمل الوطنية هي نفس الكيان؟

- النموذج الإقتصادي للشركة. هل يمكن مقارنتها مع شركة نقل محلية مستقلة (ILEC) أو شركة نقل محلية تنافسية (CLEC) أو مزود خدمة الإنترنت (ISP)؟

- أنواع التطبيقات التي سيقدمها NSP للمشترك النهائي.

- الحجم المتوقع لتدفق البيانات من الخادم والتدفق من الخادم.

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

بنية شبكة PPPoA نموذجية

يوضح المخطط التالي بنية شبكة PPPoA نموذجية. يتصل العملاء الذين يستخدمون CPEs بشبكة مزود الخدمة من خلال DSLAM من Cisco، والتي تتصل بمجمع Cisco 6400 باستخدام ATM.

اعتبارات التصميم لبنية PPPoA

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

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

في حالة الوصول السريع إلى الإنترنت في بيئة تكون فيها NSP و NAP متشابهين، يجب إنهاء جلسات PPP الخاصة بالمشترك في موجه التجميع المنشور. في هذا السيناريو، يحتاج موفرو الخدمة إلى الأخذ في الاعتبار عدد جلسات PPP التي يمكن إنهاؤها على جهاز تجميع موجه واحد، وكيفية مصادقة المستخدمين، وكيفية قيامهم بإجراء المحاسبة، والمسار إلى الإنترنت بمجرد إنهاء جلسات عمل المستخدم. استنادا إلى عدد جلسات عمل PPP والمشتركين، يمكن أن يكون موجه التجميع إما Cisco 6400 أو Cisco 7200. يمكن ل Cisco 6400 اليوم مع معالجات مسار العقد 7 (NRPs) إنهاء ما يصل إلى 14000 جلسة PPP. يقتصر Cisco 7200 على 2000 جلسة PPP. ستتغير هذه الأرقام مع الإصدارات الجديدة. يرجى التحقق من ملاحظات الإصدار ومستندات المنتج لمعرفة عدد جلسات العمل بالضبط التي يمكن لكل موجه تجميع أن يدعمها.

تتم معالجة مصادقة المستخدم ومحاسبته في هذا السيناريو على أفضل نحو باستخدام خادم RADIUS متوافق مع معايير الصناعة، والذي يمكنه مصادقة مستخدم استنادا إلى اسم المستخدم أو معرف المسار الظاهري/معرف القناة الظاهرية (VPI/VCI) المستخدم.

بالنسبة للوصول السريع إلى الإنترنت، عادة ما تقوم NSP بتصنيف سعر ثابت للعملاء. يتم تنفيذ معظم عمليات النشر الحالية بهذه الطريقة. عندما تكون NSP و NAP كيانا واحدا، تتم فوترة العملاء بمعدل ثابت للوصول إلى الإنترنت ومعدل ثابت آخر للوصول إلى الإنترنت. يتغير هذا النموذج عندما يبدأ مزود الخدمة في تقديم خدمات القيمة المضافة. يمكن لمزودي الخدمة فرض رسوم على العميل استنادا إلى نوع الخدمة والمدة التي يتم فيها إستخدام الخدمة. يتصل العملاء بالإنترنت من خلال موجه التجميع باستخدام بروتوكولات التوجيه مثل فتح أقصر مسار أولا (OSPF) أو بروتوكول التوجيه المحسن للعبارة الداخلية (EIGRP) إلى موجه حافة قد يكون يشغل بروتوكول العبارة الحدودية (BGP).

هناك خيار آخر لدى موفر الخدمة لتوفير الوصول السريع إلى الإنترنت وهو إعادة توجيه جلسات PPP الواردة من المشتركين إلى ISP منفصل باستخدام اتصال L2TP/L2F النفقي. عند إستخدام اتصال L2x النفقي، يجب إيلاء إعتبار خاص لكيفية الوصول إلى وجهة النفق. الخيارات المتاحة هي إما لتشغيل بعض بروتوكولات التوجيه أو توفير مسارات ثابتة في موجه التجميع. القيود عند إستخدام أنفاق L2TP أو L2F هي: (1) عدد الأنفاق وعدد الجلسات التي يمكن دعمها في هذه الأنفاق؛ و(2) إستخدام بروتوكولات التوجيه غير المتوافقة مع موجهات خدمات الإنترنت (ISPs) من الطرف الثالث، والتي قد تتطلب إستخدام المسارات الثابتة.

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

في نموذج خدمة الجملة، قد لا يستخدم مزود الخدمة ميزات SSG. في هذا النموذج، يقوم مزود الخدمة بتوسيع جميع جلسات PPP إلى البوابات الرئيسية. توفر البوابات الرئيسية عناوين IP للمشترك النهائي وتصادق المستخدم النهائي.

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

يتطلب تطبيق جودة الخدمة في الطبقة 3 أن يعرف مزود الخدمة الوجهة النهائية، والتي يمكن أن تكون عامل تحديد. ولكن، إذا تم إستخدامها مع جودة الخدمة من الطبقة 2 (بتطبيقها على VCs مختلفة)، يمكن أن تكون مفيدة لمزود الخدمة. يكمن القيد في هذا النموذج في أنه ثابت ويحتاج مزود الخدمة إلى توفير جودة الخدمة بشكل مسبق. لا يتم تطبيق جودة الخدمة بشكل ديناميكي على تحديد الخدمة. حاليا، لا يوجد خيار للمستخدم لاختيار طرق عرض مختلفة لخدمات مختلفة بنقرة على الماوس، ومع ذلك، فقد تم أستثمار جهد هندسي كبير لتطوير هذه الميزة.

قد يكون نشر CPE وإدارته وإمداده صعبا للغاية في هذه البنية، نظرا لأنه يلزم تكوين CPE لأسماء المستخدمين وكلمات المرور. كحل بسيط، يستخدم بعض مزودي الخدمة نفس اسم المستخدم وكلمة المرور لجميع CPEs. وهذا يمثل خطرا أمنيا كبيرا. بالإضافة إلى ذلك، إذا كان يجب على مركز التدريب الموحد فتح جلسات مختلفة في نفس الوقت، فإنه يلزم توفير مراكز افتراضية إضافية في كل من CPE و NAP و NSP. تتمتع أجهزة DSLAM وأجهزة التجميع من Cisco بالقدرة على تبسيط تهيئة وإمداد CPE. تتوفر أيضا أدوات الإدارة المتدفقة من أجل توفير PVC الشامل. الإمداد في NSP للعديد من المشتركين الذين يستخدمون PVCs هو عامل تحديد نظرا لأنه يجب إدارة جميع شبكات PVC المختلفة. وبالإضافة إلى ذلك، لا توجد طريقة بسيطة لتوفير 2000 وحدة PVCs على بروتوكول NRP واحد من خلال النقر بالماوس أو إدخال عدد قليل من ضغطات المفاتيح.

اليوم لدينا تطبيقات إدارة مختلفة لمكونات مختلفة لهذه البنية، مثل VideoNer ل DSLAM و SCM ل Cisco 6400، لا يوجد نظام إدارة واحد يوفر جميع المكونات. ويعد هذا قيدا معترفا به جيدا، ويتم أستثمار جهد كبير للحصول على تطبيق إدارة واحد وشامل لتوفير CPE و DSLAM و Cisco 6400. وبالإضافة إلى ذلك، لدينا حاليا حل لتنفيذ الشراكات بين القطاعين العام والخاص مع إتفاقية بازل، الأمر الذي سيسهل عملية النشر إلى حد كبير. كما سيسمح PPPoA مع SVC للمستخدمين النهائيين بتحديد الوجهة و QoS بشكل ديناميكي.

هناك نقطة أخرى مهمة يجب أن نضعها في الاعتبار لعمليات نشر ADSL الكبيرة باستخدام هذه البنية وهي الاتصال من موجه التجميع إلى خادم RADIUS. إذا فشل خادم NRP المتعدد عند إنهاء عدة آلاف من جلسات PPP على جهاز تجميع، فيجب إعادة إنشاء جميع جلسات PPP هذه. وهذا يعني أنه يجب مصادقة جميع المشتركين ووقف سجلات حساباتهم وإعادة تشغيلها بمجرد تأسيس الاتصال. عندما يحاول العديد من المشتركين التصديق عليهم في نفس الوقت، يمكن أن يكون التوجيه إلى خادم RADIUS عقبة. قد يتعذر مصادقة بعض المشتركين وقد يؤدي ذلك إلى حدوث مشاكل لموفر الخدمة.

من المهم جدا أن يكون لديك إرتباط بخادم RADIUS بعرض نطاق ترددي كاف لاستيعاب جميع المشتركين في نفس الوقت. علاوة على ذلك، يجب أن يكون خادم RADIUS قويا بما يكفي لمنح الأذونات لجميع المشتركين. في حالة آلاف المشتركين، يجب النظر في خيار موازنة التحميل بين خوادم RADIUS المتاحة. تتوفر هذه الميزة في برنامج Cisco IOS®.

كإعتبار نهائي، يجب أن يعمل موجه التجميع بشكل كاف لاستيعاب العديد من جلسات PPP. تطبيق نفس مبادئ هندسة حركة المرور المستخدمة من قبل عمليات التنفيذ الأخرى. سابقا، كان على المستخدم تكوين PVCs على الواجهات الفرعية من نقطة إلى نقطة. يتيح PPPoA اليوم للمستخدمين تكوين شبكات PVC متعددة على الواجهات الفرعية متعددة النقاط وكذلك من نقطة إلى نقطة. لم يعد كل اتصال PPPoA يتطلب قطعتي واصف واجهة (IDBs)، واحدة لواجهة الوصول الظاهري وواحدة لواجهة ATM الفرعية. يزيد هذا التحسين الحد الأقصى لعدد جلسات عمل PPPoA التي يتم تشغيلها على موجه.

يعتمد الحد الأقصى لعدد جلسات عمل PPPoA المدعومة على نظام أساسي على موارد النظام المتاحة مثل الذاكرة وسرعة وحدة المعالجة المركزية. تتخذ كل جلسة PPPoA واجهة وصول افتراضية واحدة. تتكون كل واجهة وصول افتراضية من كتلة واصف لواجهة الأجهزة وزوج كتلة واصف واجهة البرامج (hwidb/swidb). كل هاودب يأخذ حوالي 4.5 ألف. كل عرض يأخذ حوالي 2.5 ألف. وتتطلب واجهات الوصول الظاهرية معا توفر واجهات وصول افتراضية بسرعة 7. 5 ألف لفة في الدقيقة. أما واجهات الوصول الظاهرية طراز 2000 فتتطلب 2000 × 7. 5 ألف لفة في الدقيقة أو 15 مليون لفة في الدقيقة. لتشغيل جلسات عمل 2000، يحتاج الموجه إلى 15M إضافية. بسبب الزيادة في حد جلسة العمل، يحتاج الموجه إلى دعم المزيد من قواعد البيانات IDB. يؤثر هذا الدعم على الأداء بسبب زيادة دورات وحدة المعالجة المركزية (CPU) لتشغيل المزيد من مثيلات جهاز حالة بروتوكول الاتصال من نقطة إلى نقطة (PPP).

النقاط الرئيسية لبنية PPPoA

يصف هذا القسم ثلاث نقاط أساسية في بنية PPPoA: وهي: CPE وإدارة IP والوصول إلى وجهة الخدمة.

نظرا لطبيعة ضرب، فإن بعض التطبيقات التي تقوم بدمج معلومات IP في الحمولة لا يمكن أن تعمل في هذا السيناريو. لحل هذه المشكلة، قم بتطبيق شبكة فرعية من عناوين IP بدلا من عنوان IP واحد.

في هذه البنية، من الأسهل على NAP/NSP أن يقوم Telnet في CPE بتكوين عنوان IP واستكشاف أخطائه وإصلاحها نظرا لأنه تم تعيين عنوان IP إلى CPE.

يمكن أن تستخدم CPEs خيارات مختلفة بناء على ملف تعريف المشترك. على سبيل المثال، بالنسبة لمستخدم سكني، قد يتم تكوين CPE بدون PAT/DHCP. بالنسبة للمشتركين الذين لديهم أكثر من جهاز كمبيوتر واحد، يمكن تكوين نقاط الوصول الخاصة بالمنفذ (CPE) إما ل PAT/DHCP أو بنفس طريقة تكوين المستخدم المقيم. إذا كان هناك هاتف IP متصل ب CPE، فقد يتم تكوين CPE لأكثر من PVC واحد.

إدارة IP

في بنية PPPoA، يستخدم تخصيص عنوان IP الخاص بالمشترك CPE تفاوض IPCP، وهو نفس مبدأ PPP في وضع الطلب. يتم تخصيص عناوين IP حسب نوع الخدمة التي يستخدمها المشترك. إذا كان المشترك لديه حق الوصول إلى الإنترنت فقط من NSP، فإن NSP سيقوم بإنهاء جلسات PPP هذه من المشترك وسيعين عنوان IP. يتم تخصيص عنوان IP من تجمع محدد محليا، أو خادم DHCP، أو يمكن تطبيقه من خادم RADIUS. أيضا، ال isp أمكن زودت مجموعة من العنوان ساكن إستاتيكي إلى المشترك وقد لا يعين عنوان ديناميكيا عندما المشترك يهيئ ال PPP جلسة. في هذا السيناريو، يستخدم مزود الخدمة خادم RADIUS فقط لمصادقة المستخدم.

إذا فضل المشترك توفر خدمات متعددة، فقد يحتاج NSP إلى تنفيذ SSG. فيما يلي إمكانيات تعيين عناوين IP.

- قد يوفر SP عنوان IP للمشترك من خلال التجمع المحلي أو خادم RADIUS الخاص به. بعد أن يقوم المستخدم بتحديد خدمة، تقوم SSG بإعادة توجيه حركة مرور المستخدم إلى تلك الوجهة. إذا كانت SSG تستخدم وضع الوكيل، فقد توفر الوجهة النهائية عنوان IP، والذي ستستخدمه SSG كعنوان مرئي ل NAT.

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

قبل الإصدار 12.0.5DC من برنامج Cisco IOS Software ل NRP ل Cisco 6400، لم تكن هناك طريقة لمزود الخدمة لتوفير شبكة فرعية من عناوين IP للمشترك. يسمح النظام الأساسي Cisco 6400 و Cisco 600 Series CPEs بتكوين الشبكات الفرعية IP بشكل ديناميكي على CPE أثناء تفاوض PPP. يتم تعيين عنوان IP واحد من هذه الشبكة الفرعية إلى CPE ويتم تخصيص عناوين IP المتبقية بشكل ديناميكي للمحطات من خلال DHCP. عندما استعملت هذا سمة، لا يحتاج CPEs أن يكون شكلت ل PAT، أي لا يعمل مع بعض تطبيق.

كيفية الوصول إلى وجهة الخدمة

في بنيات PPPoA، يمكن الوصول إلى وجهة الخدمة بطرق مختلفة. وفيما يلي بعض الأساليب الأكثر انتشارا:

- إنهاء جلسات PPP في مزود الخدمة

- اتصال L2TP النفقي

- إستخدام SSG

في كل الطرق الثلاثة هناك مجموعة ثابتة من PVCs يعين من ال CPE إلى DSLAM أن يكون حولت إلى مجموعة ثابتة من PVCs على التجميع مسحاج تخديد. يتم تعيين دوائر PVC من DSLAM إلى موجه التجميع من خلال سحابة ATM.

كما يمكن الوصول إلى وجهة الخدمة باستخدام طرق أخرى مثل PPPoA باستخدام SVCs أو Multiprotocol Label Switching/Virtual Private Network. وتتجاوز هذه الأساليب نطاق هذه الوثيقة وستناقش في ورقات منفصلة.

إنهاء PPP عند التجميع

يتم إنهاء جلسات PPP التي بدأها المشترك في موفر الخدمة الذي يصادق المستخدمين باستخدام قاعدة بيانات محلية على الموجه أو من خلال خوادم RADIUS. بعد مصادقة المستخدم، يتم تفاوض IPCP ويتم تعيين عنوان IP إلى CPE. بعد تعيين عنوان IP، هناك مسار مضيف تم إنشاؤه على CPE وعلى موجه التجميع. يتم الإعلان عن عناوين IP المخصصة للمشترك، إذا كانت قانونية، إلى موجه الحافة. موجه الحافة هو البوابة التي من خلالها يمكن للمشترك الوصول إلى الإنترنت. إذا كانت عناوين IP خاصة، يقوم مزود الخدمة بترجمتها قبل إعلانها إلى موجه الحافة.

اتصال L2TP/L2F النفقي

تقوم جلسات PPP، وفقا لمزود الخدمة أو الشركة، بالانتقال إلى نقطة الإنهاء للتحميل باستخدام L2TP أو L2F بدلا من الإنهاء على موجه التجميع الخاص بمزود الخدمة. تصادق نقطة الإنهاء هذه اسم المستخدم ويتم تعيين عنوان IP للمشترك عبر DHCP أو تجمع محلي. بالنسبة لهذا السيناريو، عادة ما يكون هناك نفق واحد تم إنشاؤه بين مركز الوصول إلى L2TP/خادم الوصول إلى الشبكة (LAC/NAS) والبوابة الرئيسية أو خادم شبكة L2TP (LNS). يصادق LAC الجلسة الواردة بناء على اسم المجال؛ ويصادق اسم المستخدم في الوجهة النهائية أو البوابة الرئيسية.

ومع ذلك، في هذا النموذج، يمكن للمستخدم الوصول إلى الوجهة النهائية فقط ويمكنه الوصول إلى وجهة واحدة فقط في كل مرة. مثلا، إن شكلت ال CPE يكون مع username من rtr@cisco.com، ال pcS خلف أن CPE يستطيع فقط يتلقى منفذ إلى ال cisco مجال. إن يريد هم أن يربط إلى آخر شركة شبكة، هم يحتاجون أن يغير ال username وكلمة على ال CPE أن يعكس أن الشركة domain name. يتم الوصول إلى وجهة النفق في هذه الحالة باستخدام بروتوكول توجيه أو مسارات ثابتة أو تنفيذ IP التقليدي عبر ATM (إذا كان يفضل ATM كطبقة 2).

إستخدام عبارة تحديد الخدمة (SSG)

والميزة الرئيسية لبروتوكول SSG عبر الاتصال النفقي هي أن بروتوكول SSG يوفر خرائط للخدمات من خادم إلى عدة خدمات، في حين أن الاتصال النفقي يوفر فقط تعيين من شخص إلى آخر. ويصبح ذلك مفيدا للغاية عندما يحتاج مستخدم واحد إلى الوصول إلى خدمات متعددة، أو عدة مستخدمين في موقع واحد ويحتاج كل منهم إلى الوصول إلى خدمة فريدة. تستخدم SSG لوحة معلومات تحديد الخدمة (SSD) المستندة إلى الويب، والتي تتكون من خدمات مختلفة ومتاحة للمستخدم. يمكن للمستخدم الوصول إلى خدمة واحدة أو خدمات متعددة في وقت واحد. هناك ميزة أخرى لاستخدام SSG وهي أنه يمكن لمزود الخدمة إعداد فاتورة للمستخدم استنادا إلى الخدمات المستخدمة ووقت الجلسة، ويمكن للمستخدم تشغيل الخدمات وإيقاف تشغيلها من خلال SSD.

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

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

يمكن تكوين SSG لخدمة الوكيل أو المرور الشفاف أو PTA. عندما يطلب المشترك الوصول إلى خدمة وكيل، يقوم NRP-SSG بتمرير طلب الوصول إلى خادم RADIUS البعيد. عند تلقي قبول الوصول، تستجيب SSG للمشترك بقبول الوصول. تظهر SSG كعميل لخادم RADIUS البعيد.

يسمح المرور الشفاف بتوجيه حركة مرور المشترك غير المصدق عليها من خلال SSG في أي من الاتجاهين. أستخدم عوامل التصفية للتحكم في حركة المرور الشفافة.

يمكن إستخدام PTA فقط من قبل مستخدمي نوع PPP. يتم إجراء المصادقة والتفويض والمحاسبة تماما كما هو الحال في نوع خدمة الوكيل. يقوم مشترك بتسجيل الدخول إلى خدمة باستخدام اسم مستخدم للنموذج user@service. تعيد SSG ذلك إلى خادم RADIUS، والذي يقوم بعد ذلك بتحميل ملف تعريف الخدمة إلى SSG. تقوم SSG بإعادة توجيه الطلب إلى خادم RADIUS البعيد كما هو محدد بواسطة سمة خادم RADIUS الخاصة بملف تعريف الخدمة. بعد مصادقة الطلب، يتم تعيين عنوان IP للمشترك. لا يتم إجراء NAT. يتم تجميع كل حركة مرور المستخدم إلى الشبكة البعيدة. باستخدام PTA، يمكن للمستخدمين الوصول إلى خدمة واحدة فقط ولن يكون لديهم حق الوصول إلى الشبكة الافتراضية أو محرك أقراص SSD.

الوصف التشغيلي لبنية PPPoA

عند تشغيل CPE لأول مرة، فإنه يبدأ في إرسال طلبات تكوين LCP إلى خادم التجميع. كما يرسل خادم التجميع، مع وحدات PVC التي تم تكوينها، طلب تكوين LCP على واجهة الوصول الظاهرية (المقترنة ببروتوكول PVC). عندما يرى كل واحد طلب تكوين الآخر، فإنه يقر بالطلبات ويتم فتح حالة LCP.

بالنسبة لمرحلة المصادقة، يرسل CPE طلب المصادقة إلى خادم التجميع. يقوم الخادم، وفقا لتكوينه، بمصادقة المستخدم استنادا إلى اسم المجال (في حالة توفيره)، أو اسم المستخدم باستخدام قاعدة البيانات المحلية أو خوادم RADIUS الخاصة به. إذا كان الطلب من المشترك في شكل username@domainname، فسيحاول خادم التجميع إنشاء نفق إلى الوجهة، إذا لم يكن هناك واحد بالفعل. بعد إنشاء النفق، يقوم خادم التجميع بإعادة توجيه طلبات PPP من المشترك إلى الوجهة. والغاية، بدوره، يصادق المستعمل ويعين عنوان. إذا لم يتضمن الطلب من المشترك اسم المجال، تتم مصادقة المستخدم بواسطة قاعدة البيانات المحلية. إذا تم تكوين SSG على موجه التجميع، يمكن للمستخدم الوصول إلى الشبكة الافتراضية كما هو محدد ويمكنه الحصول على خيار تحديد خدمات مختلفة.

القرار

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

معلومات ذات صلة

- معلومات دعم منتج DSL من Cisco

- الدعم الفني - Cisco Systems