آموزش شبکه : MPLS و Segment Routing چیست؟

از زمانی که احساس شد مسیریابی صرفا بر اساس مقصد همیشه خوب و دلخواه نیست، ایده ی تعیین شرایط مسیریابی در مبدا متولد گشت و برای تحقق این ایده، مدام راهکارهای مختلفی مطرح شد: از PBR تا رفتن به سمت MPLS و سپس پیشرفت آن به MPLS-TE و نهایتا معرفی روشی با نام Segment Routing.

به این ترتیب تعیین شرایط مسیریابی در مبدا یا به عبارت بهتر، انجام Source Routing که روزی تنها در حد یک ایده بود، روز به روز به یک واقعیت و منطق جدید در مسیریابی نزدیکتر شد. آنچه سبب شده تا ایده ی Source Routing بیشتر به واقعیت نزدیک شود، راهکار Segment Routing می باشد. برای درک بهتر عملکرد Segment Routing ابتدا بهتر است مروری بر عملکرد MPLS و MPLS-TE داشته باشیم.

MPLS و ارسال پکت ها

تکنولوژی MPLS، تکنولوژی با قدمتی تقریبا 20 ساله و آشنا برای مهندسین اینترنت می باشد. مبنا و اساس کار MPLS بر پایه ی دو مفهوم Control Plane و Forwarding Plane بوده و به صورت خلاصه نحوه ی عملکرد آن به این صورت است که:

به مجموعه ای از روترها که توانایی پردازش و تشخیص Label ها را داشته باشند اصطلاحا Label Switch Router یا به اختصار LSR گفته می شود. در دامنه ی MPLS که شامل مجموعه ای از LSR هاست، به هر کدام از LSR ها نقشی داده می شود. اولین LSR ای که در لبه ی دامنه ی MPLS قرار دارد و پکتی را از خارج این ساختار به داخل دامنه ی MPLS فوروارد می کند اصطلاحا Ingress LSR نامیده می شود و به روتری که در لبه ی انتهایی دامنه ی MPLS قرار دارد و پکتی را از داخل دامنه ی MPLS به خارج این ساختار ارسال می کند، اصطلاحا Egress LSR گفته می شود.

به مسیری که یک پکت از یک Ingress LSR تا یک Egress LSR طی می کنداصطلاحا LSP یا Label Switched Path گفته می شود که این مسیر یا بر اساس کوتاهترین مسیر محاسبه شده توسط IGP ها مشخص می گردد و یا بر اساس پارامترهای Traffic Engineering یا به اختصار TE.

وظیفه ی Ingress LSR آن است که پکت های دریافت کرده از خارج دامنه ی MPLS را ابتدا به یک Forwarding Equivalence Class یا به اختصار FEC که پکت به آن تعلق دارد، اختصاص دهد.

پکت هایی که در قبال آن ها عمل یکسانی صورت می گیرد مثلا:

• همه ی آن ها از طریق یک اینترفیس خروجی یکسان باید ارسال شوند
• یا همه ی آن ها next-hop های یکسانی دارند
• یا همه ی آن ها تحت queuing policy های یکسانی هستند

در یک FEC یکسان قرار می گیرند و سپس برای آن FEC یک next-hop تعیین می شود.

سپس بعد از اضافه کردن MPLS Label Stack به هدر پکت، آن را به سمت next-hop مشخص شده برای FEC ای که پکت در آن قرار گرفته، ارسال می کند.

هر MPLS Label Stack می تواند شامل چند ورودی یا اصطلاحا entry باشد و هر کدام از این ورودی ها هم به نوبه ی خود از یکسری فیلد تشکیل شده اند که این فیلد ها عبارتند از: یک فیلد 20 بیتی برای Label، یک فیلد سه بیتی برای Traffic Class (یا همان Experimental)، یک فیلد یک بیتی (یا اصطلاحا یک flag S) و نهایتا یک فیلد 8 بیتی برای TTL (مشابه تصویر زیر) با توجه به مقادیر این فیلدها زمانی که یک LSR پکتی با هدر MPLS دریافت می کند، تشخیص می دهد که باید در قبال آن چه عکس العملی را انجام دهد.

زمانی که یک LSR پکت MPLS ای را دریافت می کند، بالاترین ورودی در MPLS Label Stack را بررسی کرده و یک واحد از TTL آن کم می کند و اگر مقدار TTL به 0 نرسید ( به این معنی که TTL منقضی نشده بود)، در FIB (دوستان آشنا با سیسکو در اینجا از مفهوم LFIB استفاده می کنند) به دنبال اطلاعات (یا همان ورودی) منطبق با مقدار فیلد Label آن ورودی میگردد.

به ازای هر Label در FIB این اطلاعات نگهداری می شود:

• عملی که در قبال آن Label باید انجام شود.
• اینترفیس next-hop (آدرس next-hop و اینترفیس خروجی)

در قبال هر Label نیز سه عمل می تواند صورت گیرد:

1.  عمل Push: یا Label زدن
2. عمل POP: یا حذف بالاترین ورودی MPLS Label Stack
3. عمل Swap: یا تغییر بالاترین Label

