التشبيك المتقدم Advanced Internetworking في الشبكات الحاسوبية

مشكلة التوسع إلى المليارات Scaling to Billions لقد رأينا الآن كيفية بناء شبكةٍ متشابكة internetwork تتكون من عدة شبكاتٍ ذات أنواعٍ مختلفة. أي أننا تعاملنا مع مشكلة عدم التجانس heterogeneity. المشكلة الحرجة الثانية في التشبيك internetworking، ويمكن القول أنها المشكلة الأساسية لجميع الشبكات، هي التوسّع scale. يجدر النظر في نمو الإنترنت لفهم مشكلة توسّع شبكة، حيث تضاعف حجم الإنترنت تقريبًا كلَّ عام خلال 30 عامًا. يدفعنا هذا النوع من النمو إلى مواجهة عدة تحديات.

ومن أهم هذه التحديات كيفية بناء نظام توجيه يمكنه التعامل مع مئات الألوف من الشبكات ومليارات العقد النهائية. تعتمد معظم الطرق لمعالجة قابلية التوسّع في التوجيه على استخدام الهرمية hierarchy كما سنرى في هذا الفصل. يمكن تقديم الهرمية في شكل مناطق areas داخل نطاق domain، حيث نستخدم أيضًا الهرمية لتوسيع نظام التوجيه بين النطاقات interdomain. بروتوكول التوجيه بين النطاقات الذي مكّن الإنترنت من التوسع إلى حجمه الحالي هو بروتوكول BGP. سنلقي نظرة على كيفية عمل بروتوكول BGP، وعلى التحديات التي يواجهها مع استمرار نمو الإنترنت.

ترتبط مشكلة العنونة ارتباطًا وثيقًا بقابلية التوسع، إذ أصبح من الواضح أن مخطط العنونة 32 بت للإصدار 4 (IP version 4) من بروتوكول IP لن يستمر بعد عقدين من الزمن، وقد أدى ذلك إلى تعريف إصدارٍ جديد من بروتوكول IP، وهو الإصدار 6 (IP version 6)، حيث اُستخدم الإصدار 5 في تجربة سابقة. يوسّع IPv6 حيز العناوين بشكل أساسي ولكنه يضيف أيضًا عددًا من الميزات الجديدة، والتي عُدِّل بعضها تحديثًا للإصدار IPv4.

طالما أن الإنترنت يستمر في النمو من حيث الحجم، فإنه يحتاج أيضًا إلى تطوير وظائفه. تغطّي الأقسام الأخيرة من هذا الفصل بعض التحسينات الهامة لإمكانات الإنترنت. التحسين الأول هو البث المتعدد multicast والذي هو تحسين لِنموذج الخدمة الأساسية. سنوضح كيفية دمج البث المتعدد، وهو القدرة على توصيل نفس الرزم إلى مجموعة من المستقبلات بكفاءة، ضمن الإنترنت، وسنشرح العديد من بروتوكولات التوجيه التي طُوِّرت لدعم البث المتعدد. التحسين الثاني هو تبديل التسمية متعددة البروتوكولات Multiprotocol Label Switching أو اختصارًا MPLS الذي يعدّل آلية تمرير شبكات IP. وقد أتاح هذا التعديل إجراء بعض التغييرات في طريقة تنفيذ توجيه IP وفي الخدمات التي تقدمها شبكات IP. أخيرًا، سننظر في تأثيرات التنقّل mobility على التوجيه ووصف بعض التحسينات على بروتوكول IP لدعم المضيفين والموجّهات المتنقلة. لا تزال قضايا قابلية التوسع مهمةً لكلٍّ من هذه التحسينات.

الإنترنت العالمي Global Internet

رأينا كيفية توصيل مجموعةٍ غير متجانسة من الشبكات لإنشاء شبكة متشابكة وكيفية استخدام الهرمية البسيطة لعنوان IP لجعل التوجيه في الإنترنت قابلًا للتوسّع إلى حدٍ ما. نقول إنه قابل للتوسع "إلى حدٍ ما"، لأنه على الرغم من أن كل موجهٍ لا يحتاج إلى معرفة جميع المضيفين المتصلين بالإنترنت، إلا أنه في النموذج الموصوف حتى الآن يحتاج إلى معرفة جميع الشبكات المتصلة بالإنترنت. يحتوي الإنترنت اليوم مئات الألوف من الشبكات المتصلة به أو أكثر من ذلك. ولكن لا تتوسّع بروتوكولات التوجيه مثل تلك التي ناقشناها سابقًا إلى هذه الأرقام. يبحث هذا القسم في مجموعة متنوعة من التقنيات التي تعمل على تحسين قابلية التوسُّع بصورة كبيرة والتي مكّنت الإنترنت من النمو بقدر ما هو عليه الآن.

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

تتمثل إحدى سمات هذا الهيكل البارزة في أنه يتكون من مواقع المستخدم النهائي end-user sites، كَجامعة ستانفورد Stanford University على سبيل المثال، التي تتصل بشبكات مزود الخدمة (كانت شبكة BARRNET عبارةً عن شبكة مزود خدمة المواقع في منطقة خليج سان فرانسيسكو على سبيل المثال). خدّم العديد من مزوّدي الخدمة منطقةً جغرافية محدودة في عام 1990، وبالتالي عُرفوا باسم الشبكات الإقليمية regional networks. ارتبطت الشبكات الإقليمية، بدورها، بشبكة رئيسية وطنية nationwide backbone، حيث موّلت مؤسسة العلوم الوطنية National Science Foundation أو اختصارًا NSF هذه الشبكة في عام 1990، وبالتالي كانت تُسمى NSFNET backbone.

