چرا چندپخشی IP بومی به یک سرویس ترانزیت اینترنتی مشترک بین AS تبدیل نشده است؟
چندپخشی IP یک عملیات لایه شبکه را ارائه می دهد که به ویژه برای ترافیک زنده یک به چند مفید به نظر می رسد: منبع یک جریان واحد را ارسال می کند و روترها بسته ها را تنها در جایی که مسیرهای تحویل از هم جدا می شوند، تکرار می کنند.
این عملیات به طور معمول در شبکه های کنترل شده امکان پذیر است. همچنین استانداردها و پیاده‌سازی‌هایی برای چندپخشی خاص منبع، سیگنال‌دهی عضویت گیرنده، درخت‌های ارسال چندپخشی، اطلاعات توپولوژی چندپخشی و تحویل چندپخشی در حوزه‌های اداری همکاری وجود دارد.
با این حال، یک میزبان متصل به اینترنت معمولاً نمی‌تواند یک جریان چندپخشی را منتشر کند که مشترکین در شبکه‌های دسترسی غیرمرتبط می‌توانند به آن بپیوندند، و شبکه‌های ترانزیت شرکت‌کننده درخت توزیع لازم را ایجاد می‌کنند.
دارم سعی میکنم بفهمم چرا این سرویس بین سیستم های مستقل مدیریت شده به روشی که ترانزیت unicast انجام می دهد ترکیب نمی شود.
این توپولوژی را در نظر بگیرید:
+-- AS C -- receiver R1
source S -- access AS A -- transit AS B
+-- AS D -- receiver R2
هر دو گیرنده به پخش مستقیم یکسانی از منبع نیاز دارند S.
رفتار حمل و نقل مورد انتظار عبارت است از:
S -> A -> B -> C -> R1
\
-> D -> R2
اتصال AB یک کپی از هر بسته را حمل می کند. AS B جریان را تکرار می کند زیرا مسیرهای دریافت کنندگان علاقه مند در آنجا متفاوت است.
برای اهداف این سوال، فرض کنید:
- چندپخشی خاص منبع شناسایی شده توسط
(S,G). - آدرس unicast قابل مسیریابی جهانی برای
S. - سیگنالینگ IGMPv3 یا MLDv2 در گیرنده.
- یک جریان زنده UDP با بهترین تلاش.
- بدون جستجو، سفارشی سازی، ارسال مجدد گیرنده، یا معنای TCP.
- هیچ الزامی برای پشتیبانی از فرستندگان ناشناخته تصادفی به یک گروه وجود ندارد.
- هیچ الزامی برای شرکت هر AS وجود ندارد.
- هیچ الزامی وجود ندارد که سیستم های مستقل مختلف از یک پیاده سازی چندپخشی داخلی یکسان استفاده کنند.
- خط مشی های مسیریابی و معاملات عادی تحت کنترل هر AS باقی می ماند.
بنابراین، به کشف نقطه قرار ملاقات ASM یا مالکیت گروه چندپخشی در سراسر اینترنت بستگی ندارد. گیرنده اکنون هم منبع و هم گروه را می داند.
به نظر می رسد مجموعه پروتکل حاوی بسیاری از اجزای فردی است:
- IGMPv3 و MLDv2 می توانند علاقه گیرنده منبع خاص را بیان کنند.
- PIM-SSM می تواند درخت های توزیع خاص منبع را بسازد.
- یک پایگاه اطلاعات مسیریابی چندپخشی ممکن است از اطلاعات دسترسی تک‌پخشی یا اطلاعات توپولوژی چندپخشی تبلیغاتی جداگانه استفاده کند.
- MP-BGP دارای خانواده آدرس چندپخشی برای تبلیغ در دسترس بودن چندپخشی است.
- RFC 8313 تحویل SSM را از طریق نقاط همتای بین دامنه ای توصیف می کند.
- RFC 8815 SSM را به جای ASM برای چندپخشی درون دامنه ای توصیه می کند.
این مکانیسم‌ها نشان می‌دهند که چندپخشی ذاتاً به یک LAN یا یک دامنه اداری منفرد محدود نمی‌شود.
چیزی که من پیدا نکردم توضیح واضحی از گام گم شده بین آن است “دو اپراتور می توانند عمدا تحویل چندپخشی را ترتیب دهند” و “مولتی کست یک سرویس قابل ترکیب است که توسط ISP های شرکت کننده ارائه می شود.”
چه چیزی باعث می‌شود سیستم‌های مستقل مشارکت‌کننده نتوانند ارسال SSM بومی را به عنوان یک سرویس حمل‌ونقل اینترنتی ساده و به تدریج قابل استقرار ارائه دهند؟
به طور خاص، زمانی که R1 می پرسد شروع می شود (S,G):
-
مجموعه پروتکل موجود تا چه اندازه می تواند علاقه گیرنده را افزایش دهد
Sدر چندین سیستم مستقل که به طور مستقل عمل می کنند؟ -
چه اطلاعاتی باید از هر مرز AS بعلاوه دسترسی ساده unicast BGP عبور کند؟
-
آیا هر AS می تواند به طور مستقل سیاست های واردات، صادرات، مشتری، همتا، ترانزیت و مجوز منبع را اعمال کند یا اینکه چندپخشی نیاز به هماهنگی دارد که نمی تواند از طریق مکانیسم های خط مشی بین دامنه ای موجود بیان شود؟
-
آیا برای هر کدام به یک حالت انتقال AS میانی نیاز دارد؟
(S,G)کانالی که از آن عبور می کند؟ اگر چنین است، حد واقعی مقیاس چقدر است؟ -
متغیر مقیاس بندی مربوطه چیست؟
- تعداد منابع؟
- تعداد گروه ها؟
- تعداد فعال
(S,G)کانال ها؟ - تعداد رابط های گیرنده رو به رو؟
- تعداد شعب AS در پایین دست؟
- میزان پیوستن و خروج از رویدادها؟
- شکل دیگری از دولت؟
-
چه چیزی مانع از کنترل اتصالات نادرست، منابع ناخواسته، بازتاب، حملات خستگی حالت، یا تقویت ترافیک از طریق مجوز منبع، پذیرش سینک، محدود کردن نرخ، و فیلتر متقابل ارائه‌دهنده عادی می‌شود؟
-
یک ISP به چه اطلاعات حسابداری نیاز دارد که نمی تواند از آن استخراج شود:
- ترافیک دریافتی توسط مشتری یا شریک به منبع.
- ترافیک منتشر شده در هر پیوند پایین دست.
- وضعیت ارسال چندپخشی ارائه دهنده.
-
آیا منبع باید با هر فروشنده قرارداد جداگانه‌ای منعقد کند که حاوی یک گیرنده باشد، یا مجوز و پرداخت می‌تواند از روابط ساده مشتری، همتا، و حمل‌ونقل پیروی کند؟
-
اگر مکانیسم‌های پروتکل لازم از قبل وجود داشته باشد، چه ویژگی عملیاتی مانع از افشای آنها به عنوان یک سرویس مشتری شده است؟
من به دنبال پاسخی هستم که موانع را به دسته هایی مانند:
- مکانیزم پروتکلی که وجود ندارد.
- پروتکلی که وجود دارد اما پیاده سازی نمی شود.
- محدودیت های سخت افزاری تغییر مسیر
- کنترل مقیاس صفحه یا حالت مرجع.
- مسائل مربوط به همگرایی یا رسیدگی به خطا.
- ناسازگاری خط مشی مسیریابی بین دامنه ای
- امنیت یا سوء استفاده ای که نمی توان به اندازه کافی محدود کرد.
- الزامات حسابداری یا تسویه حساب
- نیاز به پیکربندی دوطرفه در هر مرز AC.
- عدم وجود یک مدل سرویس عرضه
- فقدان انگیزه تامین کننده، اگرچه مکانیسم های فنی کافی هستند.
در صورت امکان، من به جای اینکه به عباراتی مانند «چندپست مقیاس نمی‌شود»، «چندپست سخت است» یا «هر روتر باید آن را پشتیبانی کند»، پاسخی می‌خواهم که مکانیسم خاص و منبع محدود کننده را شناسایی کند.
من نمی‌پرسم که آیا فرستنده می‌تواند با روش دیگری به بسیاری از گیرندگان برسد.
CDN، رله برنامه، پلت فرم استریم ابری، پوشش همتا به همتا، یا یونیکست قابل تکرار می تواند مشکل تحویل برنامه را حل کند، اما تکرار را به میزبان های انتخابی منتقل می کند. این توضیح نمی دهد که چرا روترها در نقاط انحراف مسیر واقعی نمی توانند سرویس لایه شبکه شرح داده شده در بالا را ارائه دهند.
به طور مشابه، GRE، AMT، VPN و سایر تونل‌های چندپخشی تک‌پخشی می‌توانند جزایر چندپخشی را به هم متصل کنند. آنها توضیح نمی دهند که چه چیزی مانع از تبادل خدمات چندپخشی خود توسط شبکه های حمل و نقل مستقل می شود.
وجود شبکه های IPTV خصوصی، ستون فقرات تحقیقاتی، مبادلات چندپخشی یا شرکای چندپخشی با مذاکره جداگانه نیز موضوعی نیست. آنها نشان می دهند که چندپخشی می تواند از شبکه های مسیریابی و مرزهای اداری عبور کند. من می‌پرسم چه چیزی مانع این توانایی برای آهنگسازی خارج از مجموعه‌ای از شرکت‌کنندگان از پیش تعیین شده است.
همچنین نمی‌پرسم که اگر هر دستگاه مربوطه به صورت دستی برای یک جریان خاص پیکربندی شود، چندپخشی کار می‌کند یا خیر. این امر بدون شناسایی پروتکل، خط مشی، اعتماد، مقیاس‌بندی یا نیاز مدل خدماتی که چنین هماهنگی دستی را ضروری می‌کند، نتیجه مورد نظر را تکرار می‌کند.
یک پاسخ ایده آل می تواند از طریق مثال R1 باشد (S,G) دوباره به منبع ملحق شوید Sوضعیت و پیام های مورد نیاز در هر مرز AS را شناسایی کنید و اولین نقطه ای را که مکانیسم های موجود در آن کافی یا از نظر عملیاتی قابل قبول نیستند را مشخص کنید.
اگر هیچ مسدودکننده فنی واحدی وجود نداشته باشد، کوچکترین مجموعه تغییرات فنی محتمل (شامل پروتکل‌ها، پیکربندی، مجوز، گزارش‌دهی، یا شیوه‌های اتصال) چیست که به ISPهای پشتیبان اجازه می‌دهد تا انتقال SSM را بدون نیاز به پذیرش جهانی یا توافق جداگانه بین منبع و هر ISP پایین‌دستی ارائه دهند؟
افشا: از OpenAI ChatGPT برای کمک به ویرایش و ساختار این سوال استفاده شد. محتوای فنی آن را بررسی و اصلاح کردم.