حال اگر Label در FIB پیدا شود، LSR ابتدا عملی را که برای آن Label در FIB مشخص شده در قبال آن انجام می دهد و سپس پکت را به اینترفیس next-hop ارسال می کند.

اینترفیس next-hop، هم می تواند یک اینترفیس داخلی باشد که در این صورت LSR پکت را به همان اینترفیس داخلی خود ارسال کرده و آن را پردازش می کند و هم می تواند یک LSR دیگر باشد که در این صورت پکت به سمت آن LSR ارسال می شود. اگر پکتی به دست LSR یکی مانده به آخرین LSR در یک LSP برسد، این LSR آخرین ورودی در Label stack را از پکت حذف کرده و پکتی بدون هیچ Label ای را برای Egress LSR ارسال می کند (PHB).

MPLS Control Plane

در MPLS مفهوم Control Plane به صورت مستقیم به این دو عامل وابسته است:

1-  IGPs Control Plane:

LSR ها برای محاسبه ی کوتاهترین مسیر و یا به دست آوردن اطلاعات مسیری که در Traffic Engineering باید مورد استفاده قرار گیرد، از IGP هایی مثل OSPF یا IS-IS بهره می گیرند.

2-  Label Distribution Protocol یا LDP:

LDP پروتکلی بر مبنای TCP است که LSR ها با استفاده از آن می توانند Prefix ها به همراه Label های اختصاص یافته به آن ها را به یکدیگر تبلیغ کرده و بر مبنای این اطلاعات، FIB خود را بسازند. مشکل LDP عدم پشتیبانی آن از پارامترهای TE است.

با استفاده از دو مورد بالا، LSR ها از طریق یک پروتکل IGP از سایر همسایه های خود تمام Prifix ها و با استفاده از LDP، لِیبِل های اختصاص یافته به هر Prefix را فرا می گیرند و بر اساس این اطلاعات، هر LSR برای خود LSP ای را محاسبه می کند.

مطالب شرح داده شده در بالا، توضیح مختصری از نحوه ی عملکرد MPLS بود اما قبل از پرداختن به مبحث MPLS-TE بهتر است کمی به عقب بازگردیم و به بررسی ایده ی پیدایش این راهکارها بپردازیم.

مروری بر تاریخچه ی مسیریابی IP

مسیریابی IP به روش سنتی کاملا destination based می باشد. به این معنا که هر روتری که در راه رسیدن یک پکت از یک مبدا به یک مقصد قرار داشته باشد باید از مقصد پکت مطلع باشد تا بتواند آن را به مقصد مورد نظر هدایت کند. از سوی دیگر در این روش همیشه سعی در آن است که از کوتاهترین مسیر به مقصد، به عنوان مسیر اصلی برای ارسال ترافیک استفاده شود و بر همین اساس، تمام پروتکل های مسیریابی همیشه سعی در پیدا کردن کوتاهترین مسیر ممکن به یک مقصد را دارند.

اما گاهی اوقات این مساله چندان هم خوب نیست. به عنوان مثال تصور کنید برای رسیدن به مقصدی دو مسیر وجود داشته باشد. IGP ها بر اساس cost لینک ها، کوتاهترین مسیر را انتخاب کرده و همیشه از همان مسیر برای ارسال ترافیک استفاده می کنند و تا زمانی که مسیر اصلی fail نشود به سراغ مسیر جایگزین بعدی نخواهند رفت (در نظر داشته باشید که تمام IGP ها از مکانیزم های unequal load sharing پشتیبانی نمی کنند) بنابراین یک لینک همیشه در حال استفاده و لینک دیگر ممکن است خیلی کم و در شرایط خاص مورد استفاده قرار گیرد.

گاهی نیز شاید نیاز باشد تا بنا به ملاحظاتی همانند میزان bandwidth مصرفی، از مسیری که به عنوان مسیر اصلی توسط IGP ها انتخاب نشده برای ارسال ترافیک استفاد شود، ولی در روش مسیریابی سنتی IP این امکان وجود ندارد.

به همین دلیل به نوعی برای تغییر این رفتار مسیریابی سنتی، از روشی با نام Policy Based Routing یا به اختصار PBR استفاده می شد. هر چند که با PBR این امکان فراهم می شد که روترها به جای پیروی از آن چه پروتکل های مسیریابی محاسبه کرده بودند، مجبور به پیروی از سیاستی که ادمین تعیین کرده بود، شوند اما عیبی که این راهکار داشت آن بود که باید بر روی هر روتری که در مسیر رسیدن به مقصد قرار داشت، سیاست ها به صورت جداگانه پیکربندی می شد. حال اگر ساختار شبکه خیلی بزرگ می گردید، انجام این عمل از دیدگاه پبکربندی هم خیلی سخت می شد و هم احتمال خطاهای انسانی در پیکربندی بیشتر می شد و هم چنین مدیریت سخت تر می گردید و به عبارت بهتر باعث پیچیده شدن طراحی شبکه، مدیریت و همینطور خطایابی می شد.

با معرفی MPLS یکی از مشکلات مسیریابی سنتی IP حل شد. به این صورت کهدیگر همه ی روترهای درون ساختار MPLS نیازی به دانستن مقصد اصلی پکتی که وارد این ساختار می شد، نداشتند (تغییر منطق destination based بودن مسیریابی سنتی IP) و فقط کافی بود مسیر رسیدن Ingress LSR به Egress LSR را بدانند و بر حسب آنچه در بالا توضیح داده شد، مسیریابی را با استفاده از Label ها انجام می دادند و برای انجام بخشی از این عمل از LDP کمک می گرفتند.

اما LDP به تنهایی جوابگوی حل مشکل دوم مسیریابی سنتی IP نبود. به این معنا که در یک ساختار ساده ی MPLS هنوز هم مسیر از Ingress LSR به Egress LSR بر اساس کوتاهترین مسیر محاسبه شده توسط IGP ها به دست می آمد و باز هم این امکان برای تعیین گذر ترافیک از مسیر دلخواه و نه مسیر انتخابی IGP ها، وجود نداشت. به عنوان مثال اگر داخل ابر MPLS از Ingress LSR به Egress LSR تصمیم بر آن بود که LSP برای ارسال ترافیک، بر اساس میزان bandwidth لینک ها ساخته شود، LDP جوابگوی این نیاز نبود.

بنابراین مفهومی تعریف شد بنام MPLS TE ، این روش این امکان را فراهم می آورد که بتوان به جای destination routing از source based routing استفاده کرد به این معنی که در مبدا ارسال پکت، مسیر رسیدن به مقصد تعیین گردد و همینطور مشخص شود که ترافیک فقط از طریق همان مسیر به سمت مقصد ارسال شود. به این ترتیب این امکان فراهم می گردید که دیگر همیشه تنها از یک لینک برای ارسال ترافیک استفاده نشود و ترافیک را بتوان بر اساس پارامترهایی چون میزان bandwidth لینک ها در طول رسیدن به یک مقصد، ارسال نمود.

برای حل مشکل ضعف LDP در مبحث TE، افزونه‌ای بر RSVP ایجاد شد که مجموعاً با نام Resource Reservation Protocol with Traffic Engineering Extensions یا به اختصار RSVP-TE معرفی شد. RSVP یک signaling protocol می باشد که همانند LDP، مستقیما بر روی IP اجرا می شود.

تفاوت LDP و RSVP-TE

مکانیزم عملکرد LDP به این صورت است که با فعال شدن LDP بر روی یک اینترفیس، LSR بر روی آن اینترفیس شروع به ارسال پیام Hello برای یافتن همسایه های LDP خود می نماید (UDP). اگر همسایه‌ی LDP ای پیدا شود، یعنی روتر دیگری متصل به این LSR که بر روی اینترفیس آن نیز LDP فعال شده باشد، یک ارتباط TCP بین دو همسایه ی LDP تشکیل شده و همسایه‌های LDP تمام مسیرهایی که در جدول Route خود دارند به همراه Label هایی که به هر کدام از این مسیرها اختصاص داده اند، به یکدیگر تبلیغ می نمایند.

بعد از این که تمام همسایه های LDP داخل ابر MPLS یکدیگر را شناسایی کردند و تمام نگاشت های Prefix/Label خود را به یکدیگر تبلیغ نمودند، هر کدام از LSR ها شروع به محاسبه ی مسیر تا Egress LSR می کند. پس در این حالت هر LSR فقط همسایه های LDP ای که مستقیم به آن متصل باشند را شناخته و برای آن که بتواند یک LSP را بسازد، دقیقا از همان مسیری که IGP به عنوان کوتاهترین مسیر محاسبه کرده، استفاده می کند. به نوعی در این حالت، LSP hop-by-hop و به صورت خودکار ساخته می شود، هم چنین اختصاص Label ها توسط هر LSR کاملا مستقل از سایر LSR ها صورت می گیرد.

اما با استفاده از RSVP-TE، مستقیما بین Ingress LSR و Egress LSR یک ارتباط برقرار شده و بر حسب شرایط و منابعی که در Ingress LSR مشخص شده اند، LSP محاسبه می گردد و انتخاب مسیر دیگر بستگی به آن چه IGP محاسبه کرده، نخواهد داشت. بنابراین در این شرایط یک ارتباط end-to-end خواهیم داشت و اختصاص Label ها کاملا به صورت هماهنگ بین تمام LSR ها صورت می گیرد و تعیین شرایط مسیری که باید از آن استفاده شود یا به عبارت بهتر تعیین آن که چگونه LSP ساخته شود، به صورت دستی و در روتر Ingress مشخص خواهد شد.

بررسی عملکرد MPLS-TE

 در ساختار MPLS-TE، می توان به اینترفیس ها TE Attribute ها را اختصاص داد. TE Attribute ها عبارتند از:

• bandwidth موجود
• bandwidth رزرو شده
• Link Color

این TE Attribute ها توسط IGP ها در کل دامنه flood می شوند و تمام node ها در دامنه، علاوه بر داشتن یک LSDB یکسان، باید یک TE Database یا به اختصار TED یکسان نیز داشته باشند. به عبارتی LSDB توصیفی از کل توپولوژی ساختار و TED توصیفی از ویژگی های لینک ها در ساختار و به نوعی تکمیل کننده ی LSDB است.