أفسحت شبكة NSFNET الطريق لشبكة Internet2، التي لا تزال تدير الشبكة الرئيسية backbone هذه نيابة عن مؤسسات البحث Research والتعليم Education في الولايات المتحدة (توجد شبكات R & E مماثلة لها في بلدان أخرى)، ولكن بالطبع يحصل معظم الناس على اتصالهم بالإنترنت من مزودي الخدمات التجاريين. تُبنى شبكات المزود الأكبر اليوم (يطلق عليها المستوى 1 وبالأجنبية tier-1) عادةً من عشرات الموجّهات المتطورة الموجودة في مناطق المدينة الرئيسية (يشار إليها بالعامية باسم مدن NFL) المتصلة بواسطة روابط من نقطة لنقطة (غالبًا بسعة 100 جيجابت في الثانية). لا يكون كل موقع مستخدمٍ نهائي عادةً شبكةً واحدة، ولكنه يتكون بدلًا من ذلك من شبكات فيزيائية متعددة متصلة بواسطة مبدّلات switches وموجّهات routers.

لاحظ أنه من المحتمل أن يكون كل مزودٍ ومستخدمٍ نهائي كيانًا مستقلًا إداريًا. وهذا له بعض العواقب الهامة على التوجيه. فمن المحتمل جدًا أن يكون لدى مزودي الخدمات المختلفين أفكارًا مختلفة حول أفضل بروتوكول توجيه لاستخدامه داخل شبكاتهم وحول كيفية إسناد المقاييس للروابط الموجودة في الشبكة على سبيل المثال. وبسبب هذا الاستقلال، تكون شبكة كل مزود عادةً عبارة عن نظامٍ مستقل autonomous system أو اختصارًا AS. سنعرّف هذا المصطلح بصورةٍ أدق لاحقًا، ولكن في الوقت الحالي من المناسب التفكير في النظام المستقل AS كشبكةٍ تُدار بصورةٍ مستقلة عن الأنظمة المستقلة الأخرى.

يمكن استخدام حقيقة أن الإنترنت لديه بنية واضحة لصالحنا أثناء معالجة مشكلة قابلية التوسع. ولكن نحن بحاجة إلى التعامل مع مسألتين مرتبطتين بمشكلة التوسّع scaling. المسألة الأولى هي قابلية توسّع التوجيه. حيث نحتاج إلى إيجاد طرقٍ لتقليل عدد أرقام الشبكة التي تُنقَل في بروتوكولات التوجيه وتُخزَّن في جداول التوجيه الخاصة بالموجّهات. أمّا المسألة الثانية فهي استخدامية العناوين، أي التأكد من عدم استهلاك حيز عناوين IP بسرعة كبيرة.

نرى استخدام مبدأ الهرمية hierarchy مرارًا وتكرارًا في هذا الكتاب لتحسين قابلية التوسُّع. وقد رأينا في الفصل السابق كيف يمكن لبنية عناوين IP الهرمية تحسين قابلية التوسع في التوجيه، وخاصةً مع المرونة التي يوفرها التوجيه بين النطاقات عديم التصنيف Classless Interdomain Routing أو اختصارًا CIDR والشبكات الفرعية. وسنرى لاحقًا استخدامات أخرى لِلهرمية، وشريكها التجميع aggregation، لتوفير أكبر قابليةٍ للتوسُّع، أولًا في نطاقٍ domain واحد ثم بين النطاقات. ثم سنناقش الإصدار 6 من بروتوكول IP، والذي كان اختراعه نتيجة مخاوف قابلية التوسع إلى حدٍ كبير.

مناطق التوجيه Routing Areas

كمثالٍ أول على استخدام الهرمية لتوسيع نظام التوجيه، سنَفحص كيفية استخدام بروتوكولات توجيه حالة الرابط link-state (مثل بروتوكولي OSPF و IS-IS) لتقسيم نطاق التوجيه إلى نطاقات فرعية تسمى مناطق areas. (تختلف المصطلحات إلى حدٍ ما بين البروتوكولات، ولكن سنستخدم مصطلحات بروتوكول OSPF هنا). فيمكن للنطاقات النمو بصورةٍ أكبر من خلال إضافة هذا المستوى الإضافي من الهرمية دون إنهاك بروتوكولات التوجيه أو اللجوء إلى بروتوكولات التوجيه بين النطاقات interdomain routing protocols الأعقد التي سنوضّحها لاحقًا.

المنطقة area عبارة عن مجموعة من الموجّهات المضبوطة إداريًا لتبادل معلومات حالة الرابط مع بعضها بعضًا. هناك منطقة خاصة واحدة هي المنطقة الرئيسية backbone area، والمعروفة أيضًا بالمنطقة 0. يوضح الشكل الآتي مثالًا عن نطاق توجيهٍ مُقسمٍ إلى مناطق. الموجّهات R1 و R2 و R3 هي أعضاء في المنطقة الرئيسية وأعضاءٌ أيضًا في منطقة واحدة ليست منطقة رئيسية على الأقل، حيث الموجه R1 هو في الواقع عضو في كلٍّ من المنطقة 1 والمنطقة 2. يُعرَف الموجّه العضو في كلٍ من المنطقة الرئيسية ومنطقة ليست بمنطقة رئيسية nonbackbone area بموجّه منطقةٍ حدودي area border router أو اختصارًا ABR. لاحظ أن هذه الموجّهات تختلف عن الموجّهات الموجودة على حافة نظام AS، والتي يُشار إليها باسم موجهات حدود AS للتوضيح.

يتم التوجيه داخل منطقةٍ واحدة بالضبط كما هو مّوضح في الفصل السابق. ترسِل جميع الموجّهات في المنطقة إعلانات حالة الرابط لبعضها بعضًا، وبالتالي فهي تطوّر خارطةً كاملة ومستقرة للمنطقة. ولكنّ لا تترك إعلانات حالة الرابط الخاصة بالموجّهات التي ليست موجّهات منطقةٍ حدودية المنطقةَ التي نشأت فيها. هذا له تأثير في جعل عمليات حساب المسار route calculation والإغراق flooding أكثر قابلية للتوسع بصورة كبيرة. فلن يرى الموجّه R4 مثلًا الموجود في المنطقة 3 أبدًا إعلان حالة رابطٍ من الموجه R8 الموجود في المنطقة 1. ولذلك لن يعرف شيئًا عن الهيكل topology التفصيلي لِلمناطق المغايرة لِمنطقته.

إذًا كيف يحدّد الموجّه في منطقةٍ ما عقدة توجيه القفزة التالية next hop الصحيحة للرزمة الموجّهةِ إلى شبكةٍ في منطقة أخرى؟ تصبح الإجابة عن هذا السؤال واضحةً إذا تخيلنا أن مسار الرزمة التي يجب أن تنتقل من منطقةٍ ليست منطقة رئيسية إلى منطقة أخرى مقسَّمٌ إلى ثلاثة أجزاء. أولًا، تنتقل الرزمة من الشبكة المصدر إلى المنطقة الرئيسية، ثم تعبر المنطقة الرئيسية، وتنتقل منها إلى الشبكة الوِجهة. تلخّص موجّهات المنطقة الحدودية، لإنجاز هذا العمل، معلوماتِ التوجيه التي تعلّمتها من منطقةٍ ما وتُتيحَها ضمن إعلاناتها إلى مناطق أخرى. يتلقى الموجّه R1 على سبيل المثال إعلانات حالة الرابط من جميع الموجّهات في المنطقة 1 وبالتالي يمكنه تحديد تكلفة الوصول إلى أي شبكة في المنطقة 1. يعلن الموجّه R1 عن تكاليف الوصول إلى الشبكات في المنطقة 1 عندما يرسل إعلانات حالة الرابط إلى المنطقة 0، كما لو كانت جميع هذه الشبكات متصلةً مباشرة بالموجه R1. يتيح ذلك لجميع الموجّهات في المنطقة 0 معرفة تكلفة الوصول إلى جميع الشبكات في المنطقة 1. ثم تلخّص موجهات المنطقة الحدودية هذه المعلومات وتعلن عنها في المناطق الغير الرئيسية، وبالتالي تتعلم جميع الموجّهات كيفية الوصول إلى جميع الشبكات في النطاق domain.

لاحظ أنه في حالة المنطقة 2، يوجد موجهان ABR، وبالتالي يتعين على الموجّهات في المنطقة 2 أن تختار أي موجهٍ ستستخدم للوصول إلى المنطقة الرئيسية. هذا سهل بما فيه الكفاية، نظرًا لأن كلًا من الموجهين R1 و R2 سَيُعلِنان عن تكاليف الوصول إلى شبكاتٍ مختلفة، لذلك سيتضح أيهما هو الخيار الأفضل لأن موجهات المنطقة 2 تشغّل خوارزمية المسار الأقصر shortest-path algorithm. فمن الواضح جدًا أن الموجّه R1 سيكون خيارًا أفضل من الموجّه R2 للوِجهات في المنطقة 1.

يُجري مسؤول administrator الشبكة مقايضة بين قابلية التوسُّع والتوجيه الأمثل عند تقسيم نطاقٍ إلى مناطق. يُجبِر استخدامُ المناطق جميعَ الرزم التي تنتقل من منطقة إلى أخرى على المرور عبر المنطقة الرئيسية حتى لو كان المسار الأقصر متاحًا. فلن تتدفق الرزم بين الموجهين R4 و R5 على سبيل المثال حتى لو كانا متصلين مباشرةً لأنهما موجودان في منطقتين مختلفتين وغير رئيسيتين. اتضح أن الحاجة إلى قابلية التوسع غالبًا تكون أهم من الحاجة إلى استخدام المسار الأقصر على الإطلاق.

اقتباس

هذا يوضح مبدأً مهمًا في تصميم الشبكات. حيث يكون هناك مقايضةٌ بين قابلية التوسُّع scalability ونوعٍ من الأمثلية optimality. تُخفى المعلومات من بعض العقد في الشبكة عند استخدام الهرمية، مما يعيق قدرتها على اتخاذ قرارات مثالية. ولكنّ إخفاء المعلومات أمرٌ ضروريّ لتوسيع نطاق الحل، لأنه يحفظ جميع العقد من امتلاك معرفةٍ عالمية. من الصحيح دائمًا أن قابليةَ التوسع هي هدفُ تصميمٍ أكثر إلحاحًا من اختيار المسار الأمثل في الشبكات الكبيرة.

أخيرًا، نلاحظ أن هناك خدعة يمكن من خلالها لمسؤولي الشبكة أن يقرروا بصورةٍ أكثر مرونة أي موجهاتٍ تذهب في المنطقة 0. حيث تستخدم هذه الخدعة فكرة الرابط الافتراضي virtual link بين الموجّهات. يمكن الحصول على هذا الرابط الافتراضي عن طريق ضبط موجهٍ غير متصلٍ مباشرةً بالمنطقة 0 لتبادل معلومات توجيه المنطقة الرئيسية مع هذا الموجّه. حيث يمكن ضبط رابطٍ افتراضي من الموجّه R8 إلى الموجّه R1 على سبيل المثال، مما يجعل الموجّه R8 جزءًا من المنطقة الرئيسية، وسيشارك الموجه R8 الآن في إغراق الموجهات الأخرى في المنطقة 0 بإعلان حالة الرابط. تحدَّد تكلفة الرابط الافتراضي من الموجّه R8 إلى الموجّه R1 من خلال تبادل معلومات التوجيه التي تحدث في المنطقة 1، ويمكن أن تساعد هذه التقنية في تحسين التوجيه الأمثلي.

التوجيه بين النطاقات Interdomain Routing باستخدام بروتوكول BGP

تحدّثنا عن فكرة أن الإنترنت منظمٌ ضمن أنظمةٍ مستقلة في بداية هذا الفصل، ويكون كل نظامٍ منها تحت سيطرة كيانٍ إداري منفصل. قد تكون الشبكة الداخلية المعقّدة لشركةٍ ما عبارةً عن نظام مستقل AS واحد، كما هو الحال بالنسبة للشبكة الوطنية لأي مزود خدمة إنترنت ISP. يوضح الشكل التالي شبكة بسيطة ذات نظامَين مستقلين autonomous systems:

