سرویس‌های چندپخشی (Multicast) بر بستر هسته‌های SRv6 / IPv6

مقدمه

هسته‌های ارائه‌دهنده خدمات (Service Provider) به‌طور پیوسته در حال حرکت به سمت انتقال صرفاً IPv6 و سرویس‌های Segment Routing over IPv6 (SRv6) هستند، اما مالتی‌کست (Multicast) را نمی‌توان به عنوان یک موضوع فرعی در نظر گرفت. هدف این است که موارد استفاده فعلی از مالتی‌کست وی‌پی‌ان (Multicast VPN) بدون معرفی یک مدل انتقال مالتی‌کست مجزا یا رفتار تکثیر (Replication) مختص SRv6، به جلو هدایت شوند.

رویکرد توصیف‌شده در اینجا، درخت چندپخشی (Multicast Tree) ارائه‌دهنده را به صورت بومی (Native) در IPv6 حفظ کرده و از BGP Multicast VPN (MVPN) برای سیگنال‌دهی سرویس استفاده می‌کند. SRv6 همچنان به عنوان بستر یونیکست (Unicast) و زمینه سرویس باقی می‌ماند؛ ارسال چندپخشی (Multicast Forwarding) نیز توسط PIMv6-SSM و کپسوله‌سازی (Encapsulation) IP-in-IP مدیریت می‌شود.

این مقاله در سه بخش تدوین شده است. بخش اول به اصول پایه Multicast VPN می‌پردازد: انواع درخت‌های اصلی (Core Tree)، مکانیزم‌های درخت توزیع مالتی‌کست (MDT) و مفاهیم PMSI که فارغ از نوع شبکه انتقال (Transport)، در هر پیاده‌سازی MVPN کاربرد دارند. بخش دوم، معماری مالتی‌کست سیسکو برای هسته‌های SRv6 / IPv6 را ارائه می‌دهد و نشان می‌دهد که چگونه این اصول پایه با استفاده از مالتی‌کست بومی IPv6، پروتکل PIMv6-SSM و BGP MVPN بر روی یک هسته IPv6 که برای سرویس‌های SRv6 استفاده می‌شود، پیاده‌سازی می‌گردند. بخش سوم، نمونه پیکربندی (Configuration) و اعتبارسنجی (Verification) مرتبط با یک توپولوژی مرجع را ارائه می‌دهد تا خواننده بتواند از مرحله مفهوم به مرحله پیاده‌سازی (Deployment) گام بردارد.

چرا مالتی‌کست (Multicast) اهمیت دارد

بارهای کاری مالتی‌کست (Multicast) در شبکه‌های ارائه‌دهندگان خدمات (Service Provider)، سازمانی (Enterprise) و دولتی به دلیل رشد رسانه‌های زنده، IPTV، داده‌های بازارهای مالی، سیستم‌های نظارتی و اینترنت اشیا (IoT) همچنان در حال افزایش است. با مهاجرت این شبکه‌ها به سمت SRv6، سرویس‌های مالتی‌کست نیز باید همگام با آن‌ها مهاجرت کنند.

معماری توصیف‌شده در این مقاله تضمین می‌کند که مالتی‌کست (Multicast) به‌صورت بومی (Natively) و بدون نیاز به زیرساخت‌های موازی یا پروتکل‌های هم‌پوشان (Overlay) خارج از پشته IPv6، به شبکه‌های IPv6/SRv6 منتقل شود.

اصول پایه (Fundamentals) شبکه خصوصی مجازی چندپخشی (Multicast VPN)

پیش از بررسی راهکار بومی IPv6، درک مفاهیم بنیادی Multicast VPN که زیربنای این معماری هستند، ضروری است. این بخش به بررسی بلوک‌های سازنده، انواع درخت‌های اصلی (Core Tree Types) و مکانیزم‌های MDT می‌پردازد که هر پیاده‌سازی Multicast VPN، صرف‌نظر از بستر انتقال (Transport) زیرین، به آن‌ها وابسته است.

درخت‌های هسته (Core Trees)

در معماری MVPN، روترهای لبه ارائه‌دهنده (PE) باید ترافیک مالتی‌کست (Multicast) مشتری را در سراسر هسته شبکه ارائه‌دهنده (Provider Core) منتقل کنند، بدون اینکه نیاز باشد روترهای هسته، وضعیت (State) مربوط به هر VPN را نگهداری کنند. این امر از طریق درخت‌های هسته (Core Trees) محقق می‌شود: درخت‌های توزیع مالتی‌کست در سطح ارائه‌دهنده که ترافیک کپسوله‌شده (Encapsulated) مشتری را بین روترهای PE جابه‌جا می‌کنند.

درخت هسته به طور رسمی رابط سرویس چندپخشی ارائه‌دهنده (PMSI) نامیده می‌شود. PMSI هسته ارائه‌دهنده را به عنوان یک تونل با قابلیت چندپخشی (Multicast) انتزاع می‌کند که روترهای لبه (PE) شرکت‌کننده در یک VPN مشخص را به یکدیگر متصل می‌نماید.

درخت‌های نقطه به چند نقطه (Point-to-Multipoint)

یک درخت نقطه به چند نقطه (P2MP) دارای یک ریشه واحد، یعنی PE ورودی (ingress PE)، و چندین برگ، یعنی PEهای خروجی (egress PE) با گیرنده‌های علاقه‌مند است. برخلاف تونل‌های نقطه به نقطه (P2P) که به یک مسیر مجزا برای هر مقصد نیاز دارند، یک درخت P2MP ترافیک را در نقاط انشعاب در هسته شبکه تکثیر کرده و یک نسخه از هر بسته را به طور کارآمد به تمام گیرنده‌های علاقه‌مند تحویل می‌دهد.

شکل 1: درخت نقطه به چند نقطه (P2MP) با یک PE ورودی که به چندین PE خروجی منشعب می‌شود. روترهای هسته (Core routers)، ترافیک را در نقاط انشعاب تکثیر می‌کنند.

• روتر PE ورودی به عنوان ریشه درخت عمل کرده و ترافیک مالتی‌کست (Multicast) مشتری را به هسته شبکه تزریق می‌کند.
• هر روتر PE خروجی که دارای گیرنده‌های فعال است، به عنوان یک برگ به این درخت می‌پیوندد.
• روترهای P در هسته شبکه، ترافیک را در نقاط انشعاب تکثیر می‌کنند. آن‌ها ترافیک مالتی‌کست را بدون هیچ‌گونه آگاهی از لایه پوششی (Overlay) مشتری، هدایت می‌کنند.
• ساختار درخت معمولاً به صورت گام‌به‌گام (Hop-by-hop) و با استفاده از PIM joins به سمت آدرس روتر PE ریشه ایجاد می‌شود.

این مدل، وضعیت هسته ارائه‌دهنده (Provider Core State) را متناسب با تعداد منابع فعال چندپخشی (Multicast Sources) نگه می‌دارد، نه تعداد جریان‌های مشتری (Customer Flows).

انواع PMSI

شکل 2: دو دسته‌بندی اصلی PMSI: مدل I-PMSI که با نام Default MDT نیز شناخته می‌شود، تمامی PEها را به یکدیگر متصل می‌کند، در حالی که S-PMSI که با نام Data MDT نیز شناخته می‌شود، تنها PEهای مورد نظر را به هم متصل می‌سازد.

چارچوب MVPN چندین نوع PMSI را تعریف می‌کند. دو مورد از مرتبط‌ترین آن‌ها عبارتند از:

نوع PMSI	محدوده درخت (Tree scope)	کاربرد
PMSI فراگیر (I-PMSI)	اتصال تمام PEها در یک VRF	MDT پیش‌فرض
PMSI انتخابی (S-PMSI)	اتصال تنها PEهای دارای گیرنده فعال	MDT داده

I-PMSI همیشه فعال است و سیگنالینگ کنترلی و ترافیک چندپخشی (Multicast) با نرخ پایین را حمل می‌کند. S-PMSI بر اساس تقاضا ایجاد می‌شود تا با ارسال جریان‌های با نرخ بالا تنها به PEهایی که به آن‌ها نیاز دارند، کارایی را بهینه کند.

MDT پیش‌فرض (Default MDT)

Default MDT درخت بنیادی است که تمامی روترهای PE شرکت‌کننده در یک نمونه VPN Routing and Forwarding (VRF) با قابلیت مالتی‌کست (Multicast) را به یکدیگر متصل می‌کند؛ این قابلیت همواره فعال است و به عنوان بستر انتقال پایه برای ترافیک مالتی‌کست مشتری و در مدل‌های مبتنی بر سیگنال‌دهی PIM، برای پیام‌های کنترل مالتی‌کست مشتری عمل می‌کند.

هنگامی که یک VRF با قابلیت مالتی‌کست (Multicast) پیکربندی می‌شود، به هر PE یک آدرس گروه مالتی‌کست برای Default MDT اختصاص می‌یابد. تمامی PEها در آن VRF به این گروه ملحق می‌شوند و یک درخت مالتی‌کست اشتراکی (Shared Multicast Tree) را در سراسر هسته شبکه ارائه‌دهنده (Provider Core) تشکیل می‌دهند.