پروتکلی مانند OSPF برای حمل TE Attribute ها از Opaque LSA ها یا به عبارتی LSA های Type 9 تا 11 بهره میگیرد. به یک Opaque LSA، یک TE LSA نیز گفته می شود. برای flood این LSA ها از مکانیزم استاندارد flooding سایر LSA ها استفاده می شود.

مکانیزم عملکرد RSVP-TE

با استفاده از RSVP-TE روتر Ingress به تمام LSR ها در طول مسیر رسیدن تا Egress LSR اعلام می کند که قصد ایجاد یک LSP را دارد.

قبل از تشکیل یک LSP، پروتکل RSVP وظیفه ی بررسی منابع و شرایط یک مسیر برای انتخاب آن به عنوان LSP را بر عهده دارد. همینطور این امکان را فراهم می آورد که بتوان برای یک LSP منابع مورد نیاز را ذخیره نمود.

پروتکل RSVP برای انجام عمل سیگنالینگ خود از دو پیام استفاده می کند: PATH Message و Resv Message.

به عنوان مثال در تصویر بالا، روتر R1 (که یک Ingress LSR است) قصد ساخت یک LSP تا روتر R4 (که در اینجا Egress LSR محسوب می شود) را دارد. بنابراین یک PATH Message مبنی بر ایجاد یک LSP ارسال می کند. این پیام به ترتیب از روترهای R2 و R3 عبور کرده تا به R4 برسد (hop-by-hop). هر کدام از این روترها زمانی که پیام PATH Message را دریافت می کنند، منابع موردنیاز ذکر شده در این پیام را بررسی کرده و اگر این منابع را داشته باشند، آن ها را به اندازه ای که در پیام درخواست شده، کنار می گذارند (یا به عبارتی ذخیره می کنند) و این پیام را برای روتر بعدی ارسال می کنند.

اما اگر روترهای میانی در مسیر منتهی به مقصد، منابع مورد نیاز را نداشته باشند، پیامی برای R1 مبنی بر عدم داشتن شرایط مورد نیاز ارسال می کنند (PATH Error)که در چنین شرایطی R1 یا باید مسیر دیگری را برای ساخت LSP پیدا کند و یا اگر مسیر دیگری وجود نداشته باشد، تشکیل LSP با شکست مواجه شده و باید در میزان منابع مورد نیاز تجدید نظر شود.

اما با فرض خوب بودن همه‌ی شرایط در مسیر رسیدن تا R4 و رسیدن پیام PATH به دست این روتر، R4 در پاسخ به PATH Message ای که دریافت کرده یک Resv Message برای R1 ارسال می کند. این Resv Message نیز دوباره از تمام روترهایی که در مسیر رسیدن به R1 قرار دارند، عبور کرده و اگر در طول مدت زمانی که یک روتر مثلا R2، بعد از این که PATH Message را دریافت کرد و به سمت R3 ارسال نمود، تا زمانی که Resv Message به دست آن برسد، بنا به هر دلیلی منابع درخواست شده را از دست داده باشد، به سمت R4 یک Resv Error ارسال می کند. در غیر این صورت اگر هیچ مشکلی وجود نداشته باشد، پیام Resv به دست R1 رسیده و LSP ساخته می شود.

Resv Message در واقع عمل توزیع Label ها را انجام می دهد. به این  روش ساخت LSP، یعنی ساخت LSP از سمت Ingress LSR به سمت Egress LSR اصطلاحاdownstream گفته می شود که عکس این روش هم امکان پذیر است، یعنیساختن LSP از سمت Egress LSR به سمت Ingress LSR که به آن upstreamگویند.

منابع کمی توسط PATH Message می توانند ذخیره شوند که ساده ترین آن ها bandwidth است. از هر اینترفیسی در طول مسیر می توان درخواست نمود که مقدار یا درصدی از bandwidth موجود خود را منحصرا برای LSP ای که قرار بر ساخت آن است، کنار گذارد.

پیام های PATH و Resv، منابع مورد درخواست، Label ها و … را توسط فیلد object موجود در قالب پیام  خود حمل می کنند.

یکی از object های ضروری RSVP-TE که RSVP را قادر می سازد که بتواند LSP ای را بر روی مسیری مستقل از آنچه IGP ها به عنوان مسیر بهتر تعیین می کنند، تشکیل دهد، Explicit Route Object یا به اختصار ERO هست. ERO در واقع لیستی از LSR هاست (که توسط آدرس IP هایشان مشخص می شوند) که مسیر (یا همان LSP) حتما باید از آنها عبور نماید.

توسط ERO دو نوع hop مشخص می شود: strict و loose.

• Strict hop ها آن دسته از hop هایی هستند که حتما باید به hop قبلی که در ERO مشخص شده، directly connected باشند و از لینک بین این دو LSR حتما به عنوان بخشی از مسیر LSP استفاده خواهد شد.
• loose Hop ها آن دسته از hop هایی هستند که حتما باید در LSP از آن ها استفاده شود ولی الزاما به hop قبلی directly connected نیستند و ممکن است برای رسیدن به آن ها چند راه مختلف وجود داشته باشد.

در مثال زیر، روتر F یک Strict hop می باشد چرا که هم آن و هم روتر ماقبل آن جزیی از LSP هستند و از لینک بین آنها حتما باید به عنوان بخشی از LSP استفاده گردد. اما روتر E یک loose hop است چرا که بین آن و روتر B که در LSP مشخص شده، چند راه وجود دارد و از هر کدام این راه ها نیز می توان برای رسیدن B به E استفاده نمود.

تولید ERO بر عهده ی Ingress LSR می باشد ولی Ingress LSR چطور مشخص می کند که از کدام LSR ها باید برای LSP ای که قرار بر ساخته شدن آن است، استفاده شود؟

یک روش برای انجام این کار، پیکربندی مسیر به صورت دستی بر روی Ingress LSR می باشد. این روش دقیقا مشابه استفاده و پیکربندی static route است. مشابه static route، پیکربندی استاتیک ERO زمانی مفید است که قصد داشته باشیم کنترل دقیقی بر مسیرها و اتفاقاتی که در ساختار رخ می دهند، داشته باشیم.

اما دقیقا مشابه static routing اگر ساختار شبکه بزرگ شود و تعداد LSP هایی که باید پیاده سازی شوند افزایش یابد، به همان اندازه مشکلات پیکربندی و مدیریت این LSP ها هم سخت تر خواهد شد. تصور کنید که به ازای هر تغییری، یک LSR دیگر قادر به تامین محدودیت ها و منابعی که شما در حین پیکربندی مشخص کرده اید نباشد، بنابراین مجبور خواهید بود که دوباره همه چیز را از ابتدا پیکربندی نمایید.

روش دوم، تعیین ERO به روش داینامیک می باشد. به عبارتی استفاده از یک الگوریتم برای محاسبه ی ERO. در این روش با اعمال هر تغییری در توپولوژی، محاسبات لازم برای اعمال تغییرات جدید، توسط الگوریتم مربوطه به صورت خودکار انجام می شوند اما در این حالت نظارت و کنترل، ضعیف تر از حالت Static خواهد بود.

الگوریتمی که برای محاسبه ی داینامیک ERO مورد استفاده قرار می گیرد، نسخه ی تغییر یافته ای از الگوریتم SPF با نام  Constrained Shortest Path First  یا به اختصار CSPF می باشد.

نحوه ی عملکرد CSPF

برای بررسی CSPF ابتدا بهتر است مروری بر نحوه ی عملکرد SPF داشته باشیم:

هر روتری که یک پروتکل Link State بر روی آن پیاده سازی شده باشد، واحد داده ای را تولید می کند که در آن همسایه های directly connected به آن روتر و همینطور cost هر لینک تا آن همسایه ها و … مشخص شده است. این واحدهای داده یا Data Unit ها داخل Area مشخص شده flood می شوند و تمام روترهای داخل این Area، واحد داده ای که از همسایه های خود دریافت می کنند، در دیتابیسی ذخیره می نمایند. بعد از این که یک روتر تمام Data Unit های مربوط به تمام همسایه های خود را دریافت کرد و در دیتابیس خود ذخیره نمود، بر حسب اطلاعات این دیتابیس، الگوریتمی را به اسم SPF احرا می کند که خروجی این الگوریتم، کوتاهترین مسیرها به هر روتر در Area تعریف شده می باشند. از اطلاعات حاصل از خروجی الگوریتم SPF، ورودی های جدول route که نشان دهنده‌ی بهترین next-hop ها به هر مقصد هستند، به دست می آید.

اطلاعاتی که توسط Data Unit ها می توانند حمل شوند، قابل گسترش و بسط دادن هستند. به همین دلیل برای انجام عمل MPLS-TE پروتکل هایی مانند OSPF و IS-IS، اطلاعات بیشتری در رابطه با اینترفیس ها توسط Data Unit ها flood می کنند که این اطلاعات شامل:

• حداکثر bandwidth
• حداکثر میزان bandwidth ای که باید برای یک LSP کنار گذاشته شود
• میزان bandwidth موجودی که برای هیچ LSP ای ذخیره نشده
• یک متریک برای اینترفیس فارغ از متریکی که IGP ها به عنوان متریک اینترفیس ها استفاده می کنند
• Administrative Group ای که اینترفیس به آن تعلق دارد که اصطلاحا از آن با نام Link Color یاد می شود و در واقع سیاست هایی هستند که مشخص میکنند چه لینک های حتماً باید در یک LSP استفاده شوند.

زمانی که این اطلاعات توسط Data Unit ها flood می شوند، LSR ها این اطلاعات را در دیتابیسی به اسم Traffic Engineering Database یا به اختصار TED ذخیره می نمایند.

زمان تعریف LSP روی Ingress LSR، می توان محدودیت هایی که قرار است برای LSP در نظر گرفته شوند و توسط Data Unit ها حمل شوند را مشخص کرد. مثلا مقدار bandwidth مورد نیاز LSP، هزینه یا cost مسیر، Link Color هایی که LSP باید یا نباید از آن ها استفاده کند.