هدف هذه الأنظمة المستقلة هو توفير طريقة إضافية لتجميع معلومات التوجيه بصورةٍ هرمية في شبكة إنترنت كبيرة، وبالتالي تحسين قابلية التوسُّع. نقسِّم الآن مشكلة التوجيه إلى جزأين: التوجيه داخل نظام مستقل واحد والتوجيه بين الأنظمة المستقلة. نشير إلى جزأي مشكلة التوجيه بالتوجيه بين النطاقات interdomain routing والتوجيه داخل النطاق intradomain routing، حيث يُطلق اسمٌ آخر على الأنظمة المستقلة في الإنترنت هو نطاقات التوجيه routing domains. بالإضافة إلى تحسين قابلية التوسع، يفصل نموذجُ النظام المستقل AS التوجيهَ داخل النطاق الذي يحدث في أحد الأنظمة المستقلة عن ذلك الذي يحدث في نظامٍ مستقل آخر. وبالتالي يمكن لكل نظامٍ مستقل تشغيلَ أي بروتوكولات توجيه يختارها داخل النطاق. ويمكنه استخدام بروتوكولات مساراتٍ ثابتة static routes أو بروتوكولات متعددة، إذا رغب في ذلك. وعندئذٍ تكون مشكلة التوجيه بين النطاقات هي مشكلة مشاركة أنظمةٍ مستقلة مختلفة لمعلومات إمكانية الوصول لبعضها بعضًا، وهذه المعلومات هي توصيف مجموعة عناوين IP التي يمكن الوصول إليها عبر نظامٍ مستقل معين.

تحديات التوجيه بين النطاقات Interdomain Routing

ربما يكون التحدي الأهم للتوجيه بين النطاقات اليوم، هو حاجة كل نظامٍ مستقل لتحديد سياسات policies التوجيه الخاصة به. قد يبدو مثالٌ بسيط عن سياسة التوجيه المطبَّقة في نظامٍ مستقل معين كما يلي: "أُفضّلُ إرسال حركة مرور البيانات عبر النظام المستقل X بدلًا من النظام المستقل Y كلما أمكن ذلك، لكنني سأستخدم النظام المستقل Y إذا كان المسار الوحيد، ولا أريد مطلقًا نقل حركة مرور البيانات من النظام المستقل X إلى النظام المستقل Y أو العكس". ستكون مثل هذه السياسة نموذجية عندما تدفع المال لكل من النظامين المستقلين X و Y لتوصيل نظامك المستقل ببقية الإنترنت، والنظام المستقل X هو مزوّد الاتصال المفضل لديك، ويكون النظام المستقل Y هو البديل. لن تتوقع مساعدة النظامين المستقلين X و Y لنقل حركة المرور بينهما عبر شبكتك، وهذا ما يسمى بحركة المرور العابرة transit traffic. نظرًا لأنك ترى كلًا منهما كمزوّدَين (ومن المفترض أنك دفعت المال مقابل أداء هذا الدور). كلما زادت الأنظمة المستقلة التي تتصل بها، زادت السياسات المعقّدة التي قد تتبعها، خاصة عندما تفكر في مزوّدي الشبكة الرئيسية، الذين قد يتواصلون مع العشرات من مزوّدي الخدمة الآخرين ومئات العملاء ولديهم ترتيبات اقتصادية مختلفة (تؤثر على سياسات التوجيه) مع كل مزوّد.

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

كان هناك بروتوكولين رئيسيين للتوجيه بين النطاقات في تاريخ الإنترنت. الأول كان بروتوكول البوابة الخارجية Exterior Gateway Protocol أو اختصارًا EGP، الذي احتوى على عدد من القيود، ربما كان أشدها تقييدًا على هيكل topology شبكة الإنترنت بصورة كبيرة. صُمِّم بروتوكول EGP عندما كان للإنترنت هيكلٌ يشبه الشجرة كما هو موضح في الشكل الآتي، ولم يُسمح للهيكل أن يصبح أعم. لاحظ أنه في هذه البنية البسيطة الذي تشبه الشجرة، يوجد شبكة رئيسية وحيدة، والأنظمة المستقلة متصلة فقط كآباء وأبناء وليس كنظراء peers.

لقد كان بديل بروتوكول EGP هو بروتوكول البوابة الحدودية Border Gateway Protocol أو اختصارًا BGP، والذي تكرر من خلال أربعة إصدارات BGP-4. يُنظر إلى بروتوكول BGP غالبًا على أنه واحد من أكثر أجزاء الإنترنت تعقيدًا، لذلك سنغطي بعض أهم نقاطه هنا.

لا يقدم بروتوكول BGP، على عكس بروتوكول EGP، أي افتراضات تقريبًا حول كيفية اتصال الأنظمة المستقلة، فهو يشكّل رسمًا بيانيًا عشوائيًا. من الواضح أن هذا النموذج عام بما يكفي لاستيعاب الشبكات المتشابكة غير المبنيّة على أساس الشجرة non-tree-structured internetworks، مثل الصورة المبسَّطة لإنترنت متعدّد المزودين كما هو موضح في الشكل الآتي. (اتّضح أنه لا يزال هناك نوع آخر لبنية الإنترنت، كما سنرى لاحقًا، لكنها لا تشبه بساطة بنية الشجرة، ولا يضع بروتوكول BGP أي افتراضات حول هذه البنية).

يتكون الإنترنت اليوم، على عكس الإنترنت المبني على أساس الشجرة الموضحة في بداية هذا الفصل أو حتى الصورة البسيطة إلى حدٍ ما في الشكل السابق، من مجموعة غنية من الشبكات المترابطة، تديرها في الغالب شركات خاصة، أو مزودو خدمة الإنترنت ISP بدلًا من الحكومات. يقدم العديد من مزودي خدمة الإنترنت هذه الخدمة إلى "المستهلكين consumers"، أي الأفراد الذين لديهم حواسيب في منازلهم، بينما يقدم مزودو خدمةٍ آخرون شيئًا يشبه خدمة الشبكة الرئيسية القديمة، ويربطون بين مزودي الخدمة الآخرين وأحيانًا بين الشركات الكبيرة. ويُرتِّب العديد من مزودي الخدمة للترابط مع بعضهم بعضًا في نقطة تناظر peering point واحدة.

يمكننا البدء بتحديد بعض المصطلحات للحصول على فكرةٍ أفضل عن كيفية إدارة التوجيه بين هذا الترابط المُعقد للأنظمة المستقلة. نحدّد حركة المرور المحلية local traffic على أنها حركة المرور التي تنشأ عند العقد داخل النظام المستقل أو تنتهي عندها، وحركة المرور العابرة transit traffic على أنها حركة مرور تمر عبر نظامٍ مستقل. يمكن تصنيف الأنظمة المستقلة إلى ثلاثة أنواع:

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

إن أهداف التوجيه بين النطاقات أعقد من إيجاد المسارات المثلى للتوجيه استنادًا إلى تقليل نوعٍ من مقياس الرابط link metric والتي تم تسليط الضوء عليها في فصل سابق. أولًا، من الضروري إيجاد مسار إلى الوجهة المقصودة خالٍ من الحلقات. ثانيًا، يجب أن تكون المسارات متوافقة مع سياسات الأنظمة المستقلة المختلفة على طول المسار، وكما رأينا بالفعل، قد تكون هذه السياسات معقدة على نحوٍ كيفي. يركّز التوجيه بين النطاقات interdomain على إيجاد مسار خالٍ من الحلقات non-looping ومتوافق مع السياسة وهي مشكلة أعقد للتحسين، بينما يُركِّز التوجيه داخل النطاق intradomain على مشكلة محددة جيدًا لتحسين تكلفة المسار القياسية.

هناك عوامل إضافية تجعل التوجيه بين النطاقات interdomain routing صعبًا. العامل الأول هو ببساطة مسألة التوسّع. يجب أن يكون موجّه الشبكة الرئيسية قادرًا على تمرير أي رزمةٍ متجهة إلى أي مكان على الإنترنت. وهذا يعني وجود جدول توجيه يوفر تطابقًا لأي عنوان IP صالح. ساعد توجيه CIDR في التحكم في عدد البادئات المميزة التي تُنقَل في توجيه الإنترنت الرئيسي، فهناك حتمًا الكثير من معلومات التوجيه التي يجب تمريرها والتي وصل عددها إلى ما يقارب 700,000 بادئة في منتصف عام 2018.

ينشأ تحدٍ آخر في التوجيه بين النطاقات من الطبيعة المستقلة للنطاقات. لاحظ أن كل نطاقٍ يمكنه تشغيل بروتوكولات التوجيه الداخلية الخاصة به واستخدام أي مخططٍ يختاره لإسناد المقاييس للمسارات. وهذا يعني أنه من المستحيل حساب تكاليف المسار الموجَّه لمسارٍ يعبر أنظمة مستقلة متعددة. قد تعني التكلفة 1000 عبر مزودٍ واحد مسارًا رائعًا، ولكن قد يعني ذلك مسارًا سيئًا وغير مقبول لمزودٍ آخر. ولذلك يعلن التوجيه بين النطاقات عن إمكانية الوصول reachability فقط. مفهوم قابلية الوصول هو في الأساس بيانٌ يقول "يمكنك الوصول إلى هذه الشبكة من خلال هذا النظام المستقل AS". هذا يعني أن التوجيه بين النطاقات لاختيار المسار الأمثل أمر مستحيل أساسًا.

تثير الطبيعة المستقلة بين النطاقات قضية الثقة. قد لا يرغب المزود A في تصديق إعلانات معينة من المزود B خوفًا من أن يعلن المزود B عن معلومات توجيه خاطئة. على سبيل المثال، يمكن أن يكون الوثوق بالمزود B عندما يعلن عن مسارٍ رائعٍ إلى أي مكان على الإنترنت خيارًا كارثيًا إذا تبين أن المزود B قد ارتكب خطأً في ضبط الموجّهات الخاصة به أو أنه لا يمتلك سعةً كافية لحمل حركة مرور البيانات.

ترتبط مسألة الثقة أيضًا بالحاجة إلى دعم السياسات المعقدة. فمثلًا قد تكون على استعداد للثقة بمزودٍ معين فقط عندما يعلن عن إمكانية الوصول إلى بادئات معينة، وبالتالي سيكون لديك سياسة تقول "استخدم النظام المستقل X للوصول إلى البادئات p و q فقط، إذا وفقط إذا أعلن النظام المستقل X عن إمكانية الوصول إلى تلك البادئات ".

أساسيات بروتوكول BGP

يحتوي كل نظام AS على موجهٍ حدودي border router واحد أو أكثر تدخل وتغادر الرزمُ من خلاله النظام المستقل. حيث أن الموجّهات R2 و R4 في مثالنا البسيط في الشكل الآتي هي موجّهات حدودية. (عُرفت الموجّهات على مر السنين أحيانًا باسم البوابات gateways، ومن هنا جاءت أسماء البروتوكولَين BGP و EGP). الموجّه الحدودي هو ببساطة موجّه IP مكلَّفٌ بمهمة تمرير الرزم بين الأنظمة المستقلة.

يجب أن يكون لكل نظام AS مشاركٍ في بروتوكول BGP أيضًا متحدّثٌ speaker خاصٌ ببروتوكول BGP واحد على الأقل، وهو موجّه "يتحدّث speaks" ببروتوكول BGP إلى متحدّثي بروتوكول BGP آخرين في أنظمة مستقلة أخرى. من الشائع أن تجد أن الموجّهات الحدودية هي أيضًا متحدثات بروتوكول BGP، لكنه ليس واجبًا.

لا ينتمي بروتوكول BGP إلى أي من الصنفين الرئيسيتين لبروتوكولات التوجيه، وهما متّجه المسافة distance-vector وحالة الرابط link-state. يعلن بروتوكول BGP، على عكس هذه البروتوكولات، عن مسارات كاملة كقائمة معدودة من الأنظمة المستقلة للوصول إلى شبكة معينة، حيث يُسمى أحيانًا بروتوكول متّجه المسار path-vector لهذا السبب. يُعد الإعلان عن المسارات الكاملة ضروريًا لتمكين أنواع قرارات السياسة، الموضحة سابقًا، من أن تُتّخَذ وفقًا لرغبات نظام AS معين. كما أنه يُمكِّن من اكتشاف حلقات التوجيه بسهولة.

افترض مثال الشبكة البسيط الموضح في الشكل السابق لمعرفة كيفية عمل ذلك، وافترض أن مزودي الخدمة هم شبكات عابرة transit networks، بينما شبكات العملاء هي شبكات جذريّة stubs. يمكن لمتحدثِ بروتوكول BGP لنظام AS للمزود A (في الشكل هو AS 2) أن يعلن عن معلومات قابلية الوصول لكلٍ من أرقام الشبكة المُسندة للعملاء P و Q. وبالتالي سيقول "أن الشبكات 128.96 و 192.4.153 و 192.4.32 و 192.4.3 يمكن الوصول إليها مباشرةً من النظام المستقل AS 2". وعند تلّقي هذا الإعلان، يمكن للشبكة الرئيسية الإعلان عن أنه "يمكن الوصول إلى الشبكات 128.96 و 192.4.153 و 192.4.32 و 192.4.3 على طول المسار (AS 1 , AS 2)". وبالمثل، يمكنها الإعلان عن أنه "يمكن الوصول إلى الشبكات 192.12.69 و 192.4.54 و 192.4.23 على طول المسار (AS 1 , AS 3)".

تتمثل إحدى الوظائف المهمة لبروتوكول BGP في منع إنشاء مسارات الحلقات. افترض وجود الشبكة الموضحة في الشكل السابق. وهي تختلف عن الشبكة الموضَّحة في الشكل الذي قبله فقط في إضافة رابطٍ إضافي بين النظامين المستقلين AS 2 و AS 3، ولكن التأثير الآن هو أن الرسم البياني للأنظمة المستقلة يحتوي على حلقةٍ فيه. لنفترض أن النظام المستقل AS 1 تعلّم أنه يمكنه الوصول إلى الشبكة 128.96 من خلال النظام المستقل AS 2، لذلك يعلن عن هذه الحقيقة للنظام المستقل AS 3، والذي بدوره يعلن عنها مرة أخرى إلى النظام المستقل AS 2. يمكن للنظام المستقل AS 2 الآن تحديد أن النظام المستقل AS 3 هو المسار المفضل للرزم الموجهة للشبكة 128.96 في حالة عدم وجود أية آلية لمنع الحلقة. إذا بدأ النظام المستقل AS 2 في إرسال رزمٍ، موجهةٍ إلى الشبكة 128.96، إلى النظام المستقل AS 3 ، فإن النظام المستقل AS 3 سيُرسلها إلى النظام المستقل AS 1، وبالتالي سيعيد النظام المستقل AS 1 تلك الرزم إلى النظام المستقل AS 2، وستدور في حلقةٍ إلى الأبد. يُمنع حدوث ذلك عن طريق حمل مسار النظام المستقل الكامل في رسائل التوجيه. بالتالي سيحوي الإعلان عن المسار في هذه الحالة إلى الشبكة 128.96 الذي استلمه النظام المستقل AS 2 من النظام المستقل AS 3 على مسار النظام المستقل (AS 3 , AS 1 , AS 2 , AS 4). يرى النظام المستقل AS 2 نفسه في هذا المسار، وبالتالي يستنتج أن هذا ليس مسارًا مفيدًا لاستخدامه.

من الواضح أن أرقام AS المحمولة في بروتوكول BGP يجب أن تكون فريدة لكي تعمل تقنية منع الحلقة هذه. فيمكن للنظام المستقل AS 2 التعرف على نفسه فقط في مسار AS في المثال أعلاه إذا لم يعرّف نظام مستقلٌ آخر نفسه بنفس الطريقة. يبلغ طول أرقام AS الآن 32 بتًا، وتُسندها سلطة مركزية لضمان هذا التفرُّد uniqueness.

سيعلن نظامٌ مستقل عن المسارات التي يراها جيدةً بما يكفي لنفسه فقط. إذا كان متحّدث بروتوكول BGP قادرًا على الاختيار من بين عدة مسارات مختلفة إلى وجهةٍ ما، سيختار أفضلها وفقًا لسياساته المحلية الخاصة، ثم سيكون هذا هو المسار الذي يعلن عنه. إن متحدّث بروتوكول BGP غير ملزمٍ بالإعلان عن أي مسار إلى أية وجهة، حتى لو كان لديه مسار. هذه هي الطريقة التي يمكن بها لِلنظام المستقل تنفيذ سياسة عدم توفير عبور not providing transit من خلال رفض الإعلان عن مسارات البادئات غير الواردة في هذا النظام المستقل، حتى لو كان يعرف كيفية الوصول إليها.

يجب أن يكون متحدثو بروتوكول BGP قادرين على إلغاء المسارات التي أُعلِن عنها مسبقًا عند فشل الروابط وتغيير السياسات. ويحدث ذلك باستخدام شكلٍ من أشكال الإعلان السلبي يُعرف باسم المسار المسحوب withdrawn route. تُنقل معلومات قابلية الوصول الإيجابية والسلبية في رسالة تحديث BGP، ويعرض الشكل التالي صيغة هذه الرسالة. (لاحظ أن الحقول في هذا الشكل هي من مضاعفات 16 بت، على عكس صيغ الرزم الأخرى في هذا الفصل):

