آیا دلیلی برای وجود path computation element در SDN وجود دارد؟

آیا دلیلی برای وجود path computation element در SDN وجود دارد؟

 

مفهوم کلیدی در بحث SDN که جدا سازی سطح کنترلی از بخش فیزیکی شبکه می باشد و برای قابلیت مشاهده ، برنامه نویسی و … استفاده می شود ، بحث کاملا جدیدی نیست. Path computation element protocol  ( پروتکل هفت ساله توسط سازمان IETF ) یک پروتکل دیداری و کنترلی است که در MPLS کار میکند و تا حدودی سطح کنترل را از head-end router ، برای تعریف مسیر های شبکه حذف میکند.  با وجودی که معماری PCE ( همان path computation element ) کاملا عمومیت پیدا نکرده و پشتیبانی کاملی از open flow ندارد ، احتمال اینکه نقشی در معماری در حال ظهور SDN بخصوص در شبکه های service provider بازی کند ، وجود دارد.

چرا به معماری PCE نیاز داریم؟

محاسبه مسیر های انتها به انتها از طریق شبکه های MPLS-TE یا GMPLS-TE میتواند بسیار پیچیده باشد. traffic engineered paths پهنای باند و ضمانت های QoS مختلفی مانند حداقل کردن تاخیر و لرزش ( jitter ) با وجود اجتناب از مسیر های پرهزینه را فراهم میکنند. بنابراین تعیین کردن یک مسیر برای عبور از طریق یک شبکه active  و پیچیده که نیازمندی های مختلفی را ایجاب میکند ، وظیفه دشواری است.
ایجاد مسیر در مواقعی مانند عبور از دامنه های مسیر یابی و autonomous systems ( همان ASes )  و یا در شبکه های چند لایه که در آنها بخشی از مسیر شامل تکنولوژی هایی مانند سوئیچینگ نوری می باشد ، پیچیده تر هم می شود.
معماری PCE که در RFC 4655 تعریف شده است ،  محاسبه مسیر را با جدا کردن تعیین توپولوژی شبکه از ایجاد مسیر ، ساده میکند. هر دو وظیفه توسط
provider edge router که درخواست مسیر مشتری را دریافت میکند ، انجام شده است. این روترکه head-end router نام دارد ، می بایست از یک IGP (  یا interior gateway protocol )  مانند OSPF برای تعیین توپولوژی داخل دامنه مسیر یابی و همچنین از BGP ( یا border gateway protocol ) برای مسیر هایی که از مرز های AS عبور میکنند ، پشتیبانی کند. اضافه کردن محاسبات پیچیده برای مسیر  میتواند کارایی پردازنده روتر را پایین بیاورد.
در سال 2005 PCE IETF working group تشکیل و RFC 4655 در سال 2006 منتشر شد. RFC اولیه معماری PCE را تعریف و RFC های بعدی جزئیات آن را تکمیل کردند. اکنون مساله ای که وجود دارد ، بحث اضافه کردن ظرفیت ها و موضوعات مربوط به آدرس دهی در معماری PCE است.

PCE  در مقابل SDN ؟

علاقه به PCE در ابتدا محدود به یک سری از مشتریان با نگرانی های خاص بود ، اما اخیرا این علاقه مندی افزایش پیدا کرده چرا که ضرورت SDN مزایای جدا کردن سطح کنترلی را از component های اختصاصی شبکه نشان داده است.
open flow میتواند هر کاری که PCE قادر به انجام آن است حتی بیشتر از آن هم انجام دهد اما لازمه آن فراهم کردن تمام منطق یک MPLS-enabled router در کنترلر open flow  است.
در همین حال نیز PCE هم یک رویکرد تکاملی را نشان میدهد. پیاده سازی PCE در SDN نیازمند ارتقا دادن یا جایگزینی تمام روترها و سوییچ ها با واحد های سازگار است در حالی که در مورد اجرای SDN داخل PCE تنها نیازمند ارتقا روترهای head-end  هستیم.
telecom service providers متوجه شده اند که PCE بسیار جالب است چرا که ارتقا تمام شبکه های MPLS به شدت میتواند گران و آزار دهنده باشد. توانایی PCE در ترکیب کردن پارامتر های شبکه های نوری مزیت دیگری در کنار توانایی ایجاد مسیر در عبور از دامنه های مسیر یابی و ASes  می باشد.