Ingress LSR یک نسخه ی خاص از الگوریتم SPF با اسم CSPF را اجرا می کند کهورودی های آن اطلاعات TED و اطلاعاتی هستند که به عنوان محدودیت های LSP لحظه ی تعریف آن، مشخص شده اند.

خروجی SPF ورودی های Unicast Routing Table و خروجی CSPF در واقع ERO ای است که توسط PATH Message به سمت Egress LSR ارسال می شود و از این طریق منابع مورد نیاز برای LSP ای که قرار بر ساخته شدن آن است، رزرو می شود. Egress LSR هم در پاسخ به PATH Message ای که دریافت می کند با ارسال یک Resv message، عمل توزیع Label ها یا همان Label Distribution را انجام می دهد و به این ترتیب نهایتا LSP ساخته می شود.

بعد از کامل شدن تمام این مراحل، RSVP ورودی ای را به unicast routing table اضافه می کند که نشان دهنده ی LSP به صورت یک Virtual Link بین Ingress LSR و Egress LSR است.

اما RSVP-TE اصطلاحا یک Soft State Protocol محسوب می شود به این معنی که،برای حفظ ارتباط adjacency بین دو همسایه ی RSVP، پیام های سیگنالینگ باید به صورت دوره ای بین این دو روتر رد و بدل شوند. اگر هر کدام از این پیام ها بنا به هر دلیلی به دست یکی از این روترهای همسایه نرسد، بعد از گذشت یک بازه زمانی مشخص (تحت عنوان Refresh timer) ارتباط adjacency بین آن دو روتر از بین خواهد رفت.

بنابراین زمانی که یک LSP ساخته می شود، برای آن که همیشه در حالت UP باقی بماند باید بین دو روتر همسایه یعنی Ingress و Egress، به صورت مداوم پیام های PATH و Resv رد و بدل شوند و از آن جایی که این پیام ها از طریق hop هایی که در راه رسیدن Ingress به Egress قرار دارند عبور می کنند، این بازنگری UP بودن LSP در تمام روترهایی که در طول LSP قرار دارند انجام می شود (hop-by-hop).

راهکاری که در پاسخ به ضعف و مشکلات روش MPLS-TE و در راستای محقق ساختن هرچه بیشتر پارادایم Source Routing معرفی گردیده است، Segment Routing می باشد.

Segment Routing تکنولوژی نه چندان جدید برای انجام Source Routing می باشد. در این روش، مبدا مسیری را انتخاب کرده و آن را در قالب لیستی از سگمنت ها در هدر پکت قرار می دهد. segment ها مشخص کننده ی رفتار و عملی هستند که باید در قبال پکت صورت گیرد. با استفاده از سگمنت روتینگ در شبکه ها، دیگر نیازی نیست که منطق ارسال پکت ها حتما بر اساس یک application خاص یا بر اساس یک جریان خاص باشد، بلکه forward پکت ها تنها بر اساس همان دستورالعملی که توسط سگمنت ها مشخص شده اند، صورت می گیرد.

تفاوت سگمنت روتینگ با MPLS و MPLS-TE در آن است که، Segment Routing از هیچ پروتکل اضافه تری چون LDP و RSVP برای سیگنالینگ و forward اطلاعات خود در طول یک دامنه ی SR استفاده نمی کند بلکه در مقابل، این اعمال را تنها با بهره گرفتن از قابلیت های توسعه یافته ی پروتکل هایی چون OSPF و IS-IS انجام می دهد. هم چنین در هنگام اجرا در یک ساختار MPLS یا IPv6، می تواند مستقیما از data plane آن ها بهره گیرد. اگر ساختار MPLS باشد، SR مستقیما از MPLS Data Plane بدون هیچ تغییری در آن، استفاده می کند. مزیت دیگر SR نسبت به MPLS در استفاده ی کارآمدتر از bandwidth و همینطور کاهش latency است.

Segment Routing: مفاهیم پایه

یک دامنه ی SR مجموعه ای از روترها است که اصطلاحا همه ی آن ها SR-Capable می باشند به این معنا که قابلیت تشخیص و کار با سگمنت ها را دارند. مشابه LSP در MPLS، مسیری در دامنه ی SR که به منظور ارتباط نقاط مختلف از آن استفاده می شود، SR-PATH نام دارد. SR-PATH الزاما کوتاهترین مسیر محاسبه شده توسط IGP نیست. به بیان بهتر SR-PATH می تواند کوتاهترین مسیر محاسبه شده توسط IGP و یا مسیری که بر حسب پارامترهای TE تعیین شده است، باشد. در واقع این سگمنت ها هستند که هر کدام بخشی از مسیر را مشخص می کنند که ترکیب آن ها با هم، نشان دهنده ی کل مسیر از یک مبدا تا یک مقصد مشخص می باشد.

اگر قرار بر بررسی SR در ساختار MPLS باشد، سگمنت ها معادل label ها در MPLS هستند و چندین سگمنت در قالب MPLS Label Stack گنجانده می شوند. در قبال سگمنت ها نیز همان اعمال مربوط به Label ها یعنی: PUSH، عمل POP (که در SR تحت عنوان NEXT خطاب می شود) و SWAP (که در SR تحت عنوان Continue خطاب می شود) صورت می گیرد. هنگامی که روتری پکتی را در دامنه ی SR دریافت می کند، بالاترین سگمنت در stack را مورد پردازش قرار داده و عمل تعیین شده برای سگمنت را در قبال آن انجام می دهد.

هر سگمنت توسط شناسه ای با نام Segment ID یا به اختصار SID، مشخص می شود. SID عددی صحیح و 32 بیتی است. SID ها توسط IGP extension ها در دامنه ی SR توزیع می شوند.

SID ها یا globally unique هستند به این معنا که چنین SID هایی در کل دامنه ی SR توسط تمام روترها قابل تشخیص می باشند و یا locally هستند که چنین SID هایی تنها توسط روتری که تولید شده اند قابل شناسایی و فهم می باشند. در دامنه ی SR هر روتر (یا همان node) و هر لینک (یا همان adjacency) دارای یک SID است.

نهاد IETF انواع مختلفی از سگمنت ها را معرفی کرده که مهم ترین آن ها عبارتند از:

1- IGP Prefix segment:
این سگمنت ها حاوی آدرس IP یک Prefix می باشند که توسط یک IGP فرا گرفته شده است. شناسه ی این سگمنت ها Prefix SID نام دارد و این SID ها globally unique می باشند. node segment ها فرم خاصی از Prefix segment ها هستند که حاوی آدرس IP اینترفیس loopback یک نود به صورت یک Prefix بوده و مشخص کننده ی یک نود می باشند.

2-IGP adjacency segment:
این سگمنت ها حاوی ارتباطات adjacency یک روتر با همسایه اش می باشند. در واقع منظور از adjacency، لینک بین دو روتر همسایه است. به SID این سگمنت ها اصطلاحا adjacency SID گفته می شود. adjacency SID ها هم می توانند locally unique باشند و هم globally unique. به این معنا که یک adjacency segment هم می تواند تنها به لینک ارتباطی بین یک روتر و همسایه اش اشاره داشته و یا این که به چندین hop در دامنه ی IGP، اشاره داشته باشد.

3- IGP Anycast segment:
این سگمنت ها مشابه Prefix segment ها می باشند با این تفاوت که مشخص کننده ی یک Prefix یا یک روتر خاص نیستند بلکه به مجموعه ای از روترها اشاره دارند. شناسه ی این سگمنت ها یا اصطلاحا Anycast SID ها نیز همانند Prefix SID ها globally unique هستند.

4- Binding segment:
نشان دهنده ی یک tunnel در دامنه ی SR می باشد. حال این تانل می تواند یک SR-Path دیگر، یک سیگنال LDP یا یک سیگنال RSVP-TE و یا هر encapsulation دیگری باشد.

هر روتری که SR بر روی آن فعال شده باشد، رنجی از Label های MPLS را برای سگمنت های global ذخیره می کند که اصطلاحا SR Global Block یا به اختصارSRGB خطاب می شود.

ادمین شبکه به هر روتر، یک node SID منحصر به همان روتر اختصاص می دهد. از سوی دیگر adjacency SID ها توسط روتر تولید می شوند و مقدار آن ها متفاوت از مقادیر node SID هاست. SID ها هدایت کننده ی داده ها در طول یک مسیر مشخص می باشند.

Segment Routing: عملکرد

مثال اول: تعیین مسیر با استفاده از adj-SID ها

 adj-SID ها، در واقع local label هایی هستند که به یک اینترفیس خاص و next-hop ای که در سر دیگر اینترفیس قرار دارد، اشاره دارند. adj-SID ها نیاز به پیکربندی خاصی ندارند و به محض فعال شدن SR برای OSPF یا IS-IS، روتر به صورت خودکار به هر اینترفیسی که بر روی آن این IGP ها فعال باشند، یک adj-SID اختصاص می دهد.

 IS-IS برای تبلیغ این SID ها، از sub-TLV های جدیدی تحت عنوان Adj-SID sub-TLV بهره می گیرد که عبارتند از:

TLV 22 (Extended IS Reachability) [RFC 5305]
TLV-222 (Multitopology IS) [RFC5120]
TLV-23 (IS Neighbor Attribute) [RFC5311]
TLV-223 (Multitopology IS Neighbor Attribute) [RFC5311]
TLV-141 (inter-AS reachability information) [RFC5316]

در OSPF نیز برای تبلیغ این SID ها از adj-SID sub-TLV Type 2  و LAN adj-SID sub-TLV  Type 3  بهره گرفته می شود.

لازم به ذکر است که این توسعه های جدید تعریف شده هنوز در حال بررسی و گسترش می باشند که برای آشنایی با قالب این TLVها و همچنین پیگیری روند تغییرات و پیشرفت آن ها برای IS-IS می توانید به این لینک و برای OSPF نیز به اینلینک مراجعه نمایید.

ساختار زیر را در نظر بگیرید:

در این ساختار، بر روی تمام روترها، SR فعال شده و هر روتر، adj-SID اختصاص داده به همسایه ی دیگر در آن سر لینک خود را از طریق IGP پیکربندی شده، به همسایه های خود تبلیغ می کند. هدف، انتقال ترافیک از روتر R1 به R7 می باشد. در حالت عادی و بدون هیچ پیکربندی خاصی، R1 برای انتقال ترافیک به سمت R7 از کوتاهترین مسیر ممکن (R1-R2-R3-R7) بهره می گیرد. اما قصد داریم تا با استفاده از SR کاری کنیم که ترافیک ها از مسیر: R1-R2-R4-R6-R7 ارسال شوند.

برای انجام این عمل، R1 یک stack مطابق آن چه در تصویر نشان داده شده ساخته، آن را به هدر پکت اضافه کرده و پکت را برای R2 ارسال می کند. R2 با دریافت این پکت، خارجی ترین lable در stack را بررسی کرده و متوجه می شود که گام بعدی برای ارسال پکت، R4 است. پس ابتدا خارجی ترین lable را PoP کرده و سپس پکت را به سمت R4 ارسال می کند. این عمل به همین منوال بر روی سایر روترهای تعیین شده در stack، ادامه می یابد تا پکت به مقصد مورد نظر یعنی R7 برسد.

مثال دوم: استفاده از Prefix-Segment

در یک ساختار MPLS، به صورت پیش فرض بدون هیچ پیکربندی خاصی، با فعال شدن Segment Routing بر روی یک روتر، روتر مجموعه ای از local label ها را تحت عنوان SR Global Block به منظور اختصاص این label ها به global segment ها، رزرو می کند. به عنوان مثال، رنج پیش فرض در نظر گرفته شده برای SRGB در روترهای سیسکو از 16000 تا 23999 می باشد که این رنج پیش فرض را می توان تغییر داد.

توصیه می شود که تمام روترهای داخل دامنه ی SR از رنج یکسانی برای SRGB استفاده نمایند اما امکان آن که هر نود، SRGB متفاوتی نسبت به سایر نودها داشته باشد نیز وجود دارد.

Prefix-SID ها به یک MPLS Local label ترجمه می شوند. نحوه ی ترجمه ی آن ها به این صورت است که: مقدار تعریف شده برای prefix-SID به علاوه ی کم ترین مقدار رنج در نظر گرفته شده برای SRGB می شود. به عنوان مثال در یک روتر سیسکو، اگر برای Prefix 10.10.10.0/24، مقدار 10 به عنوان index یا همان Prefix-SID تعریف شود و رنج SRGB نیز همان رنج پیش فرض باشد، نهایتا آن چه به عنوان label به Prefix 10.10.10.0/24 اختصاص داده می شود مقدار 16010 خواهد بود.

ساختار زیر را در نظر بگیرید:

در این ساختار هدف آن است که R1 پکتی را به مقصد 10.10.10.1 که متصل به R7 می باشد، از مسیر R1-R2-R4-R6-R7 ارسال نماید. همانطور که در بالا نیز اشاره گردید، Node-SID ها فرم خاصی از Prefix-SID ها می باشند که مشخص کننده ی یک نود بوده و معمولا به اینترفیس loopback پیکربندی شده بر روی روتر اختصاص می یابند. در این ساختار همانطور که در تصویر مشخص شده، در هر روتر به Prefix اینترفیس loopback آن روتر، index ای مطابق با شماره ی روتر اختصاص یافته است. به عنوان مثال: برای Prefix 1.1.1.1/32 مربوط به اینترفیس loopback روتر R1، مقدار 1 به عنوان index در نظر گرفته شده است. از سوی دیگر تمام روترهای درون ساختار از رنج پیش فرض SRGB، استفاده می کنند. پس با توجه به فرمول بالا، آن چه به عنوان label یا node-SID از طرف R1 برای سایر همسایگان IGP اش، ارسال می شود: 16001 می باشد. برای سایر روترها نیز به همین صورت خواهد بود.

از سوی دیگر در روترR7 برای Prefix 10.10.10.0/24 مقدار 10 به عنوان index تعیین شده است و آن چه به عنوان label این Prefix برای سایر روترهای دامنه ی SR تبلیغ شده و در RIB آن ها ثبت می گردد، مقدار 16010 است.

روتر R1 برای آن که پکت به مقصد 10.10.10.0/24 را بر اساس مسیر تعیین شده ارسال نماید، stack ای حاوی Prefix-SID مربوط به 10.10.10.0/24 و سپس node-SID روترهای R4-R6 ایجاد کرده، آن را به هدر پکت اضافه کرده و برای R2 ارسال می کند. روتر R2 با دریافت پکت و بررسی خارجی ترین label متوجه می شود که گام بعدی برای ارسال پکت، روتر R4 است. پس ابتدا خارجی ترین label را POP کرده و سپس پکت را برای R4 ارسال می کند. این روند به همین منوال ادامه می یابد تا نهایتا پکت به مقصد موردنظر برسد.

آن چه تا به اینجا شرح داده شد مفاهیم پایه و مثال هایی ساده از نحوه ی عملکرد Segment Rouing بودند. اگر علاقه مند به تست و پیکربندی SR برای یک ساختار ساده و بررسی موارد بیان شده در این پست می باشید، می توانید با مراجعه به این لینک، سناریوی پیکربندی SR برای یک ساختار ساده را دریافت نمایید.