يُعرَّف بروتوكول BGP، على عكس بروتوكولات التوجيه الموصوفة في الفصل السابق، للتشغيل فوق بروتوكول TCP، وهو بروتوكول النقل الموثوق. يجب عدم إرسال معلومات مُرسلة من متحدِّثٍ إلى آخر مرةً أخرى، نظرًا لأن متحدثي بروتوكول BGP يمكنهم الاعتماد على بروتوكول TCP ليكونوا موثوقين. وبالتالي طالما لم يتغير شيء، يمكن لمتحدّث بروتوكول BGP ببساطة إرسال رسالة تنشيط اتصال keepalive عرَضية تقول "ما زلت هنا ولم يتغير شيء". إذا تعطل هذا الموجّه أو انفصل عن نظيره، سيقف عن إرسال رسائل تنشيط الاتصال، وستَفترِض الموجّهات الأخرى التي تعلمت المسارات منه أن هذه المسارات لم تعد صالحة.

علاقات Relationships النظام المستقل وسياساته المشتركة

تبين أن هناك عددًا قليلًا من السياسات المشتركة التي تعكس العلاقات المشتركة بين الأنظمة المستقلة. يوضح الشكل التالي العلاقات الأكثر شيوعًا:

العلاقات الثلاث المشتركة والسياسات التي تتماشى معها هي:

المزوِّد - العميل Provider-Customer: يعمل المزودون على توصيل عملائهم ببقية الإنترنت. قد يكون العميل شركة، أو قد يكون مزود خدمة إنترنت أصغر (الذي قد يكون له عملاء خاصين به). لذا فإن السياسة الشائعة هي الإعلان عن جميع المسارات التي تعرفها لعميلك، والإعلان عن المسارات التي تتعلمها من عميلك إلى الجميع.
العميل - المزوّد Customer-Provider: يريد العميل في الاتجاه الآخر توجيه حركة المرور إليه (وعملائه، إذا كان لديه) بواسطة مزوده، ويريد أن يكون قادرًا على ارسال حركة المرور إلى بقية الإنترنت من خلال مزوّده. لذا فإن السياسة الشائعة في هذه الحالة هي الإعلان عن البادئات والمسارات الخاصة بك التي تعلّمتها من عملائك إلى مزود الخدمة الخاص بك، والإعلان عن المسارات التي تعلمتها من مزود الخدمة إلى عملائك، ولكن لا تعلن عن المسارات التي تعلّمتها من مزودٍ إلى مزودٍ آخر. والسبب في الجزء الأخير هو التأكد من أن العميل لا يجد نفسه عاملًا في مجال نقل حركة المرور من مزود إلى آخر، وهذا ليس في مصلحته إذا كان يدفع لمزودي الخدمة لنقل حركة المرور نيابة عنه.
النظير peer: الخيار الثالث هو التناظر المتماثل symmetrical peering بين الأنظمة المستقلة. يكون مزودي الخدمة الذين يعدّون أنفسهم متساوين ونظائر، بحيث يمكنهم الوصول إلى عملاء بعضهم بعضًا دون الحاجة للدفع لمزوّد آخر. تتمثل السياسة المعتادة هنا في الإعلان عن المسارات التي تعلمتها من عملائك إلى نظيرك peer، والإعلان عن المسارات التي تعلمتها من نظيرك إلى عملائك، ولكن لا تعلن عن المسارات من نظيرك إلى أي مزود أو العكس.

شيء واحد يجب ملاحظته حول هذا الأسلوب وهو إعادته بعض الهيكلة إلى شبكة الإنترنت التي تظهر أنّها غير مُنظّمة unstructured. لدينا الشبكات الجذرية stub networks في الجزء السفلي من التسلسل الهرمي، وتُمثّل هذه الشبكات عملاءٌ لمزودٍ واحد أو أكثر، ونرى مع تقدمنا في التسلسل الهرمي مزوّدي الخدمة الذين لديهم مزودين آخرين كعملاءٍ لهم. لدينا في الجزء العلوي مزودون لديهم عملاء ونظائر ولكنهم ليسوا عملاء لأي شيء، ويُعرف هؤلاء المزوّدون بمزودي الطبقة الأولى Tier-1.

اقتباس

لنعد إلى السؤال الحقيقي: كيف يساعدنا كل هذا في بناء شبكات قابلة للتوسّع؟ أولًا، يكون عدد العقد المشاركة في بروتوكول BGP بترتيب عدد الأنظمة المستقلة، وهو أصغر بكثير من عدد الشبكات. ثانيًا، إن العثور على مسار جيد بين النطاقات هو فقط مسألة إيجاد مسار إلى الموجه الحدودي الصحيح، والذي لا يوجد سوى عدد قليل منه لكل نظام AS. وبالتالي قسّمنا مشكلة التوجيه بدقة إلى أجزاءٍ يمكن التحكم فيها، باستخدام مستوٍ جديد من التسلسل الهرمي لزيادة قابلية التوسُّع. أصبح تعقيد التوجيه بين النطاقات الآن من رتبة عدد الأنظمة المستقلة، كما أن تعقيد التوجيه داخل النطاق يكون من رتبة عدد الشبكات في نظام AS واحد.

دمج التوجيه بين النطاقات مع التوجيه داخل النطاق

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

لنبدأ بموقف بسيط جدًا، وهو أيضًا شائع جدًا. من الواضح أن الموجّه الحدودي والذي يتصل فقط بالأنظمة المستقلة الأخرى عند نقطة واحدة، هو الخيار الوحيد لجميع المسارات خارج نظام AS في حالة نظام مستقل جذري stub. يمكن لهذا الموجّه حقن مسارٍ افتراضي default route في بروتوكول التوجيه داخل النطاق، وهذا بيانٌ مفاده أن أية شبكة لم يعلن عنها صراحةً في بروتوكول النطاق الداخلي يمكن الوصول إليها من خلال الموجّه الحدودي. تذكّر، من تمرير بروتوكول IP، أنّ المدخلة الافتراضية default entry في جدول التمرير تأتي بعد كل المدخلات الأكثر تحديدًا، وهي تقابل أي شيءٍ فشلَ في مطابقة مدخلةٍ محددة.

تتمثل الخطوة التالية في التعقيد في جعل الموجّهات الحدودية تضخ مساراتٍ معينة تعّلمتها من خارج نظام AS. افترض، على سبيل المثال، الموجّه الحدودي لنظام AS الذي يتصل بعميل AS. يمكن لهذا الموجّه معرفة أن بادئة الشبكة 192.4.54 / 24 موجودة داخل عميل AS، إما من خلال بروتوكول BGP أو بسبب ضبط المعلومات في الموجه الحدودي، ويمكنه حقن مسارٍ لهذه البادئة في بروتوكول التوجيه الذي يعمل داخل مزود AS. سيكون هذا إعلانًا من النوع: "لدي رابطٌ بالبادئة 192.4.54 / 24 بتكلفة X". قد يتسبب ذلك في معرفة الموجّهات الأخرى في مزود AS أن هذا الموجّه الحدودي هو المكان المناسب لإرسال الرزم المخصَّصة لتلك البادئة.

يأتي المستوى الأخير من التعقيد في الشبكات الرئيسية، التي تتعلم الكثير من معلومات التوجيه من بروتوكول BGP بحيث يصبح حقنها في بروتوكول داخل النطاق مكلفًا للغاية. إذا أراد الموجه الحدودي، على سبيل المثال، حقن 10000 بادئة تعلّمها من نظام AS آخر، فسيتعيّن عليه إرسال رزم حالة رابط كبيرة جدًا إلى الموجهات الأخرى في نظام AS، وستصبح حسابات المسار الأقصر معقدةً للغاية. لذلك تستخدم الموجّهات في الشبكة الرئيسية متغيرًا من بروتوكول BGP يسمى BGP الداخلي interior BGP أو اختصارًا iBGP لإعادة توزيع المعلومات التي تعلّمتها باستخدام متحدّثي بروتوكول BGP على حواف نظام AS إلى جميع الموجهات الأخرى في نظام AS بفعالية. (يعمل البديل الآخر لبروتوكول BGP بين الأنظمة المستقلة ويُسمى BGP الخارجي exterior BGP أو اختصارًا eBGP. يمكّن بروتوكول iBGP أي موجهٍ في نظام AS من التعرف على أفضل موجهٍ حدودي لاستخدامه عند إرسال رزمةٍ إلى أي عنوان، ويتتبع كل موجه في نظام AS في الوقت نفسه كيفية الوصول إلى كل موجهٍ حدودي باستخدام بروتوكول تقليدي داخل النطاق بدون معلوماتٍ محقونة. يكون كل موجهٍ في نظام AS قادرًا على تحديد العقدة التوجيهية التالية المناسبة لجميع البادئات من خلال الجمع بين هاتين المجموعتين من المعلومات.

افترض شبكة المثال البسيط التي تمثل نظامًا مستقلًا واحدًا في الشكل السابق. تتحدَث الموجّهات الحدودية الثلاثة، A و D و E، بروتوكول eBGP مع أنظمة مستقلة أخرى وتتعلّم كيفية الوصول إلى البادئات المختلفة. تتواصل الموجّهات الحدودية الثلاثة هذه مع الموجهات الأخرى ومع الموجّهات الداخلية B و C من خلال إنشاء شبكة من جلسات iBGP بين جميع الموجّهات في النظام المستقل. دعنا نركز الآن على كيفية بناء الموجّه B لرؤيته الكاملة لكيفية تمرير الرزم إلى أية بادئة. انظر إلى الجزء العلوي الأيسر من الشكل الآتي، والذي يعرض المعلومات التي يتعلّمها الموجّه B من جلسات iBGP الخاصة به. يتعلم أنه من الأفضل الوصول إلى بعض البادئات عبر الموجّه A، والبعض الآخر عبر الموجّه D، والبعض الآخر عبر الموجّه E. وفي الوقت نفسه، تعمل جميع الموجّهات في النظام المستقل أيضًا على تشغيل بعض بروتوكولات التوجيه داخل النطاق مثل بروتوكول معلومات التوجيه Routing Information Protocol أو اختصارًا RIP أو بروتوكول OSPF. (المصطلح العام لبروتوكولات داخل النطاق هو بروتوكول بوابة داخلية interior gateway protocol أو اختصارًا IGP). يتعلم الموجّه B كيفية الوصول إلى العقد الأخرى داخل النطاق من هذا البروتوكول المنفصل تمامًا، كما هو موضح في أعلى الجدول الأيمن من الشكل الآتي. يحتاج الموجه B إلى إرسال رزمٍ إلى الموجّه C للوصول إلى الموجّه E على سبيل المثال. أخيرًا في الجدول السفلي، يجمع الموجه B الصورة بأكملها معًا، ويجمّع المعلومات حول البادئات الخارجية التي تعلمها من iBGP مع المعلومات حول المسارات الداخلية إلى الموجهات الحدودية المتعلَّمة من بروتوكول IGP. وبالتالي إذا أمكن الوصول إلى بادئة مثل 18.0 / 16 عبر الموجه الحدودي E، وكان أفضل مسار داخلي إلى الموجه E هو عبر الموجه C، فسيترتّب عن ذلك إعادة توجيه أية رزمة مخصَّصة للبادئة 18.0 / 16 إلى الموجه C، ويمكن بهذه الطريقة لأي موجهٍ في النظام المستقل إنشاء جدول توجيه كامل لأية بادئةٍ يمكن الوصول إليها عبر بعض موجهات الحدود في النظام المستقل.