تنظیمات و component های PCE

در یک شبکه مبتنی بر PCE ، بدانیم که head-end router  به پشتیبانی از IGP و احتمالا BGP ادامه میدهد ولی تعیین مسیر به یک یا چند PCE مربوط می شود. PCE یک component نرم افزاری اختصاصی برای محاسبه مسیر می باشد که ممکن است در یک سرور اختصاصی ، سرور مدیریت شبکه ( NMS ) ، یک cloud یا دریک head-end router با منابع پردازشی کافی اجرا شود.
هر PCE برای اطلاعاتی که برای ایجاد یک مسیر جدید نیاز دارد به یک traffic engineered database ( یا  TED) وابسته است. TED اطلاعات توپولوژی شبکه را از روتر ها ( که دارای پروتکل های استاندارد مسیریابی هستند ) بدست می آورد و ممکن است این اطلاعات را با دیگر TED ها به اشتراک بگذارد و یا با آنها تبادل اطلاعات کند. یک TED میتواند در یک سرور در طول PCE component ، در یک سرور جدای از PCE و یا احتمالا داخل یک head-end router قرار بگیرد. RFC 4655 تعدادی از تنطیمات ممکن را شرح می دهد:

  • در دامنه موجود اگر یک PCE وجود داشته باشد خودش تمام مسیر ها را محاسبه میکند.
  • در دامنه موجود ممکن است چند PCE موجود باشد اما هر مسیر توسط یک PCE ، به صورت جدا تعیین میشود.
  • چند PCE میتوانند محاسبه مسیر را به صورت ترکیبی انجام دهند ، یک PCE درخواست مسیر را دریافت میکند سپس قبل از پاسخ به درخواست ، اطلاعات لازم را از دیگر PCE ها دریافت میکند.
  • جایی که مسیر از چند دامنه عبور میکند یک یا چند PCE در هر دامنه ترکیب شده تا مسیر کامل را ایجاد کنند.
  • میشود چند دامنه را در یک دامنه ترکیب کرد و یک PCE تمام مسیر ها را تعیین کند.
  • مسیر هایی هستند که loose hop دارند یعنی جایی در مسیر وجود دارد که 2 router مستقیما بهم متصل نیستند. روترها در loose hop باید در امتداد مسیر اصلی ، مسیری را به روتربعدی پیدا کنند که در اینجا میتوانند درخواستی را به همان PCE که مسیر سراسری را تعیین کرده یا به PCE دیگری ارسال کنند.
  • در شبکه هایی با چند AS یک معماری PCE میتواند روی یک AS در کنار دیگر AS ها (ASes ) که توسط معماری های سنتی کنترل می شوند ، مورد استفاده قرار بگیرد.

کمک های ایجاد مسیر توسط معماری PCE

RFC مربوطه چندین مورد از جاهایی که  معماری PCE در پیچیدگی ایجاد مسیر ارزش خود را نشان داده ، لیست کرده است.این موارد شامل:

  • نیاز به ایجاد مجموعه ای از مسیر هایی که یک هدف را دنبال میکنند ، مثلا برای حداقل کردن میزان استفاده از یک لینک
  • مواقعی که چند معیار باید برآورده شود مثلا علاوه بر اینکه نیاز داریم میزان استفاده از لینک حداقل شود ، نیاز به حداقل کردن تاخیر انتها به انتها نیز داریم.
  • وقتی که برای حداقل کردن هزینه یک نقطه در شبکه های چند نقطه ای ، یک نیازمندی وجود دارد.

ایجاد مسیر موقعی شروع میشود که یک  customer-edge router درخواستی را به provider-edge head-end router می فرستد که این روتر آن را به سمت PCE عبور میدهد. RFC 5440 پروتکلی را مشخص کرده که بین head-end routers و PCE ها مبادله انجام میدهد. یک درخواست شامل آدرس آیپی مبدا و مقصد و همچنین یک سری مشخصات در مورد پهنای باند مورد نیاز و پارامتر های QoS میباشد. PCE پس از دریافت درخواست ، یک مسیر را محاسبه میکند و داخل یک explicit route object ( یا ERO ) که هر hop را در طول مسیر مشخص کرده ، باز میگرداند.
سپس head-end router ، ERO را در امتداد مسیر مشخصی برای اختصاص دادن مسیر ( همان مسیر محاسبه شده در PCE ) داخل هر روتر مشمول میفرستد. فرمت ERO با فرمت RSVP-TE ERO که اخیرا توسط روترهای MPLS-TE enabled استفاده میشود ، یکسان است. در نتیجه روترها به غیر از
head-end router نیازی به اینکه برای پشتیبانی از PCE به روز رسانی شوند ، ندارند.

PCE های stateful و stateless

Stateless PCE ها رکوردی از مسیر ایجاد شده را نگه نمیدارند ، در حالی که نوع stateful ، رکورد تمام مسیر های فعالی را که اخیرا ایجاد کرده است حفظ میکند. رکورد های حاصل از مسیر های موجود ، یک stateful PCE را قادر می سازند که ایجاد مسیر ها را ، بدون تلاش برای اختصاص دوباره منابعی که به یک مسیر موجود قبلا سپرده است ، انجام دهد.
از طرفی stateless PCE ها باید از اختصاص دوباره منابع جلوگیری کنند. TED به روز رسانی هایی را در مورد منابع قابل دسترس در هر روتراز طریق شبکه به کمک IGP دریافت میکند. Stateless PCE در حین ایجاد یک مسیر از این اطلاعات استفاده میکند.
نگه داشتن حالت یک سری مزایا به همراه خود دارد ولی موجب افزایش پیچیدگی میشود. یک stateful PCE هنگامی که یک مسیر بسته میشود ، آگاه میگردد ، همچنین ممکن است تعیین کند که یک مسیر موجود میتواند re-optimaized شود تا QoS را بهبود ببخشد یا هزینه را کاهش دهد. علاوه بر این ها یک stateful PCE میتواند تضمین کند که مسیر هایی که برای پشتیبانی ( backup ) هنگام برطرف سریع failover ها  ایجاد شده اند ، از هیچ یک از مسیر های اولیه میان روترها یا لینک ها استفاده نمیکنند.
پایگاه داده حاصل از مسیر های stateful PCE ممکن است بسیار حجیم شوند و در یک شبکه بزرگ همراه با مکانیزم ایجاد و تشخیص سریع مسیر ، به روز نگه داشتن و sync کردن این پایگاه داده با TED میتواند دشوار باشد. داشتن چند PCE میتواند عوارضی را اضافه کنند چراکه پایگاه داده های PCE باید با رکورد های نگه داشته شده از مسیر هایی که دیگر PCE ها تولید کرده اند sync باشد. App هایی مانند VoIP ، video و collaboration به برآورده شده نیاز های QoS سختی وابسته هستند. افزایش استفاده از این برنامه ها همراه با ادامه یافتن نیاز به کاهش هزینه ها ، انگیزه هایی را بوجود آورده که به نظر میرسد ، پذیرش PCE در سطح گسترده حتمی است. کار هایی که در اکنون در حال انجام است ، مربوط به رفع مشکلاتی است که stateful PCE ها از خود نشان داده اند. با توجه به سطح علاقه ای که به فناوری PCE وجود دارد ، بی تردید توسعه های فعالی در زمینه PCE های stateful و stateless ادامه پیدا خواهد کرد.

 

منبع : searchsdn.techtarget.com

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *