ارزیابی مهندسی ترافیک در شبکه های MPLS و حفاظت از لینک – قسمت پنجم (پایانی)

در قسمت­های قبلی از این سری مقالات Backup Tunnelهای NHOP و NNHOP مقایسه، در مورد Promotion یا ارتقا صحبت و همچنین الگوریتم‌های حق تقدم حفاظت Backup شرح داده شد. در این قسمت نحوه‌ی استفاده از Backup Tunnelهای Signal شده، مقایسه‌ی پهنای باند Signal شده و پهنای باند Backup و همچنین پیش ‌نیاز‌ها و محدودیت‌های مربوط به Fast Reroute ،MPLS Traffic Engineering مورد بررسی قرار خواهند گرفت.

Poolهای پهنای باند حفاظت ‌شده و Poolهای پهنای باند تأمین‌کننده‌ی پهنای باند Backup Tunnel

دستور Tunnel MPLS Traffic-Eng Bandwidth به کاربر این امکان را می‌دهد که موارد زیر را تنظیم کند:

• میزان پهنای باندی که یک Backup Tunnel ذخیره می‌کند.
• Pool پهنای باند DS-TE که پهنای باند باید از آن ذخیره ‌شود.

این دستور به کاربر امکان می‌دهد کهPool  پهنای باندی مشخص کند که ترافیک باید به آن تعلق داشته باشد تا بتواند از این پهنای باند استفاده کند و چندین Pool می‌تواند برای این منظور مجاز باشد. البته هیچ ارتباط مستقیمی بین Pool پهنای باند محافظت شده و Pool پهنای باندی که پهنای باند Backup Tunnel، پهنای باند خود را از آن می‌گیرد، وجود ندارد.

 استفاده از Backup Tunnelهای Signal شده با پهنای باند صفر

غالباً استفاده از Backup Tunnelها با پهنای باند Signal شده صفر، حتی در صورت نیاز به حفاظت از پهنای باند، مطلوب‌تر است. ممکن است به نظر برسد که اگر هیچ پهنای باندی در ظاهر ذخیره نشده باشد، هیچ تضمینی هم برای پهنای باند وجود ندارد، اما لزوماً اینطور نیست. در موقعیت‌هایی که محافظت از لینک و یا حفاظت از پهنای باند فقط برای ترافیک Sub-pool مد نظر باشد، برای هر پیوند محافظت شده AB با حداکثر مقدار Subpool قابل ذخیره‌ی n، ممکن است مسیری از Node A به Node B وجود داشته باشد به گونه‌ای که اختلاف بین حداکثر Global قابل‌ ذخیره و حداکثر Subpool قابل ‌ذخیره، حداقل به ‌اندازه‌ی n باشد. اگر یافتن چنین مسیرهایی در شبکه برای هر لینک امکان‌پذیر بود، می‌توان بدون ذخیره‌ی پهنای باند، تمام Backup Tunnelها را در امتداد چنین مسیرهایی ایجاد کرد. در صورت خرابی تنها یک لینک، فقط یک Backup Tunnel از هر لینکی در مسیر خود استفاده می‌کند. از آنجا که این مسیر حداقل n پهنای باند در Global Pool دردسترس دارد، با فرض اینکه علامت‌گذاری و زمان‌بندی جهت دسته‌بندی ترافیک Subpool در یک Queue اولویت‌بندی انجام شده ‌باشند، پهنای باند Subpool تضمین می‌شود.

این روش به Backup Tunnelهایی که از خرابی‌های لینک مستقل محافظت می‌کنند، این توانایی را می‌دهد که پهنای باند Global Pool را بین خود به اشتراک بگذارند. انتظار می‌رود که Backup Tunnelها فقط برای مدت کوتاهی پس از خرابی مورد استفاده قرار گیرند، یعنی تا زمانی که Headendهای LSPهای آسیب‌دیده، آن‌ها را به مسیرهای دیگر با پهنای باند Subpool موجود تغییر مسیر دهند. احتمال خرابی چندین لینک غیرمرتبط در صورت عدم وجود Node یا خرابی‌های Shared Risk Link Group یا SRLG که منجر به خرابی چندین لینک می‌شود، بسیار ناچیز است. بنابراین منطقی است که تصور کنیم به احتمال زیاد خرابی‌های لینک عملاً مستقل هستند. این فرض مستقل بودن خرابی همراه با Backup Tunnelهای Signal شده بدون ذخیره‌ی پهنای باند مشخص، امکان اشتراک پهنای باند کارآمد را فراهم می‌کند که موجب صرفه‌جویی قابل ‌توجهی در پهنای باند می‌شود.

Backup Tunnelهایی که از ترافیک Subpool محافظت می‌کنند، از هر Pool پهنای باند می‌گیرند. ترافیک اولیه که از Global Pool استفاده می‌کند، می‌تواند از کل Global Pool بهره ببرد و ترافیک اولیه که از Subpool استفاده می‌کند می‌تواند از کل Subpool بهره ببرد. در عین‌حال، در صورت خرابی یک لینک، پهنای باند ترافیک Subpool کاملاً تضمین شده است.

