شبکه‌های بدون زنجیره: تغییر به سمت عملیات مستقل مبتنی بر هدف - وبلاگ IBM

صنعت ارتباطات از راه دور که سنگ بنای اتصال جهانی است، مدتی است که با نوآوری هایی مانند 5G، اینترنت اشیا، رایانش ابری و هوش مصنوعی، دوران رنسانس فناوری را پشت سر گذاشته است. در نتیجه، مدیریت شبکه ها به طور فزاینده ای سخت شده است. نیاز به اتوماسیون برای رسیدگی به وظایف معمول، نظارت بر سلامت شبکه و پاسخگویی به مسائل در زمان واقعی وجود دارد. با این حال، مجموعه مهارت های موجود در ارائه دهندگان خدمات ارتباطی (CSP) ممکن است با نیازهای در حال تحول این چشم انداز پویا هماهنگ نباشد. برای موفقیت در عصر مدرن، CSP ها به تیم های همه کاره، از جمله دانشمندان داده برای تفسیر و عملیات داده ها، توسعه دهندگان نرم افزار برای اتوماسیون از طریق رابط های برنامه نویسی برنامه کاربردی فروشنده (API) و مهندسین تضمین خدمات برای طراحی حلقه های بسته برای اطمینان از قابلیت اطمینان خدمات نیاز دارند.

در حالی که CSP ها شکاف را با ایجاد تیم هایی با تجربیات متنوع پر می کنند، آنها به طور همزمان از پیشرفت های قابل توجهی در یک روند همزمان بهره مند می شوند. زبان‌های برنامه‌نویسی به سمت پارادایم‌های کم‌کد/بدون کد تکامل یافته‌اند و با ظهور هوش مصنوعی مولد، ما در نقطه‌ای هستیم که مدل‌های پایه می‌توانند کد رسمی را بر اساس توصیف‌های زبان طبیعی وظایف تولید کنند. این دیدگاه جدیدی را به مفهوم داد شبکه مبتنی بر هدف (IBN)، که در آن مدیران انسانی اهداف شبکه در سطح بالا را به زبان طبیعی به نام «مقصد» بیان می‌کنند و این مقاصد انسانی به‌طور خودکار به سیاست‌ها و پیکربندی‌های شبکه ترجمه می‌شوند. IBN این پتانسیل را دارد که مدیریت شبکه را بهبود بخشد و می‌تواند به یک تغییردهنده بازی در رسیدگی به شکاف استعداد در شرکت‌های مخابراتی تبدیل شود. با برداشتن یک قدم جلوتر، شبکه های خودمختار (AN) وعده استفاده از مقاصد به‌عنوان ورودی برای خودپیکربندی، خودبهینه‌سازی و خودترمیمی شبکه‌ها را به‌محض تغییر شرایط آنها می‌دهد.

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

یک مورد انگیزشی: ارائه خدمات جدید بدون قصد

برای درک نیاز به ساده‌سازی تعاملات بین تیم‌های CSP و شبکه، از یک استقرار سرویس جدید به عنوان مثال استفاده می‌کنیم.

ما فرض می‌کنیم که عملیات شبکه CSP مطابق با مشخصات ذکر شده در آن خودکار است TMF Introductory Guide 1230 (IG1230) در معماری فنی شبکه های خودمختار. در این زمینه، OSS CSP دارای (1) یک سازمان دهنده برای ارائه خدمات، تهیه خودکار و تست خودکار، (2) یک سیستم تضمینی با موجودی شبکه است که داده ها را جمع آوری می کند، بینش هایی را در مورد وضعیت شبکه ایجاد می کند و در نتیجه تصمیم گیری مبتنی بر داده را تسهیل می کند. در زمینه کنترل حلقه بسته و (3) مدیر خط مشی که رفتار شبکه را با استفاده از خط مشی های از پیش تعریف شده هدایت می کند و از همسویی با سیاست های گسترده تر CSP اطمینان می دهد. به طور خلاصه، عملیات خودکار حول اتصال شدید سرویس‌ها با توصیف‌گرها، پیکربندی‌ها، خط‌مشی‌ها و جریان‌های کاری ضروری TOSCA طراحی شده توسط انسان اختصاص داده شده است که در آن هوشمندی و تصمیم‌گیری توسط طراحان خدمات در طول زمان طراحی اضافه می‌شود. طراحان سرویس باید به طور فعال طیف وسیعی از شرایطی را که ممکن است در شبکه رخ دهد پیش‌بینی کنند و دستورالعمل‌های دقیقی را در مورد نحوه رسیدگی به آن‌ها ارائه دهند - تجربه لمس صفر تا زمانی که شرایط آینده پیش‌بینی شده باشد و سیاست‌هایی برای رسیدگی به آنها وجود داشته باشد، به دست می‌آید.

ما از اصطلاحات روز 0، روز 1 و روز 2 برای مراحل مختلف چرخه عمر سرویس، یعنی طراحی خدمات, نمونه خدمات و تضمین خدماتبود.

• طراحی سرویس شامل توسعه دارایی های خدمات مختلف است که در شکل 1 نشان داده شده است. این وظیفه تیم طراحی سرویس است که باید عملیات روز 1 و روز 2 سرویس را درک کند و گردش کار و اسکریپت های مورد نیاز را تولید کند. خطوط قرمز در شکل 2 روند ارائه خدمات یک سرویس جدید را نشان می دهد و اطمینان می دهد که اکنون می توان سرویس را سفارش داد.

• نمونه‌سازی سرویس زمانی اتفاق می‌افتد که سفارش سرویس به دنبال درخواست مشترک می‌رسد. امروزه در CSP ها سفارش سرویس معمولاً از طریق رابط TMF 641 از مدیر سفارش سرویس (SOM) می رسد. هنگامی که ارکستراتور سرویس دستور سرویس را دریافت می کند، اطمینان حاصل می کند که گردش کار اجرا شده است و پیکربندی های نظارتی درخواستی، مدل های PM/FM و خط مشی ها مستقر و اجرا شده اند. نمونه سرویس را در شکل 2 در خطوط سبز نشان می دهیم.

• تضمین خدمات از یک رویکرد حلقه بسته پیروی می کند که در آن شرایط سرویس های مستقر تحت نظارت مستمر و اقدامات چرخه عمر خودکار قرار می گیرند. حلقه بسته اطمینان را در شکل 2 با خطوط آبی نشان می دهیم.

به طور خلاصه، این مرحله طراحی است که شامل مقدار قابل توجهی کار دستی است، زیرا لازم است شبکه با دستورالعمل هایی برای سرویس جدید ارائه شود.

مقاصد چیست؟

در IBN، intent به اهداف سطح بالایی اشاره دارد که CSP می خواهد در شبکه خود به آنها دست یابد. به جای پرداختن به پیکربندی‌های پیچیده شبکه سطح پایین در طول عملیات روز 0 همانطور که در بالا بحث شد، تیم‌های مهندسی اهداف را با مقاصد بیان می‌کنند و اهداف منطقی زیربنای آن‌ها آنها را به پیکربندی شبکه مورد نیاز ترجمه می‌کند که هدف هدف را برآورده می‌کند.

پس از اعمال پیکربندی ها در شبکه، AN به طور مداوم سرویس های مستقر شده را نظارت می کند و پیکربندی را برای اطمینان از اینکه عملیات در تراز با اهداف مشخص شده باقی می ماند، تطبیق می دهد. AN استفاده از intent ها را در عملیات روز دوم گسترش می دهد.

دیدگاه های IBN و AN

در مرحله بعد، ما برخی از جنبه‌هایی را ارائه می‌کنیم که در آن مقاصد به طور بالقوه می‌توانند رویه‌های تثبیت شده از دوران پیش از قصد را متحول کنند:

• عملیات روز 0:
  • آمادگی برای خدمات جدید – از هوش مصنوعی مولد برای پردازش ورودی زبان طبیعی برای تکمیل نیازهای خدمات به طور مستقل استفاده کنید.
  • معرفی خدمات جدید - خدمات جدید را با استفاده از زبان طبیعی تعریف کنید، مانند «ارائه راه حل اتصال مناسب برای ارتباطات ایمن در موسسات مراقبت‌های بهداشتی» یا «فعال کردن ارتباط دستگاه IoT در زیرساخت شهر هوشمند» و استفاده از هوش مصنوعی مولد برای تولید خودکار دارایی‌های خدمات ضروری.
  • تولید خودکار درایورهای منبع خاص فروشنده- از هوش مصنوعی مولد برای ایجاد درایورهای منبع خاص فروشنده، بر اساس اسناد فروشنده استفاده کنید.
• عملیات روز 1:
  • ساده سازی سفارش خدمات - به مشتریان اجازه می دهد با استفاده از زبان طبیعی خدمات درخواست کنند. این رویکرد کاربر پسند، تجربه سفارش سرویس جدید، مانند ترکیب و تطبیق پیشنهادات از کاتالوگ را امکان پذیر می کند.
  • بررسی های امکان سنجی - بررسی های اعتبارسنجی را آسان می کند زیرا مشتریان اهداف خود را با ارزیابی مؤثر عوامل مهم مانند در دسترس بودن خط فیبر نوری بیان می کنند. نتیجه کاهش بار مهندسین شبکه، اعتبارسنجی سریع‌تر سرویس، و استقرار چابک‌تر و پاسخگوتر است.
• عملیات روز 2:
  • تضمین خدمات پویا - شبکه ها را قادر می سازد تا به طور هوشمند به شرایط در حال تغییر و نیازهای کاربر پاسخ دهند. خط‌مشی‌های مبتنی بر هدف انعطاف‌پذیر، چابکی را افزایش می‌دهند، و اطمینان از قابلیت اطمینان و پاسخ‌دهی به‌زمان خدمات شبکه را تضمین می‌کنند.

چالش های IBN و AN

دو چالش اصلی وجود دارد که باید مورد توجه قرار گیرد:

1. چگونه یک منظور را بیان و منتقل کنیم؟
2. چگونه روی یک intent اجرا کنیم: کنترل کننده قصد چگونه به نظر می رسد؟

TM Forum API شبکه مبتنی بر هدف TMF921 را معرفی کرد که یک چارچوب ساختاریافته برای تعریف اهداف شبکه در سطح بالا ارائه می دهد. TM Forum هدف را به صورت زیر تعریف می کند:هدف مشخص کردن رسمی تمام انتظارات از جمله الزامات، اهداف و محدودیت‌های داده شده به یک سیستم فنی است.". با این حال، بخش مشخصات رسمی یک نگرانی را معرفی می کند: مهندسان شبکه باید خود را با این زبان رسمی آشنا کنند تا از پتانسیل کامل مفهوم هدف استفاده کنند. علاوه بر این، مقاصد با مشخصات رسمی لزوماً تعداد پارامترهایی را که باید با آنها ارائه شود کاهش نمی دهند. این جنبه، ساده‌سازی پیش‌بینی‌شده مدیریت شبکه را که معمولاً با IBN مرتبط می‌شود، به چالش می‌کشد.

علاوه بر این، با رسمی کردن مشخصات هدف، کنترل کننده هدف، مؤلفه اصلی IBN که منطق تفسیر هدف را در اختیار دارد، صرفاً به یک مفسر قطعی زبان رسمی قصد تبدیل می شود. این سوال مطرح می شود که چگونه ما کنترل کننده هدف را به یک سیستم خودمختار با روش عملیاتی اعلامی تبدیل می کنیم که در آن انسان ها نیازی به پیش بینی هر شرایط شبکه بالقوه و ارائه دستورالعمل های خاص برای حل آن ندارند. در غیر این صورت، عملیات سیستم نمی تواند با موفقیت از خودکار به خودمختار (TMF IG1230) تبدیل شود.

در وبلاگ های آینده به چالش ها و فرصت های IBN و AN با جزئیات بیشتری خواهیم پرداخت. می خواهید بیشتر بدانید؟ تماس با ما در maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com و tmtattis@ae.ibm.com.

برای آینده متحول شوید
با مخابرات