از دیدگاه PIM که در لایه Overlay مربوط به VRF مشتری اجرا می‌شود، Default MDT می‌تواند مانند یک شبکه محلی مجازی (Virtual LAN) عمل کند که در آن تمامی PEها به عنوان همسایگان PIM متصل به صورت مستقیم ظاهر می‌شوند. در مدل BGP C-multicast که در این مقاله اعتبارسنجی شده است، کشف PE و درخواست‌های عضویت در مالتی‌کست مشتری (Customer multicast joins) توسط BGP MVPN سیگنال‌دهی می‌شوند؛ MDT تونل ارائه‌دهنده (Provider tunnel) لازم برای حمل ترافیک مالتی‌کست کپسوله‌شده مشتری را فراهم می‌کند.

ویژگی‌های کلیدی:

• همیشه روشن (Always on)MDT پیش‌فرض به محض پیکربندی VRF با قابلیت چندپخشی (Multicast) ایجاد می‌شود، صرف‌نظر از اینکه ترافیک مشتری در جریان باشد یا خیر.
• حمل ترافیک پایه مشتریجریان‌های چندپخشی (S,G) مشتری در ابتدا روی MDT پیش‌فرض ارسال می‌شوند، مگر اینکه یک Data MDT فعال شود.
• multicast از طریق مسیرهای BGP MVPN انجام می‌گیرد، در حالی که MDT به عنوان درخت انتقال ارائه‌دهنده عمل می‌کند.
• اشتراک‌گذاری بین خانواده‌های آدرس (Address Families)یک گروه MDT پیش‌فرض واحد، هم ترافیک چندپخشی IPv4 و هم IPv6 مشتری را در یک VRF یکسان پشتیبانی می‌کند.
• یک مورد برای هر VRFهر VRF با قابلیت چندپخشی، دارای MDT پیش‌فرض اختصاصی خود با یک گروه چندپخشی منحصربه‌فرد است.
• یک عدد برای هر VRF– هر VRF با قابلیت چندپخشی (Multicast) دارای Default MDT اختصاصی خود با یک گروه چندپخشی منحصر به فرد است.

از آنجایی که تمام تجهیزات PE در یک VRF از یک Default MDT واحد استفاده می‌کنند، هسته شبکه ارائه‌دهنده (Provider Core) به ازای هر VRF یک درخت مالتی‌کست (Multicast Tree) نگهداری می‌کند، نه به ازای هر جریان مشتری. این امر باعث می‌شود وضعیت هسته شبکه حتی با افزایش تعداد ورودی‌های مشتری قابل مدیریت باقی بماند.(S,G)ورودی‌ها افزایش می‌یابد.

با این حال، Default MDT ترافیک را به تمام PEها در VRF، از جمله آن‌هایی که گیرنده فعال ندارند، ارسال می‌کند. برای جریان‌های با نرخ پایین و ترافیک کنترلی، این سربار (Overhead) قابل قبول است. برای جریان‌های با پهنای باند (Bandwidth) بالا، Data MDT جایگزین کارآمدتری را ارائه می‌دهد.

شکل 3: حالت پیش‌فرض MDT ترافیک چندپخشی (Multicast) را به تمام PEها در VRF ارسال می‌کند. PEهایی که گیرنده علاقه‌مندی برای یک جریان (Flow) خاص ندارند، ترافیک ناخواسته را حذف (Drop) می‌کنند.

MDT داده (Data MDT)

قابلیت Data MDT محدودیت‌های کارایی در Default MDT را برطرف می‌کند. در حالی که Default MDT ترافیک را به تمام PEها در یک VRF ارسال می‌کند، Data MDT یک درخت انتخابی ایجاد می‌کند که تنها شامل PEهایی است که گیرنده‌های فعال برای یک مشتری خاص دارند(S,G)جریان (Flow)

شکل 4: Data MDT یک درخت P2MP انتخابی ایجاد می‌کند. تنها روترهای لبه (PE) که دارای گیرنده‌های فعال هستند به Data MDT ملحق می‌شوند؛ روترهای لبه (PE) بدون گیرنده، سیگنالینگ را کش (Cache) می‌کنند اما به آن ملحق نمی‌شوند.

توالی به شرح زیر است:

مرحله	عملکرد
1. فعال‌ساز آستانه (Threshold trigger)	روتر لبه ارائه‌دهنده ورودی (Ingress PE) نرخ ترافیک هر مشتری را نظارت می‌کند(S,G)روی Default MDT. هنگامی که یک جریان از آستانه پهنای باند (Bandwidth) قابل تنظیم فراتر رود، یا در صورت پیکربندی بلافاصله، روتر لبه ورودی یک Data MDT را آغاز می‌کند.
2. سیگنال‌دهی (Signaling)	روتر لبه ورودی یک مسیر BGP MVPN نوع 3، با قابلیت کشف خودکار S-PMSI، را به تمام روترهای لبه در VRF تبلیغ می‌کند. این مسیر مشتری(S,G)و گروه چندپخشی (Multicast) جدیدی که باید برای Data MDT استفاده شود را شناسایی می‌کند.
3. پیوستن انتخابی (Selective join)	فقط روترهای لبه خروجی (Egress PEs) که دارای گیرنده‌های فعال برای آن هستند(S,G)به درخت Data MDT جدید در هسته شبکه می‌پیوندند. روترهای لبه بدون گیرنده، این تبلیغ را کش (Cache) می‌کنند اما به آن نمی‌پیوندند.
4. سوئیچ‌اور (Switchover)	پس از یک دوره انتظار کوتاه (Hold-down period)، روتر لبه ورودی ترافیک مشتری را(S,G)از Default MDT به Data MDT منتقل می‌کند. اکنون جریان ترافیک فقط به روترهای لبه متقاضی تحویل داده می‌شود.

ویژگی‌های کلیدی:

• دانه-بندی (Granularity) به صورت (S,G) – هر Data MDT یک جریان (Flow) مشتری را حمل می‌کند. Data MDTها فقط برای درخت‌های خاص-منبع (Source-specific trees) اعمال می‌شوند و نه درخت‌های اشتراکی (Shared trees).ایجاد بر اساس تقاضا (On-demand creation) – Data MDTها تنها زمانی ایجاد می‌شوند که ترافیک از آستانه (Threshold) فراتر رود، که این امر باعث می‌شود وضعیت هسته (Core state) در دوره‌های کم‌ترافیک در حداقل باقی بماند.درخت P2MP مجزا – هر Data MDT از گروه مالتی‌کست (Multicast group) اختصاصی خود استفاده می‌کند و یک درخت P2MP مستقل در هسته ارائه‌دهنده (Provider core) ایجاد می‌نماید.

• ایجاد بر اساس تقاضا (On-demand creation)داده‌های MDT تنها زمانی ایجاد می‌شوند که ترافیک از آستانه (Threshold) فراتر رود، که این امر وضعیت هسته (Core state) را در دوره‌های کم‌ترافیک در حداقل نگه می‌دارد.
• درخت P2MP مجزاهر Data MDT از گروه مالتی‌کست (Multicast group) اختصاصی خود استفاده می‌کند و یک درخت P2MP مستقل در هسته ارائه‌دهنده (Provider core) ایجاد می‌نماید.
• سیگنال‌دهی شده با BGPمسیر نوع 3 (Type 3 route) تضمین می‌کند که تمام PEها از سوئیچ‌اور (Switchover) مطلع شوند؛ PEهای خروجی بر اساس تمایل گیرنده به صورت خودکار ملحق می‌شوند.
• قابل بازگشت (Reversible)اگر نرخ ترافیک به زیر آستانه کاهش یابد یا گیرنده‌ها قطع شوند، جریان می‌تواند به Default MDT بازگردد.

شکل 5: به‌روزرسانی BGP IPv4 MVPN که حاوی اطلاعات Data MDT است، شامل جزئیات تونل PMSI که توسط PE ورودی برای سیگنال‌دهی سوئیچ‌اور (Switchover) در Data MDT استفاده می‌شود.

جنبه	Default MDT	Data MDT
دامنه (Scope)	تمام PEها در VRF	فقط PEهای دارای گیرنده فعال
فعال‌سازی (Activation)	همیشه روشن (Always on)	بر اساس تقاضا و آستانه (On demand, threshold-based)
نوع ترافیک	کنترل و داده با نرخ پایین	نرخ بالا(S,G)جریان‌ها (Flows)
درخت هسته (Core tree)	یکی برای هر VRF	یکی برای هر جریان(S,G)سیگنال‌دهی (Signaling)
BGP MVPN نوع 1، کشف خودکار (Auto-Discovery)	BGP MVPN نوع 3، S-PMSI A-D	BGP MVPN نوع 3، S-PMSI A-D

در یک استقرار (Deployment) معمول، Default MDT وظیفه مدیریت اتصال چندپخشی (Multicast) پایه و جریان‌های چندپخشی با پهنای باند (Bandwidth) پایین را بر عهده دارد، در حالی که جریان‌های با پهنای باند (Bandwidth) بالا مانند کانال‌های IPTV و فیدهای ویدیویی زنده، برای تحویل کارآمد به Data MDTها منتقل می‌شوند.

کشف خودکار (Auto-Discovery) و سیگنال‌دهی (Signaling) پروتکل BGP

MVPN سنتی یا Draft-Rosen، برای ساختار درختی (Tree Construction) و کشف PE (PE Discovery) در هسته ارائه‌دهنده (Provider Core) به پروتکل PIM متکی بود. فناوری NG-MVPN که توسط RFC 6513 و RFC 6514 تعریف شده است، این فرآیند را با قابلیت کشف خودکار مبتنی بر BGP (BGP-based Auto-Discovery) جایگزین می‌کند؛ در این روش، PEها مشارکت خود در یک شبکه خصوصی مجازی چندپخشی (Multicast VPN) را از طریق BGP تبلیغ می‌کنند که این امر نیاز به مجاورت‌های PIM در سراسر Default MDT برای کشف PE را از بین می‌برد.

BGP MVPN دو عملکرد کلیدی را معرفی می‌کند:

• کشف خودکار (Auto-Discovery)– تجهیزات PE به‌صورت خودکار تشخیص می‌دهند که کدام‌یک از PEهای دیگر برای مالتی‌کست (Multicast) در یک VPN خاص فعال هستند. هر PE آدرس لوپ‌بک (Loopback) و عضویت VPN خود را از طریق BGP تبلیغ می‌کند که نیاز به پیکربندی دستی یا کشف مبتنی بر PIM را از بین می‌برد.
• – سیگنال‌دهی مشتری در Overlay: پیام‌های Join و Prune مالتی‌کست مشتری (C-multicast) به‌جای PIM، از طریق BGP بین تجهیزات PE سیگنال‌دهی می‌شوند. این بدان معناست که وضعیت مالتی‌کست مشتری به‌صورت مسیرهای C-multicast در به‌روزرسانی‌های BGP حمل می‌شود، نه به‌عنوان پیام‌های PIM که در سراسر Default MDT منتشر (Flood) می‌شوند.پیام‌های Join و Prune مربوط به C-multicast مشتری، به‌جای PIM بین دستگاه‌های PE، از طریق BGP ارسال (Signaled) می‌شوند. این بدان معناست که وضعیت مالتی‌کست مشتری به‌جای پیام‌های PIM که در سراسر Default MDT منتشر (Flooded) می‌شوند، در به‌روزرسانی‌های BGP به‌عنوان مسیرهای C-multicast حمل می‌شود.

هر به‌روزرسانی BGP MVPN که یک جریان مالتی‌کست (Multicast) مشتری را به یک تونل ارائه‌دهنده (Provider Tunnel) متصل می‌کند، دارای یک ویژگی تونل PMSI (PMSI Tunnel Attribute) است. این PTA شامل دو بخش اطلاعاتی حیاتی است:

• نوع تونل (Tunnel type)– پروتکل درخت اصلی (Core tree protocol) مانند PIM-SSM، mLDP P2MP، RSVP-TE P2MP یا IR را شناسایی می‌کند. این پارامتر به PE گیرنده می‌گوید که چگونه به درخت ارائه‌دهنده (Provider tree) متصل شود.
• شناسه تونل (Tunnel identifier)– نمونه خاص تونل را به صورت منحصربه‌فرد شناسایی می‌کند، مانند آدرس گروه مالتی‌کست برای PIM-SSM یا عنصر FEC برای mLDP. این پارامتر به PE گیرنده می‌گوید که به کدام درخت متصل شود.

PTA، صفحه کنترل (Control Plane) مربوط به BGP MVPN را به زیرساخت مالتی‌کست (Multicast) ارائه‌دهنده متصل می‌کند. این بخش در واقع پلی میان سیگنال‌دهی لایه اورلی (Overlay) و درخت لایه آندرلی (Underlay) است.

خانواده آدرس BGP MVPN هفت نوع مسیر (Route Type) را در RFC 6514 تعریف می‌کند. مواردی که بیشترین ارتباط را با این مقاله دارند عبارتند از:

• نوع 1، Intra-AS I-PMSI A-D– هر PE عضویت خود را در یک VPN چندپخشی (Multicast VPN) تبلیغ کرده و MDT پیش‌فرض را برقرار می‌کند.
• نوع 3، S-PMSI A-D– PE ورودی یک Data MDT را سیگنال‌دهی کرده و یک جریان (S,G) مشتری را به یک تونل ارائه‌دهنده انتخابی متصل می‌کند.(S,G)جریان به یک تونل ارائه‌دهنده انتخابی.
• نوع 5، Source Active A-D– PE منبع تبلیغ می‌کند که یک منبع چندپخشی مشتری فعال است؛ این مورد زمانی که VRF مشتری از PIM-SM استفاده می‌کند، کاربرد دارد.
• نوع 6، Shared Tree Join– یک PE خروجی تمایل خود را به یک درخت اشتراکی (Shared Tree) مشتری اعلام می‌کند؛ این مورد زمانی که VRF مشتری از PIM-SM استفاده می‌کند، کاربرد دارد.
• نوع 7، Source Tree Join– یک PE خروجی تمایل خود را به یک درخت منبع (Source Tree) مشتری اعلام می‌کند؛ این مورد برای پیوستن به درخت منبع، از جمله جریان‌های SSM استفاده می‌شود.

سایر انواع مسیرهای MVPN خارج از محدوده تأیید اعتبار Default MDT در یک سیستم خودمختار (AS) واحد هستند که در مثال پیکربندی استفاده شده است.

معماری هسته (Core Architecture) مبتنی بر SRv6 / IPv6

استراتژی مالتی‌کست (Multicast) سیسکو برای شبکه‌های هسته SRv6 / IPv6، استفاده از MVPN بر روی هسته IPv6 برای سرویس‌های SRv6 است که از PIMv6-SSM بومی در لایه زیرساخت (Underlay) و کپسوله‌سازی IP-in-IP برای ترافیک مشتری بهره می‌برد. در این معماری، ارسال مالتی‌کست از SRv6 SIDs، هدرهای مسیریابی بخش (Segment Routing Headers) یا فرمت‌های بسته SRv6 استفاده نمی‌کند؛ درخت ارائه‌دهنده (Provider tree) یک مالتی‌کست بومی IPv6 است. این رویکرد از استانداردهای بالغ مالتی‌کست IPv6 بدون نیاز به افزونه‌های مالتی‌کست اختصاصی SRv6 بهره می‌برد. سرویس‌های مالتی‌کست از همان هسته IPv6 استفاده‌شده برای یونیکست (Unicast) بهره می‌برند و نیازی به زیرساخت مالتی‌کست جداگانه نیست.

در آزمایشگاه اعتبارسنجی، SRv6 به گونه‌ای پیکربندی شده است که محیط نشان‌دهنده یک سرویس SRv6 L3VPN باشد، اما انتقال چندپخشی (Multicast transport) خود از IPv6/PIMv6 استفاده می‌کند و نه از ارسال SRv6 SID/SRH.

این معماری بر پایه رویه‌های MVPN در RFC 6513/6514، آدرس‌های زیرساخت IPv6 در RFC 6515، تبلیغ IPv4 NLRI با گام‌های بعدی (Next-hops) IPv6 در RFC 8950 و رفتار PIM-SM و PIM-SSM در RFC 7761 بنا شده است. زمینه سرویس SRv6 بر اساس RFC 8402 و RFC 8986 است، در حالی که تأثیر مسیر Flex-Algo توسط RFC 9350 و RFC 9502 پوشش داده می‌شود.

اصول طراحی:

• مالتی‌کست (Multicast) بومی IPv6– پروتکل PIMv6-SSM درخت‌های ارائه‌دهنده (Provider trees) را ایجاد می‌کند؛ هیچ مکانیزم جدیدی مختص SRv6 مورد نیاز نیست.
• لایه پوششی (Overlay) BGP MVPN– سیگنال‌دهی مالتی‌کست مشتری بین تجهیزات PE رخ می‌دهد.
• کپسوله‌سازی (Encapsulation) IP-in-IP– صفحه داده (Data plane) از انتقال سبک بدون لایه پوششی (Overlay shim) اضافی استفاده می‌کند.
• سادگی عملیاتی– مدل انتقال یکپارچه PIMv6-SSM MDT برای سرویس‌های مالتی‌کست VRF، به اپراتورها مجموعه‌ای واحد از رویه‌ها برای یادگیری و مجموعه‌ای واحد از دستورات show برای تسلط ارائه می‌دهد که جایگزین ترکیب‌های سنتی پروتکل‌ها می‌شود.

این رویکرد از پشتیبانی IETF چند-فروشنده (Multi-vendor) برخوردار است.draft-ietf-pim-multicast-over-srv6یک سند فعال در کارگروه PIM است که نویسندگانی از شرکت‌های Cisco، Juniper، Nokia، Aramco و Verizon دارد. به عنوان یک پیش‌نویس اینترنتی (Internet-Draft)، این سند باید به عنوان یک کار در حال پیشرفت تلقی شود، در حالی که طراحی اصلی همچنان از بلوک‌های سازنده مبتنی بر استانداردهای موجود استفاده می‌کند.

صفحه کنترل (Control Plane)

صفحه کنترل مالتی‌کست (Multicast control plane) از یک معماری دو-صفحه‌ای (Two-plane architecture) استفاده می‌کند:

• لایه پوششی (Overlay) BGP MVPNروترهای PE در نقش‌های Root، Mid و Tail، مسیرهای MVPN را از طریق Route Reflector برای کشف خودکار (Auto-Discovery) و سیگنال‌دهی مالتی‌کست مشتری تبادل می‌کنند. در این لایه پوششی، نیازی به مجاورت مستقیم PIM بین روترهای PE نیست.
• لایه زیرساخت (Underlay) IPv6همان شبکه IPv6 که برای SRv6 unicast استفاده می‌شود. پروتکل PIMv6-SSM در این لایه زیرساخت اجرا می‌شود تا درخت‌های توزیع مالتی‌کست بومی IPv6 را ایجاد کند. تمامی روترها شامل Root، Mid و Tail به عنوان PE و روترهای P1/P2 به عنوان روترهای ترانزیت در این فرآیند مشارکت دارند، با این تفاوت که P1 و P2 منحصراً در این لایه فعالیت می‌کنند و هیچ آگاهی از وضعیت VPN مشتری ندارند.

شکل 6: سرویس‌های چندپخشی (Multicast) بر بستر هسته‌های SRv6 / IPv6 از یک معماری دو لایه استفاده می‌کنند: لایه پوششی (Overlay) BGP MVPN برای سیگنال‌دهی سرویس و لایه زیرساخت (Underlay) IPv6 همراه با PIMv6-SSM برای انتقال چندپخشی ارائه‌دهنده.

کشف هم‌پوشانی (Overlay) پروتکل BGP

با استفاده از مکانیزم کشف خودکار (Auto-Discovery) در BGP MVPN که پیش‌تر معرفی شد، هر یک از تجهیزات PE، Root، Mid و Tail، یک مسیر (Route) نوع 1 از نوع Intra-AS I-PMSI A-D را از طریق RR تبلیغ می‌کنند. مسیر نوع 1 حامل ویژگی تونل PMSI (PMSI Tunnel Attribute) است که نوع تونل، PIM-SSM، منبع MDT، آدرس لوپ‌بک (Loopback) تجهیز PE و گروه MDT را که برای هر VRF منحصربه‌فرد است، مشخص می‌کند. در پایان این تبادل، هر سه تجهیز PE از وجود یکدیگر آگاه شده و دقیقاً می‌دانند که چگونه درخت زیرساخت (Underlay tree) را ایجاد کنند، اما هنوز هیچ درختی ساخته نشده است.

ایجاد درخت زیرساخت (Underlay Tree) برای PIMv6-SSM

با دریافت PMSI TA در حین کشف لایه پوششی (Overlay Discovery)، هر PE آدرس منبع و گروه MDT را خوانده و PIMv6-SSM را آغاز می‌کند.(S,G)به سمت لوپ‌بک‌های (Loopback) سایر PEها متصل می‌شود. این اتصالات (Joins) به صورت گام‌به‌گام از طریق P1 و P2 (روترهای ترانزیت) و Mid (گره bud که هم به عنوان گام ترانزیت و هم به عنوان PE عمل می‌کند) منتشر شده و به ازای هر PE، یک درخت P2MP با ریشه منبع ایجاد می‌کنند. در مجموع، این درخت‌های اختصاصی هر PE، اتصال MDT دوطرفه بین PEها را فراهم می‌کنند، در حالی که هر درخت به صورت مجزا در یک PE ریشه دارد. روترهای ترانزیت در PIM مشارکت دارند اما از وضعیت VPN آگاهی ندارند. این یک مالتی‌کست (Multicast) بومی IPv6 خالص است.

در پایان راه‌اندازی صفحه کنترل (Control Plane)، هسته ارائه‌دهنده (Provider Core) دارای درخت‌های PIM دوطرفه است که تمامی PEها را به یکدیگر متصل می‌کند و فرآیند کشف خودکار BGP (BGP Auto-discovery) نیز تکمیل شده است.

شکل 7: پایان راه‌اندازی صفحه کنترل (Control Plane). تبادل BGP برای کشف خودکار (Auto-discovery)، تجهیزات PE را از طریق RR متصل می‌کند، در حالی که درخت‌های PIMv6-SSM در هسته (Core) شبکه ساخته می‌شوند.

سیگنالینگ اتصال مشتری (Customer Join Signaling)

هنگامی که یک گیرنده درخواست IGMP/PIM join را برای یک مشتری ارسال می‌کند(S,G)، روتر لبه خروجی (Egress PE) مانند Tail، یک جستجوی مسیر معکوس (RPF) در VRF انجام می‌دهد که از طریق BGP next-hop به روتر لبه ورودی (Ingress PE) اشاره دارد، سپس یک مسیر BGP MVPN Type 7 Source Tree Join تولید کرده و آن را از طریق RR به روتر لبه ورودی (Root) تبلیغ می‌کند. Root ورودی VRF خود را برای هدایت جریان ترافیک آن مشتری به سمت Default MDT برنامه‌ریزی می‌کند. در این فرآیند، نیازی به سیگنال‌دهی PIM بین روترهای لبه (PEs) نیست و تنها از BGP استفاده می‌شود.

صفحه داده (Data Plane)

مشتری(S,G)ترافیک از سمت CE به Root (که همان PE ورودی است) می‌رسد، در قالب IP-in-IPv6 کپسوله‌سازی شده و بر روی درخت ساخته شده توسط PIM ارسال می‌شود. P1 و P2 بسته را به عنوان مالتی‌کست IPv6 بومی (Native) ارسال کرده و هرگز محتوای داخلی مشتری را بررسی نمی‌کنند. در Tail (که همان PE خروجی است)، هدر بیرونی حذف شده و بسته مشتری به گیرنده تحویل داده می‌شود. PEها هم یک ورودی P(S,G) برای ارائه‌دهنده و هم یک ورودی C(S,G) برای مشتری نگهداری می‌کنند؛ روترهای ترانزیت تنها بر اساس ورودی ارائه‌دهنده (Provider) عملیات ارسال را انجام می‌دهند.ورودی P(S,G)و یک مشتریورودی C(S,G)؛ روترهای ترانزیت بر اساس آن هدایت (Forward) می‌کنندورودی P(S,G)فقط.

شکل 8: ارسال (Forwarding) در صفحه داده (Data plane) با وضعیت P(S,G) ارائه‌دهنده برای ارسال مالتی‌کست IPv6 در هسته شبکه و وضعیت C(S,G) مشتری برای تحویل VRF. روترهای هسته (Core routers) به صورت بومی (Natively) عملیات ارسال را انجام می‌دهند؛ تنها روترهای لبه (Edge PEs) عملیات کپسوله‌سازی (Encapsulation) و کپسوله‌زدایی (Decapsulation) را انجام می‌دهند.

کپسوله‌سازی (Encapsulation) به صورت ساده IP-in-IPv6 است و شامل هیچ‌گونه GRE، MPLS یا هدر تونل (Tunnel Header) اضافی نمی‌باشد.

شکل 9: کپسوله‌سازی (Encapsulation) ترافیک مشتری IPv4 با استفاده از IP-in-IPv6. فیلد Next Header در IPv6 ارائه‌دهنده بر روی عدد 4 تنظیم شده است، زیرا هدر داخلی مشتری از نوع IPv4 می‌باشد.

در لبه ورودی (Ingress PE)، بسته IPv4 مشتری در یک هدر IPv6 بیرونی ارائه‌دهنده کپسوله‌سازی (Encapsulation) می‌شود؛ روترهای ترانزیت به صورت بومی (Natively) عملیات فورواردینگ را انجام می‌دهند؛ در لبه خروجی (Egress PE)، هدر بیرونی حذف می‌شود. فیلدNext Headerدر هدر IPv6 ارائه‌دهنده باید روی مقدار4تنظیم شود، زیرا هدر IP مشتری یک هدر IPv4 است.

شکل 10: کپسوله‌سازی (Encapsulation) ترافیک مشتری IPv6 با استفاده از IP-in-IPv6. فیلد Next Header در IPv6 ارائه‌دهنده بر روی 41 تنظیم شده است، زیرا هدر داخلی مشتری از نوع IPv6 است.

جریان ترافیک مشتری IPv6 مشابه است، اما هدر داخلی یک هدر مشتری IPv6 می‌باشد.فیلدNext Header41در هدر IPv6 ارائه‌دهنده باید روی این مقدار تنظیم شود، زیرا هدر IP مشتری یک هدر IPv6 است.

روترهای Transit P تنها به پشتیبانی از IPv6 multicast بومی و PIMv6 نیاز دارند؛ آن‌ها بسته‌های IPv6 multicast بومی را بدون آگاهی از لایه هم‌پوشانی (Overlay) فوروارد می‌کنند. تنها روترهای لبه (Edge PEs) به قابلیت VPN چندپخشی (Multicast VPN) نیاز دارند که این امر باعث به حداقل رساندن فضای استقرار (Deployment footprint) می‌شود.

چرا دو پروتکل؟پروتکل BGP هماهنگی بین PEها را انجام می‌دهد و تعیین می‌کند چه کسی با مسیرهای نوع 1 (Type 1 routes) مشارکت می‌کند و چه کسی با مسیرهای نوع 7 (Type 7 routes) چه ترافیکی را درخواست دارد. پروتکل PIM مسیر ارسال چندپخشی (Multicast forwarding path) را از طریق روترهای هسته (Core routers) ایجاد می‌کند. روترهای هسته از PIM استفاده می‌کنند اما هرگز با BGP MVPN درگیر نمی‌شوند. PEها هر دو پروتکل را اجرا می‌کنند، اما برای اهداف متفاوت.

پیکربندی نمونه (Sample Configuration)

بخش‌های پیکربندی (Configuration) و تایید (Verification) زیر از این توپولوژی مرجع استفاده می‌کنند.

شکل 11: توپولوژی مرجع سرویس‌های چندپخشی (Multicast) بر بستر هسته‌های SRv6 / IPv6. ریشه (Root) همان PE ورودی، Mid یک PE گره میانی (bud-node)، Tail همان PE خروجی، P1/P2 روترهای ترانزیت و RR بازتاب‌دهنده مسیر (Route Reflector) است.

Root گره ورودی/منبع PE، Mid یک گره bud-node PE، Tail یک گره خروجی/گیرنده PE، P1/P2 روترهای ترانزیت (Transit Routers) و RR بازتاب‌دهنده مسیر (Route Reflector) هستند. میزبان‌های متصل (Attached hosts) نشان‌دهنده نقاط پایانی ترافیک اعتبارسنجی (Validation traffic endpoints) می‌باشند.

گره (Node)	نقش (Role)	آدرس IPv6 اینترفیس Loopback0	آدرس IPv4 اینترفیس Loopback0
ریشه (Root)	روتر لبه (PE) ورودی/منبع	2001:db8:100::1/128	192.0.2.1/32
P1	روتر میانی (Transit P router)	2001:db8:100::2/128	192.0.2.2/32
میانی (Mid)	روتر لبه (PE) گره Bud	2001:db8:100::3/128	192.0.2.3/32
P2	روتر میانی (Transit P router)	2001:db8:100::4/128	192.0.2.4/32
انتها (Tail)	روتر لبه (PE) گیرنده/خروجی	2001:db8:100::5/128	192.0.2.5/32
RR	بازتاب‌دهنده مسیر (Route Reflector)	2001:db8:100::6/128	192.0.2.6/32

این قطعات شامل مؤلفه‌های اختصاصی مالتی‌کست (Multicast) و خانواده‌های آدرس BGP مرتبط با این مثال هستند. فرض بر این است که دسترسی IPv6 یونیکست (Unicast) از طریق هسته ارائه‌دهنده (Provider Core)، شامل IS-IS، مکان‌یاب‌های SRv6 و دسترسی Loopback0، از قبل عملیاتی شده است. خطوط SRv6 زمینه سرویس L3VPN را فراهم می‌کنند؛ درخت مالتی‌کست (Multicast Tree) همچنان به صورت IPv6 مالتی‌کست بومی (Native) باقی می‌ماند.

اعتبارسنجی در سطح بسته (Packet-level validation) در این مقاله بر روی یک جریان چندپخشی (Multicast) مشتری IPv4 متمرکز است که از طریق یک MDT پیش‌فرض IPv6 منتقل می‌شود:

• منبع مشتری (Customer source):198.51.100.100
• گروه مشتری (Customer group):232.1.1.1
• وی‌آراف (VRF):قرمز (red)
• گروه پیش‌فرض ام‌دی‌تی (Default MDT group):ff3e::8000:1

PE ورودی ریشه (Root Ingress PE)

استفاده‌های ریشه (Root)2001:db8:100::1, AS65000, و VRFred.

router bgp 65000
 mvpn
 bgp router-id 192.0.2.1
 address-family ipv4 unicast
!
 address-family vpnv4 unicast
!
 address-family ipv6 unicast
!
 address-family vpnv6 unicast
!
 address-family ipv4 mvpn
!
 address-family ipv6 mvpn
!
 neighbor 2001:db8:100::6
 remote-as 65000
 update-source Loopback0
 address-family vpnv4 unicast
!
 address-family vpnv6 unicast
!
 address-family ipv6 unicast
!
 address-family ipv4 mvpn
!
 address-family ipv6 mvpn
!
!
 vrf red
 rd auto
 address-family ipv4 unicast
 segment-routing srv6
 locator MAIN
 alloc mode per-vrf
!
 redistribute connected
 redistribute static
!
 address-family ipv6 unicast
 segment-routing srv6
 locator MAIN
 alloc mode per-vrf
!
 redistribute connected
!
 address-family ipv4 mvpn
!
 address-family ipv6 mvpn
!
!
router static
 vrf red
 address-family ipv4 unicast
 198.51.100.100/32 198.51.100.1
!
!
!
route-policy rpf-for-srv6-mcast
 set core-tree pim-default-v6
end-policy
multicast-routing
 address-family ipv6
 interface all enable
!
 vrf red
 address-family ipv4
 mdt source ipv6 Loopback0
 interface all enable
 bgp auto-discovery pim6
!
 mdt default ipv6 ff3e::8000:1
!
 address-family ipv6
 mdt source ipv6 Loopback0
 interface all enable
 bgp auto-discovery pim6
!
 mdt default ipv6 ff3e::8000:1
!
!
!
router pim
 address-family ipv6
 interface Loopback0
 enable
!
 interface HundredGigE0/0/0/0
 enable
!
!
 vrf red
 address-family ipv4
 rpf topology route-policy rpf-for-srv6-mcast
 mdt c-multicast-routing bgp
!
 interface HundredGigE0/0/0/2
 enable
!
!
 address-family ipv6
 rpf topology route-policy rpf-for-srv6-mcast
 mdt c-multicast-routing bgp
!
 interface HundredGigE0/0/0/2
 enable
!
!
!
!

همان ساختار PE برای Mid اعمال می‌شود،2001:db8:100::3، و Tail،2001:db8:100::5؛ تنها آدرس‌های لوپ‌بک (Loopback addresses)، مکان‌یاب SRv6، شناسه روتر BGP و رابط رو به CE متفاوت هستند. در آزمایشگاه اعتبارسنجی، Root یک مسیر ایستا (Static route) را برای منبع مشتری IPv4 بازتوزیع می‌کند تا PEهای گیرنده دارای دسترسی یونیکست/RPF برای198.51.100.100/32.

یادداشت‌های پیکربندی (Configuration):

• mdt default ipv6 ff3e::8000:1– گروه IPv6 SSM برای MDT پیش‌فرض؛ هر VRF یک گروه منحصر به فرد دریافت می‌کند.
• mdt source ipv6 Loopback0– اینترفیس Loopback0 در PE که به عنوان منبع درخت PIM استفاده می‌شود. این اینترفیس باید از طریق زیرساخت (Underlay) IPv6 قابل دسترس باشد.
• bgp auto-discovery pim6– فعال‌سازی کشف خودکار (Auto-discovery) در BGP MVPN با استفاده از تونل ارائه‌دهنده PIMv6-SSM.
• rpf topology route-policy rpf-for-srv6-mcast– هدایت RPF برای استفاده از درخت هسته (Core tree) PIMv6-SSM.
• mdt c-multicast-routing bgp– تولید مسیرهای نوع 7 MVPN به جای PIM روی MDT برای وضعیت C-multicast.
• پروتکل PIM روی Loopback0 و تمامی اینترفیس‌های رو به هسته (Core-facing) فعال است که درخت‌های زیرساخت (Underlay) PIMv6-SSM را می‌سازد.
• address-family ipv4 mvpnوaddress-family ipv6 mvpnخانواده‌های آدرس MVPN هستند که در این اعتبارسنجی IOS XR استفاده شده‌اند. آن‌ها را باvpnv4 multicast or vpnv6 multicast.

بازتاب‌دهنده مسیر (Route Reflector)

RR از2001:db8:100::6و AS استفاده می‌کند65000.

router bgp 65000
 mvpn
 bgp router-id 192.0.2.6
 address-family ipv4 unicast
!
 address-family vpnv4 unicast
!
 address-family ipv6 unicast
!
 address-family vpnv6 unicast
!
 address-family ipv4 mvpn
!
 address-family ipv6 mvpn
!
! Root (PE1)
 neighbor 2001:db8:100::1
 remote-as 65000
 update-source Loopback0
 address-family ipv4 unicast
 route-reflector-client
!
 address-family vpnv4 unicast
 route-reflector-client
!
 address-family ipv6 unicast
 route-reflector-client
!
 address-family vpnv6 unicast
 route-reflector-client
!
 address-family ipv4 mvpn
 route-reflector-client
!
 address-family ipv6 mvpn
 route-reflector-client
!
!
! Mid (PE2)
 neighbor 2001:db8:100::3
 remote-as 65000
 update-source Loopback0
 address-family ipv4 unicast
 route-reflector-client
!
 address-family vpnv4 unicast
 route-reflector-client
!
 address-family ipv6 unicast
 route-reflector-client
!
 address-family vpnv6 unicast
 route-reflector-client
!
 address-family ipv4 mvpn
 route-reflector-client
!
 address-family ipv6 mvpn
 route-reflector-client
!
!
! Tail (PE3)
 neighbor 2001:db8:100::5
 remote-as 65000
 update-source Loopback0
 address-family ipv4 unicast
 route-reflector-client
!
 address-family vpnv4 unicast
 route-reflector-client
!
 address-family ipv6 unicast
 route-reflector-client
!
 address-family vpnv6 unicast
 route-reflector-client
!
 address-family ipv4 mvpn
 route-reflector-client
!
 address-family ipv6 mvpn
 route-reflector-client
!
!
!

RR نیازی به پیکربندی VRF ندارد؛ این دستگاه تنها مسیرهای BGP MVPN را بازتاب (Reflect) می‌دهد. هر سه PE، شامل Root، Mid و Tail، در وضعیتroute-reflector-clientتحتipv4 mvpnوipv6 mvpnقرار دارند. خانواده‌های آدرس (Address Families) تک‌پخشی (Unicast) VPN همچنان برای دسترسی به مسیرهای مشتری مورد نیاز هستند.

روترهای ترانزیت (Transit Routers)

P1 استفاده می‌کند از2001:db8:100::2; P2 استفاده می‌کند از2001:db8:100::4.

multicast-routing
 address-family ipv6
 interface all enable
!
!
router pim
 address-family ipv6
 interface HundredGigE0/0/0/0
 enable
!
 interface HundredGigE0/0/0/1
 enable
!
 interface HundredGigE0/0/0/2
 enable
!
!
!

روترهای P تنها به مسیریابی (Routing) چندپخشی (Multicast) جهانی IPv6 و پروتکل PIMv6 بر روی اینترفیس‌های متصل به هسته شبکه نیاز دارند و نیازی به پیکربندی BGP MVPN، VRF و یا مسیریابی چندپخشی VRF ندارند. این روترها ترافیک چندپخشی بومی (Native) IPv6 را هدایت کرده و درخواست‌های عضویت PIMv6-SSM را به صورت گام‌به‌گام (Hop-by-hop) بدون هیچ‌گونه آگاهی از وضعیت VPN مشتری، منتشر می‌کنند.

پروتکل PIM تنها بر روی رابط‌های (Interfaces) مورد نیاز که به سمت هسته شبکه (Core) هستند، فعال می‌شود. این کار از فعال‌سازی ناخواسته PIM بر روی لینک‌های غیرضروری جلوگیری می‌کند؛interface all enableتحت (under)multicast-routingتنها به عنوان یک قابلیت تسهیل‌کننده در محیط آزمایشگاهی (Lab) حفظ شده است.

تأیید (Verification)

مراحل تأیید زیر، لایه به لایه وضعیت چندپخشی (Multicast) را بررسی می‌کنند و با ترتیبی که صفحه کنترل (Control Plane) ایجاد می‌شود، مطابقت دارند: ابتدا کشف خودکار BGP MVPN، سپس درخت‌های PIM ارائه‌دهنده (Provider PIM trees)، سپس درخواست‌های عضویت چندپخشی مشتری (Customer multicast joins) و در نهایت ارسال در صفحه داده (Data-plane forwarding). دستورات را با استفاده از توپولوژی مرجع بر روی روترهای مشخص‌شده اجرا کنید.

گام 1: کشف خودکار (Auto-Discovery) در BGP MVPN

پس از فعال‌سازیbgp auto-discovery pim6بر روی تمامی PEها، هر PE یک مسیر Type 1, Intra-AS I-PMSI A-D ایجاد می‌کند که حامل یک ویژگی تونل PMSI (PMSI Tunnel Attribute) است و به PEهای راه دور نحوه اتصال به MDT پیش‌فرض آن را اطلاع می‌دهد.

! === Root - verify Type 1 exchange ===
show bgp ipv4 mvpn route-type 1
! Expected: Three Type 1 routes - one local, two received via RR:
! *> [1][2001:db8:100::1]/136
! *>i[1][2001:db8:100::3]/136
! *>i[1][2001:db8:100::5]/136
! The "i" prefix means iBGP-learned; absence means locally originated.
! === RR - verify it reflects all three Type 1 routes ===
show bgp ipv4 mvpn route-type 1
! Expected: All three PE Type 1 routes, each with the originator's loopback as next-hop:
! *>i[1][2001:db8:100::1]/136
! *>i[1][2001:db8:100::3]/136
! *>i[1][2001:db8:100::5]/136

به‌صورت اختیاری، ویژگی PMSI Tunnel Attribute را در داخل یک مسیر (Route) نوع 1 بررسی کنید تا پارامترهای درخت زیرساخت (Underlay tree) تأیید شوند.

! === Tail - inspect Root's Type 1 detail ===
show bgp ipv4 mvpn [1][2001:db8:100::1]/136 detail
! Key fields to verify in the output:
! PMSI: flags 0x00, type 3 (PIM SSM), label 0
! Originating PE: 2001:db8:100::1
! Multicast Group: ff3e::8000:1
!
! This tells Tail: "To receive Root's MDT traffic, join the PIMv6-SSM tree
! (2001:db8:100::1, ff3e::8000:1)."
! PMSI tunnel type 3 = PIM-SSM. This is separate from BGP MVPN route type 3,
! which is S-PMSI A-D / Data MDT signaling.

گام 2: درخت‌های PIM ارائه‌دهنده (Provider PIM Trees)

با تحریک اطلاعات PMSI در مسیرهای نوع 1 (Type 1 routes)، هر PE فرآیند PIMv6-SSM join را به سمت لوپ‌بک‌های (loopbacks) سایر PEها برای گروه آغاز می‌کندff3e::8000:1. روترهای ترانزیت P1 و P2 این درخواست‌های join را به صورت گام‌به‌گام (hop-by-hop) هدایت می‌کنند، بدون اینکه نیازی به آگاهی از BGP باشد.

! === Root - verify provider PIM trees ===
show pim ipv6 topology ff3e::8000:1
! Expected: P(S,G) entries for the Default MDT group ff3e::8000:1:
!
! (2001:db8:100::1, ff3e::8000:1) SPT - Root's own tree
! RPF: Loopback0,2001:db8:100::1*
! Loopback0 fwd LI LH
! HundredGigE0/0/0/0 fwd Join
!
! (2001:db8:100::5, ff3e::8000:1) SPT - Tail's tree
! RPF: HundredGigE0/0/0/0,fe80::...
! Loopback0 fwd LH MVS MV6S
!
! "MV6S" flag = IPv6 multicast VPN source - indicates this tree feeds the MDT.
! "LI" = local interest, "LH" = last hop.
! === P2 (transit router) - verify hop-by-hop PIM state ===
show pim ipv6 topology ff3e::8000:1
! Expected: P2 is pure transit - no VRF and no MVPN state:
!
! (2001:db8:100::1, ff3e::8000:1) SPT
! RPF: toward Root's direction (HundredGigE0/0/0/0 toward Mid/P1)
! Outgoing: toward Tail (HundredGigE0/0/0/1)
!
! (2001:db8:100::5, ff3e::8000:1) SPT
! RPF: toward Tail's direction (HundredGigE0/0/0/1)
! Outgoing: toward Root/Mid (HundredGigE0/0/0/0)
!
! P2 forwards native IPv6 multicast only.
! === Tail - verify provider PIM trees ===
show pim ipv6 topology ff3e::8000:1
! Expected: Mirror image of Root:
!
! (2001:db8:100::1, ff3e::8000:1) SPT - Root's tree (Tail joined it)
! RPF: toward P2 (incoming from core)
! Loopback0 fwd LH MV6S
!
! (2001:db8:100::5, ff3e::8000:1) SPT - Tail's own tree
! RPF: Loopback0,2001:db8:100::5*
! Loopback0 fwd LI LH
! HundredGigE0/0/0/0 fwd Join

گام 3: پیوستن چندپخشی (Multicast Join) مشتری

هنگامی که یک گیرنده (Receiver) درخواست IGMP یا PIM join را برای یک مشتری ارسال می‌کند،(S,G)، روتر PE گیرنده وضعیت VRFC(S,G)را ایجاد کرده و یک مسیر BGP MVPN Type 7 Source Tree Join را آغاز می‌کند. روتر PE ورودی (Ingress PE)، که نقش Root را دارد، این Type 7 را از طریق RR دریافت کرده و ارسال ترافیک مشتری را بر روی MDT آغاز می‌کند.

! === Tail - verify VRF customer multicast state after receiver joins ===
show pim vrf red topo 232.1.1.1 198.51.100.100
! Expected for customer flow (198.51.100.100, 232.1.1.1):
!
! (198.51.100.100,232.1.1.1) SPT
! JP: Join(BGP) RPF: mdt6red,2001:db8:100::1
! HundredGigE0/0/0/1 fwd Join(...) LI
!
! KEY INDICATORS:
! "Join(BGP)" - the join was signaled via BGP Type 7, NOT PIM over the MDT.
! "RPF: mdt6red,2001:db8:100::1" - RPF points to Root via the MDT tunnel interface.
! The outgoing interface is toward the CE/receiver.
! === Tail - verify Type 7 route originated locally ===
show bgp ipv4 mvpn route-type 7
! Expected: locally originated Type 7 encoding the customer C-source and C-group:
! *> [7][192.0.2.1:0][65000][32][198.51.100.100][32][232.1.1.1]/184
! 0.0.0.0 0 i
!
! Route encoding: [Type][RD][Source-AS][SrcLen][C-Source][GrpLen][C-Group]
! Next-hop 0.0.0.0 = locally originated.
! === Root - verify VRF customer multicast state after receiving Type 7 ===
show pim vrf red topo 232.1.1.1 198.51.100.100
! Expected:
! (198.51.100.100,232.1.1.1) SPT
! JP: Join(...) RPF: HundredGigE0/0/0/2,198.51.100.1
! mdt6red fwd BGP
!
! KEY INDICATORS:
! "Join(now)" - Root has an active join for this C(S,G).
! "RPF: HundredGigE0/0/0/2,198.51.100.1" - RPF toward the CE/source.
! "mdt6red fwd BGP" - outgoing onto the MDT tunnel, triggered by BGP Type 7.
! === Root - verify Type 7 received from a receiver PE via RR ===
show bgp ipv4 mvpn route-type 7
! Expected: Type 7 received from a receiver PE via RR:
! *>i[7][192.0.2.1:0][65000][32][198.51.100.100][32][232.1.1.1]/184
! 2001:db8:100::3 100 0 i
!
! If both Mid and Tail have active receivers, the RR can learn one Type 7 route
! per receiver PE. The ingress PE installs the selected path or paths according
! to normal BGP best-path and multipath behavior.

گام 4: صفحه داده (Data Plane) مشتری IPv4

پس از همگرایی کامل صفحه کنترل (Control Plane)، اطمینان حاصل کنید که ترافیک چندپخشی (Multicast) IPv4 مشتری، به صورت سرتاسری (End-to-End) بر روی IPv6 MDT در جریان است.

در تنظیمات اعتبارسنجی، میزبان‌های تولیدکننده و دریافت‌کننده ترافیک به رابط‌های سمت مشتری (Customer-facing interfaces) در PE متصل شدند تا تحویل بسته برای جریان IPv4 SSM اثبات شود. یک میزبان منبع ترافیک، ترافیک چندپخشی (Multicast) UDP را از198.51.100.100به سمت232.1.1.1. میزبان‌های دریافت‌کننده در پشت Mid و Tail به گروه ملحق شدند و هر کدام جریان کامل بسته‌ها را دریافت کردند. میزبان‌های اعتبارسنجی متصل‌شده تنها برای تولید و دریافت ترافیک چندپخشی مشتری استفاده می‌شوند؛ آن‌ها بخشی از معماری سرویس چندپخشی ارائه‌دهنده (Provider) نیستند.

! === Root - confirm customer traffic is encapsulated onto the MDT ===
show mrib vrf red route 232.1.1.1 198.51.100.100
! Expected: forwarding entry for the customer (S,G) with:
! Incoming interface: HundredGigE0/0/0/2
! Outgoing interface: mdt6red
! === Tail - confirm customer traffic is decapsulated from the MDT ===
show mrib vrf red route 232.1.1.1 198.51.100.100
! Expected: forwarding entry for the customer (S,G) with:
! Incoming interface: mdt6red
! Outgoing interface: HundredGigE0/0/0/1
! === Provider core - confirm native IPv6 MDT state ===
show mrib ipv6 route ff3e::8000:1
! Expected: provider P(S,G) entries for the PE loopbacks and MDT group.
! On transit P routers, the entries should contain only core-facing physical interfaces,
! with no VRF, no BGP MVPN, and no MDT tunnel interface.

خروجی اعتبارسنجی آزمایشگاهی نمونه از تست بسته IPv4:

TrafficSource:
 1000 packets sent from 198.51.100.100 to 232.1.1.1 UDP/5000
MidReceiver:
 1000 packets received
 rx1000 from 198.51.100.100... srv6-mcast seq=1000
TailReceiver:
 1000 packets received
 rx1000 from 198.51.100.100... srv6-mcast seq=1000

وضعیت نماینده PE در حالی که ترافیک فعال بود:

Root:
 (198.51.100.100,232.1.1.1) SPT
 RPF: HundredGigE0/0/0/2,198.51.100.1
 mdt6red fwd BGP
 Incoming Interface List
 HundredGigE0/0/0/2
 Outgoing Interface List
 mdt6red
Mid:
 (198.51.100.100,232.1.1.1) SPT
 JP: Join(BGP) RPF: mdt6red,2001:db8:100::1
 Incoming Interface List
 mdt6red
 Outgoing Interface List
 HundredGigE0/0/0/2
Tail:
 (198.51.100.100,232.1.1.1) SPT
 JP: Join(BGP) RPF: mdt6red,2001:db8:100::1
 Incoming Interface List
 mdt6red
 Outgoing Interface List
 HundredGigE0/0/0/1

گام 5: صفحه داده مشتری (Customer Data Plane) در IPv6

همان مدل VRF و Default MDT، ترافیک مالتی‌کست (Multicast) مشتری IPv6 را نیز حمل می‌کند. در تنظیمات اعتبارسنجی، منبع مشتری IPv6 برابر با2001:db8:198:51::100است، گروه SSM مشتری IPv6 برابر باff3e::8000:2321می‌باشد و ترافیک در VRFredاز طریق همان گروه Default MDT IPv6 به آدرسff3e::8000:1.

بخش‌های میانی (Mid) و انتهایی (Tail) از وضعیت گیرنده MLD ایستا برای جریان SSM مشتری در IPv6 استفاده می‌کنند:

router mld
 vrf red
 interface HundredGigE0/0/0/2
 static-group ff3e::8000:2321 2001:db8:198:51::100
!
!
!

در Tail، رابط رو به گیرنده (receiver-facing interface) عبارت است ازHundredGigE0/0/0/1؛ دستور گروه ایستا (static group statement) در غیر این صورت یکسان است. این کار باعث ایجاد علاقه گیرنده VRF مشتری برای IPv6 می‌شودC(S,G)، درست همان‌طور که علاقه گیرنده IGMP یا PIM وضعیت VRF مشتری را برای IPv4 ایجاد می‌کندC(S,G).

! === Root - confirm IPv6 customer traffic is encapsulated onto the MDT ===
show pim vrf red ipv6 topology
show mrib vrf red ipv6 route
! Expected: forwarding entry for the IPv6 customer C(S,G) with:
! C-source: 2001:db8:198:51::100
! C-group: ff3e::8000:2321
! Incoming interface: HundredGigE0/0/0/2
! Outgoing interface: mdt6red
! === Mid - confirm IPv6 customer traffic is decapsulated from the MDT ===
show pim vrf red ipv6 topology
show mrib vrf red ipv6 route
! Expected: forwarding entry for the IPv6 customer C(S,G) with:
! Incoming interface: mdt6red
! Outgoing interface: HundredGigE0/0/0/2
! === Tail - confirm IPv6 customer traffic is decapsulated from the MDT ===
show pim vrf red ipv6 topology
show mrib vrf red ipv6 route
! Expected: forwarding entry for the IPv6 customer C(S,G) with:
! Incoming interface: mdt6red
! Outgoing interface: HundredGigE0/0/0/1

خروجی اعتبارسنجی آزمایشگاه نمونه از تست بسته (Packet) IPv6:

TrafficSource:
 1000 packets sent from 2001:db8:198:51::100 to ff3e::8000:2321 UDP/5001
MidReceiver:
 1000 packets received
 rx1000 from 2001:db8:198:51::100... srv6-mcast6 seq=1000
TailReceiver:
 1000 packets received
 rx1000 from 2001:db8:198:51::100... srv6-mcast6 seq=1000

وضعیت VRF مشتری در IPv6 به صورت نمونه در حین فعال بودن ترافیک:

Root:
 (2001:db8:198:51::100,ff3e::8000:2321) SPT
 RPF: HundredGigE0/0/0/2,2001:db8:198:51::1
 mdt6red fwd BGP
 Incoming Interface List
 HundredGigE0/0/0/2
 Outgoing Interface List
 mdt6red
Mid:
 (2001:db8:198:51::100,ff3e::8000:2321) SPT
 JP: Join(BGP) RPF: mdt6red,2001:db8:100::1
 Incoming Interface List
 mdt6red
 Outgoing Interface List
 HundredGigE0/0/0/2
Tail:
 (2001:db8:198:51::100,ff3e::8000:2321) SPT
 JP: Join(BGP) RPF: mdt6red,2001:db8:100::1
 Incoming Interface List
 mdt6red
 Outgoing Interface List
 HundredGigE0/0/0/1

ملاحظات استقرار (Deployment)

برای هر VRF با قابلیت چندپخشی (Multicast)، مدل استقرار اولیه از انتقال MDT بر بستر IPv6 استفاده می‌کند. اپراتورهایی که قصد انتقال از هسته چندپخشی IPv4 را دارند، باید به جای تغییر وضعیت به صورت ترکیبی (Mixed-mode)، یک بازه زمانی اختصاصی برای مهاجرت در نظر بگیرند.

ملاحظات کلیدی در طراحی:

• هر VRF با قابلیت مالتی‌کست (Multicast) باید حول یک آدرس خانواده انتقال MDT/core واحد برای یک فاز استقرار مشخص برنامه‌ریزی شود.
• مهاجرت از MDTهای مبتنی بر IPv4 GRE به MDTهای IPv6 IP-in-IP نیازمند یک تغییر وضعیت (Cutover) برنامه‌ریزی شده برای هر VRF است.
• این مقاله استقرار در یک AS واحد را پوشش می‌دهد؛ MVPN بین ASها و مالتی‌کست اکسترانت خارج از محدوده فعلی این مقاله هستند.
• برای اطلاع از پیکربندی‌های سخت‌افزاری پشتیبانی شده و محدودیت‌های مقیاس‌پذیری (Scale limits)، به یادداشت‌های انتشار (Release notes) مخصوص هر پلتفرم مراجعه کنید.

ارتقاهای آتی (Future Enhancements)

قابلیت‌های زیر بر پایه معماری توصیف‌شده در بالا بنا شده‌اند و توسط استانداردهای زیرساختی پشتیبانی می‌شوند، اما بخشی از مدل پیاده‌سازی اولیه نبوده و برای فازهای بعدی برنامه‌ریزی شده‌اند. برای اطلاع از در دسترس بودن فعلی، به یادداشت‌های انتشار (Release Notes) مختص هر پلتفرم مراجعه کنید.

یکپارچه‌سازی Flex-Algo

تکنولوژی Flex-Algo می‌تواند این معماری را برای تأثیرگذاری بر ساختار درخت مالتی‌کست (Multicast tree) در هسته شبکه ارائه‌دهنده (Provider core) گسترش دهد:

• ساختار درخت PIM می‌تواند از مسیرهای مبتنی بر محدودیت Flex-Algo برای تأخیر (Latency)، وابستگی (Affinity) یا پهنای باند (Bandwidth) پیروی کند.
• با دریافت یک اشتراک چندپخشی (Multicast) برای(S,G)، یک درخت گام‌به‌گام (Hop-by-hop) به سمت منبع و با پیروی از مسیر تعریف‌شده توسط Flex-Algo ساخته می‌شود.
• این قابلیت امکان مهندسی ترافیک چندپخشی (Multicast) را بدون نیاز به RSVP-TE فراهم می‌کند.

جدول چندپخشی (Multicast) سراسری

معماری توصیف‌شده در بالا بر مالتی‌کست (Multicast) در VRF تمرکز دارد، جایی که ترافیک مشتری در تونل‌های IP-in-IPv6 در سراسر هسته شبکه ارائه‌دهنده (Provider Core) کپسوله‌سازی (Encapsulation) می‌شود. با این حال، تمام ترافیک‌های مالتی‌کست (Multicast) نیازی به جداسازی VPN ندارند.

برای مالتی‌کست (Multicast) در جدول مسیریابی جهانی (Global Routing Table)، یک هسته (Core) سرتاسری IPv6 کارها را بیش از پیش ساده می‌کند: جریان‌های مالتی‌کست IPv6 به صورت بومی (Natively) و از طریق PIMv6 بدون نیاز به هیچ‌گونه کپسوله‌سازی (Encapsulation)، تونل‌ها (Tunnels) یا لایه پوششی MDT منتقل می‌شوند. این ساده‌ترین مدل پیاده‌سازی (Deployment Model) است: ارسال استاندارد PIMv6-SSM بدون نیاز به هیچ مکانیزم اضافی.

استاندارد RFC 7716 رویه‌های BGP MVPN را به جدول سراسری (Global Table) گسترش می‌دهد و گزینه‌ای را برای استفاده از کشف خودکار (Auto-Discovery) و سیگنال‌دهی مبتنی بر BGP برای مالتی‌کست (Multicast) در جدول سراسری فراهم می‌کند؛ این قابلیت زمانی مفید است که اپراتورها بخواهند یک مدل عملیاتی BGP MVPN یکپارچه را در هر دو بخش VRF و مالتی‌کست جدول سراسری (Global Table) داشته باشند.

جنبه	مالتی‌کست (Multicast) در VRF	مالتی‌کست (Multicast) جدول سراسری
بافت فورواردینگ (Forwarding context)	به ازای هر VRF	جدول مسیریابی سراسری
کپسوله‌سازی (Encapsulation)	IP-in-IPv6	بدون کپسوله‌سازی، PIMv6 بومی (Native)
سیگنال‌دهی BGP	الزامی، MVPN نوع 1 و 7	اختیاری، RFC 7716
مورد استفاده (Use case)	مالتی‌کست (Multicast) مشتری در L3VPN	مالتی‌کست (Multicast) در سطح شبکه بدون جداسازی VPN

در حالت پایه GTM، ارسال چندپخشی (Multicast Forwarding) به صورت IPv6 multicast بومی در جدول مسیریابی سراسری (Global Routing Table) انجام می‌شود: در این حالت از VRF، متمایزکننده مسیر (Route Distinguisher)، پوشش MDT و کپسوله‌سازی IP-in-IP استفاده نمی‌شود. استاندارد RFC 7716 یک مدل اختیاری مبتنی بر BGP MVPN را برای چندپخشی جدول سراسری تعریف می‌کند. نمونه پیکربندی و اعتبارسنجی در این مقاله بر مدل چندپخشی VRF با استفاده از BGP MVPN و IPv6 MDTها تمرکز دارد.

نتیجه‌گیری

معماری سیسکو برای سرویس‌های چندپخشی (Multicast) بر روی هسته‌های SRv6 / IPv6 از یک طراحی دو-لایه استفاده می‌کند: لایه پوششی (Overlay) BGP MVPN برای کشف PE و سیگنال‌دهی مشتری، و لایه زیرین (Underlay) PIMv6-SSM برای انتقال بومی (Native) چندپخشی IPv6، که از کپسوله‌سازی ساده IP-in-IP بهره می‌برد. هیچ‌گونه افزونه چندپخشی اختصاصی برای SRv6 مورد نیاز نیست.

نکات کلیدی:

• بلوک‌های سازنده مبتنی بر استاندارد– ساخته شده بر پایه RFC 6513/6514 MVPN، پشتیبانی از سیگنال‌دهی زیرساخت (Underlay) IPv6 در RFC 6515/8950 و عملکرد PIM-SM/SSM در RFC 7761. هیچ پروتکل اختصاصی در مسیر ارسال (Forwarding path) وجود ندارد.
• حداقل فضای مورد نیاز برای استقرار– تنها لبه‌های شبکه (Edge PEs) به قابلیت Multicast VPN نیاز دارند. روترهای میانی (Transit P routers) به پشتیبانی بومی از IPv6 multicast/PIMv6 نیاز دارند، اما نیازی به آگاهی از VPN ندارند.
• حمل و نقل یکپارچه (Unified transport)– همان زیرساخت PIMv6-SSM Default MDT، ترافیک Multicast لایه 3 (L3VPN) را برای ترافیک مشتریان IPv4 و IPv6 حمل می‌کند.
• مقیاس‌پذیر (Scalable)– قابلیت Default MDT اتصال پایه به ازای هر VRF را فراهم می‌کند؛ Data MDT درخت‌های انتخابی با بهره‌وری بالا در پهنای باند (Bandwidth) را برای جریان‌های با نرخ بالا ارائه می‌دهد.
• فضای کافی برای رشد– مهندسی ترافیک Flex-Algo و Global Table Multicast، بهبودهای مبتنی بر استانداردی هستند که برای فازهای بعدی برنامه‌ریزی شده‌اند.

با افزایش پشتیبانی چند-فروشنده‌ای (Multi-vendor) از IETF، این همان مسیری است که Cisco برای خدمات چندپخشی (Multicast) بر روی هسته‌های SRv6 / IPv6 دنبال می‌کند.

مراجع

موضوع	لینک
RFC 6513 – مالتی‌کست (Multicast) در شبکه‌های MPLS/BGP IP VPN	rfc-editor.org/rfc/rfc6513
RFC 6514 – انکودینگ‌ها و رویه‌های BGP برای مالتی‌کست (Multicast) در شبکه‌های MPLS/BGP IP VPN	rfc-editor.org/rfc/rfc6514
RFC 6515 – آدرس‌های زیرساخت IPv4 و IPv6 در به‌روزرسانی‌های BGP برای مالتی‌کست VPN	rfc-editor.org/rfc/rfc6515
RFC 7716 – مالتی‌کست جدول جهانی (Global Table) با رویه‌های BGP Multicast VPN	rfc-editor.org/rfc/rfc7716
RFC 8950 – تبلیغ IPv4 NLRI با یک Next Hop از نوع IPv6	rfc-editor.org/rfc/rfc8950
RFC 7761 – پروتکل مستقل مالتی‌کست (PIM) – حالت Sparse	rfc-editor.org/info/rfc7761
RFC 8402 – معماری مسیریابی بخش‌بندی شده (Segment Routing)	rfc-editor.org/info/rfc8402
RFC 8986 – برنامه‌نویسی شبکه Segment Routing بر بستر IPv6	rfc-editor.org/info/rfc8986
RFC 9350 – الگوریتم انعطاف‌پذیر IGP	rfc-editor.org/info/rfc9350
RFC 9502 – الگوریتم انعطاف‌پذیر IGP در شبکه‌های IP	rfc-editor.org/info/rfc9502
مالتی‌کست بر بستر SRv6 – پیش‌نویس گروه کاری IETF PIM	datatracker.ietf.org/doc/draft-ietf-pim-multicast-over-srv6
درخت‌های توزیع مالتی‌کست (Multicast Distribution Trees) در xrdocs	xrdocs.io/multicast/blogs/multicast-distribution-trees-mdts