از همین روش می‌توان برای محافظت از Node و SRLG استفاده کرد. بااین‌حال، تصمیم‌گیری در مورد اینکه Backup Tunnelها باید در کجا قرار داده شوند، امر پیچیده‌تری است زیرا هم خرابی Node و هم خرابی SRLG منجر به خرابی همزمان چندین لینک می‌شود. بنابراین، نمی‌توان Backup Tunnelهایی را که از ترافیکی محافظت می‌کنند که از همه لینک‌های آسیب دیده عبور می‌کند، مستقل از یکدیگر محاسبه نمود، اما Backup Tunnelهایی که از گروه‌ لینک‌های مربوط به خرابی‌های مختلف محافظت می‌کنند را هنوز هم می‌توان به‌طور مستقل از یکدیگر محاسبه کرد که این امر منجر به صرفه‌جویی در پهنای باند مشابه می‌شود.

مقایسه‌ی پهنای باند Signal شده و پهنای باند Backup

از پهنای باند Backup، به‌صورت Local یعنی توسط روتری که Headend متعلق به Backup Tunnel است استفاده می‌شود تا تعیین‌ گردد که کدام و چه تعداد LSP اولیه را می‌توان در یک Backup Tunnel خاص، تغییر مسیر داد. روتر تضمین می‌کند که مجموع پهنای باند مورد نیاز این LSPها از پهنای باند Backup فراتر نرود.

بنابراین، حتی هنگامیکه Backup Tunnel با پهنای باند صفر Signal شده، پهنای باند Backup باید با مقداری متناسب با نیاز واقعی پهنای باند ترافیکی که توسط این Backup Tunnel محافظت می‌شود، تنظیم شود. برخلاف مواردی که نیازهای پهنای باند Backup Tunnel به‌طور واضح Signale می‌شوند، مقدار پهنای باند سیگنال شده که صفر است، با پهنای باند Backup برابر نیست.

پیش‌نیاز‌های لازم برای مهندسی ترافیک در شبکه های Fast Reroute ،MPLS و Node Protection

شبکه باید از ویژگی‌های Cisco IOS زیر پشتیبانی کند:

• IP Cisco Express Forwarding
• Multiprotocol Label Switching یا MPLS

شبکه باید حداقل از یکی از پروتکل‌های زیر پشتیبانی کند:

• Intermediate System-to-Intermediate System یا IS-IS
• Open Shortest Path First یا OSPF

قبل از تنظیم Link FRR وNode Protection، فرض بر این است که کاربر کارهای زیر را انجام داده اما نیازی نیست که قبلاً Tunnelهای MPLS TE را تنظیم کرده باشد، پس مراحل زیر باید طی شوند:

• MPLS TE در تمام روترها و رابط کاربری‌های مربوطه باید فعال شوند.
• Tunnelهای MPLS TE تنظیم شوند.

محدودیت‌های مهندسی ترافیک در شبکه های Fast Reroute ،MPLS و Node Protection

• رابط‌های کاربری باید از MPLS Global Label Allocation استفاده کنند.
• روترهای Backup Tunnel Headend و Tailend باید FRR را در Draft-Pan-Rsvp-Fastreroute-00.Txt پیاده‌سازی کنند.
• اگر Backup Tunnel در زمانی که LSP به‌طور فعال در حال استفاده از آن است خراب ‌شود، Backup Tunnelها محافظت نمی‌شوند و LSP خراب می‌شود.
• LSPهایی که به‌طور فعال از Backup Tunnel استفاده می‌کنند برای ارتقا در نظر گرفته نمی‌شوند. اگر LSP به‌طور فعال از یک Backup Tunnel استفاده ‌کند و در عین حال Backup Tunnel بهتری در دسترس باشد، LSP فعال به Backup Tunnel بهتر سوییچ نمی‌کند.
• کاربر نمی‌تواند FRR Helloها را در روتری فعال کند که در عین حال Resource Reservation Protocol (RSVP) Graceful Restart را فعال کرده است.
• فقط در نسخه 12.2، کاربر نمی‌تواند One-Hop Autotunnelها، Backup Autotunnelها یا Autotunnel Mesh Groupها را در یک روتر که با Stateful Switchover یا SSO تنظیم شده‌اند، فعال کند. این محدودیت مانع از بازیابی موفقیت‌آمیز MPLS TE Tunnel که به ‌طور خودکار توسط Autotunnel TE تنظیم شده است از هر روترMidpointی که در طول مسیر LSPهای متعلق به روتر SSO Switchover انجام می‌دهند، نمی‌شود.
• اگر LSPها، FRR Active باشند و روتر Point of Local Repair یا PLR، با SSO مواجه شود، MPLS TE LSPهایی که Fast Reroutable هستند، Recover یا بازیابی نمی‌شوند.

مقاله های مرتبط: