MPLS و MPLS-TE مقدمه‌ای برای 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 می باشد که در پستی دیگر به آن خواهیم پرداخت.