- اینترنت خراب است
- چمدان تاریخی مسیریابی IP Routing: Simplistic Plane Data
- Latency ، Loss Packet and Route Selection
یک تمرین خوشایند حتی اگر شما پیچیدگی لوازم و نیاز به کار با یادگارهای قدیمی مانند IPSec را مشخص کنید ، مدیریت زمان تاخیر ، از بین رفتن بسته ها و در دسترس بودن زیاد یک مشکل بزرگ در اینترنت است. ارائه دهندگان خدمات نیز این را می دانند (و میلیاردها دلار در MPLS ایجاد می کنند).
خبر بد این است که در حال بهبود نیست. مهم نیست که ظرفیت موجود به طرز چشمگیری افزایش یافته است. مشکل در نحوه ارتباط بین ارائه دهندگان و نحوه مدیریت (غلط) مسیرهای جهانی است. این نهفته در هسته نحوه ایجاد اینترنت ، پروتکل های آن و نحوه ارائه دهندگان خدمات مسیریابی IP است. همان معماری که به اینترنت اجازه می دهد مقرون به صرفه برای مقیاس میلیاردها دستگاه باشد ، محدودیت های خود را نیز تعیین می کند.
پرداختن به این چالش ها نیاز به بازسازی عمیقی در ساختار اینترنت و مسیریابی هسته ای دارد – و باید پایه و اساس راه حل های ممکن را تشکیل دهد. قرار نیست یک روتر جدید براق وجود داشته باشد که همه اینها را به طرز جادویی حل کند.
مسئله در ارتباط بین ارائه دهندگان و نحوه مدیریت مسیرهای جهانی است. این نهفته در هسته چگونگی ایجاد اینترنت ، پروتکل های آن و نحوه ارائه دهندگان خدمات لایه مسیریابی خود است.
چمدان تاریخی IP Routing's: Simplistic Data Plane
آیا ترافیک صوتی ، تصویری ، HTTP یا از طریق ایمیل ، اینترنت از بسته های IP ساخته شده است. میلیاردها نفر از آنها به مقصد سفر می کنند و اطلاعات را در اختیار دارند. اگر آنها در طول راه گم شوند ، بازیابی آنها بر عهده پروتکل های سطح بالاتر مانند TCP است. بسته ها از روتر گرفته تا روتر ، فقط از هوپ بعدی خود و مقصد نهایی آنها آگاه هستند. روترها کسانی هستند که در مورد بسته ها تصمیم می گیرند. هنگامی که روتر بسته ای را دریافت می کند ، طبق جدول مسیریابی خود یک محاسبه را انجام می دهد – بهترین hop hop برای بسته را مشخص می کند.
از روزهای ابتدایی اینترنت ، روترها با محدودیت های فنی شکل می گرفتند. کمبود قدرت پردازش برای جابجایی بسته ها در طول مسیر "صفحه داده" وجود دارد. سرعت دسترسی و حافظه در دسترس محدود بود ، بنابراین روترها باید به سخت افزارهای سفارشی متکی بودند که حداقل پردازش را در هر بسته انجام می دادند و هیچ مدیریت دولتی نداشتند. برقراری ارتباط با این صفحه داده محدود باید بسیار ساده و نادر باشد. تصمیم گیری های مسیریابی به یک فرآیند جداگانه منتقل می شود ، "هواپیمای کنترل" ، که به هواپیمای داده دستور داده می شود.
این جدایی از صفحه های کنترل و داده به معماران اجازه می دهد تا روترهایی را که مقیاس پذیر هستند ، بسازند و میلیون ها بسته در ثانیه را اداره کنند. با این حال ، حتی با افزایش قدرت پردازش در صفحه داده ، واقعاً مورد استفاده قرار نمی گرفت. الگوی این بود و هنوز هم این است که صفحه کنترل همه تصمیمات را می گیرد ، هواپیما داده ها جدول مسیریابی را اجرا می کنند و جدا از مسیریابی به روز رسانی های جدول ، به سختی ارتباط برقرار می کنند. دریافت "بازخورد" از صفحه داده به سادگی از این مسئله خارج نیست.
یک روتر مدرن هیچ ایده ای ندارد که چه مدت واقعاً یک بسته را برای رسیدن به هاپ بعدی خود گرفت یا اینکه اصلاً به آن رسیده است یا خیر. آیا همسایگان احتقان هستند؟ شاید و شاید اینطور نباشد. روتر حتی نمی داند که آیا خودش احتقان است. و به همان میزان که اطلاعاتی برای به اشتراک گذاشتن دارد ، به هواپیمای کنترل ، جایی که تصمیم گیری های مسیریابی در واقع اتخاذ می شود ، بازگردانده نمی شود.
از قضا ، این مبادله محدود بین هواپیمای کنترل و صفحه داده به افراط منتقل شد. در OpenFlow و شبکه تعریف شده توسط نرم افزار (SDN): تفکیک صفحه کنترل و صفحه داده به دو دستگاه مختلف. این ممکن است یک راه حل مناسب برای کاهش هزینه ها در مرکز داده باشد ، اما برای بهبود مسیریابی جهانی ، افزایش معناداری تقسیم اطلاعات بین هواپیمای کنترل و صفحه داده ، معقول تر خواهد بود.
برای مطالعه کامل بارگیری در Whitepaper:
