Võrgud lahti ühendatud: üleminek kavatsuspõhiste autonoomsete toimingute poole – IBM Blog

Telekommunikatsioonitööstus, globaalse ühenduvuse nurgakivi, on juba mõnda aega läbinud tehnoloogilist renessanssi, mille taga on sellised uuendused nagu 5G, asjade internet, pilvandmetöötlus ja AI. Selle tulemusena on võrkude haldamine muutunud üha raskemaks. Rutiinsete ülesannete käsitlemiseks, võrgu seisundi jälgimiseks ja probleemidele reaalajas reageerimiseks on vaja automatiseerimist. Siiski ei pruugi sideteenuste pakkujate (CSP) olemasolevad oskused olla kooskõlas selle dünaamilise maastiku muutuvate nõudmistega. Kaasaegsel ajastul edu saavutamiseks vajavad CSP-d mitmekülgseid meeskondi, sealhulgas andmeteadlasi andmete tõlgendamiseks ja toimimiseks, tarkvaraarendajaid automatiseerimiseks tarnija rakendusliideste (API) kaudu ja teenuse tagamise insenere suletud ahelate kavandamiseks, et tagada teenuse usaldusväärsus.

Kuigi CSP-d täidavad lõhe, luues mitmekesise kogemusega meeskondi, saavad nad samaaegselt kasu ka samaaegse trendi olulistest edusammudest. Programmeerimiskeeled on arenenud madala koodi/koodita paradigmade suunas ning generatiivse AI esilekerkimisega oleme jõudnud punkti, kus alusmudelid suudavad genereerida ametlikku koodi ülesannete loomuliku keele kirjelduste põhjal. See andis kontseptsioonile uue vaatenurga kavatsuspõhine võrgustik (IBN), kus inimadministraatorid väljendavad kõrgetasemelisi võrgueesmärke loomulikus keeles, mida nimetatakse kavatsusteks, ja et need inimlikud kavatsused tõlgitakse automaatselt võrgupoliitikateks ja konfiguratsioonideks. IBN-il on potentsiaali parandada võrguhaldust ja see võib muutuda telekommunikatsiooniettevõtete talentide puudujäägi lahendamisel mängu muutjaks. Astudes sammu edasi, autonoomsed võrgud (AN) lubavad kasutada kavatsusi sisenditena võrkude autonoomseks isekonfigureerimiseks, ise optimeerimiseks ja iseparandamiseks, kui nende tingimused arenevad.

Kuigi me võime ette kujutada helget tulevikku nii IBN-i kui ka AN-i jaoks, on püsivad mured nende teostatavuse ja programmirakenduste, sealhulgas kavatsuste väljendamise, võrgukonfiguratsiooni täpse tõlkimise, süsteemi läbipaistvuse ja keerukuse pärast. Selles ajaveebis sukeldume valdkondadesse, kus nende praktiline rakendamine omab potentsiaali, ja analüüsime väljakutseid, mis neil teel võivad tekkida.

Motiveeriv juhtum: uute teenuste tutvustamine kavatsusteta

CSP-meeskondade ja võrgu vahelise suhtluse sujuvamaks muutmise vajaduse mõistmiseks kasutame näitena uut teenuse juurutamist.

Eeldame, et CSP võrgu toimimine on automatiseeritud vastavalt dokumendis kirjeldatud spetsifikatsioonidele TMF sissejuhatav juhend 1230 (IG1230) autonoomsete võrkude tehnilise arhitektuuri kohta. Selles kontekstis on CSP OSS-il (1) teenuste osutamise, automatiseeritud varustamise ja automatiseeritud testimise korraldaja, (2) võrgu inventuuriga tagamissüsteem, mis kogub andmeid, loob ülevaate võrgu oleku kohta ja hõlbustab seega andmepõhist otsuste tegemist. suletud ahela juhtimise kontekstis ja (3) poliitikahaldur, mis juhib võrgu käitumist eelnevalt määratletud poliitikate abil, tagades kooskõla laiema CSP poliitikaga. Lühidalt öeldes keerlevad automatiseeritud toimingud teenuste tiheda sidumise ümber neile määratud inimese loodud TOSCA teenusekirjelduste, konfiguratsioonide, poliitikate ja hädavajalike töövoogudega, millesse teenusedisainerid lisavad projekteerimise ajal luureandmeid ja otsustusvõimet. Teenusedisainerid peavad ennetavalt ette nägema paljusid võrgus esineda võivaid tingimusi ja andma üksikasjalikud juhised nende lahendamiseks – nullpuudutuse kogemus saavutatakse seni, kuni tulevased tingimused on ette nähtud ja nende käsitlemiseks on olemas poliitika.

Kasutame termineid Päev 0, Päev 1 ja Päev 2 erinevate teenuse elutsükli etappide jaoks, nimelt teenuse kujundamine, teenuse käivitamine ja teenuse tagamine, Vastavalt.

• Teenuse disain hõlmab erinevate teenusevarade arendamist, nagu on kujutatud joonisel 1. See on teenuse disainimeeskonna ülesanne, kes peab mõistma teenuse Day1 ja Day 2 toiminguid ning tootma vajalikke töövooge ja skripte. Punased jooned joonisel 2 kujutavad uue teenuse teenuse osutamise protsessi, tagades, et teenust saab nüüd tellida.

• Teenuse käivitamine toimub teenusetellimuse saabumisel abonendi taotluse alusel. Tänapäeval saabub teenindustellimus CSP-des tavaliselt teenusetellimuste haldurilt (SOM) TMF 641 liidese kaudu. Kui teenuseorkestraator saab teenusetellimuse, tagab ta, et töövood täidetakse ning nõutud jälgimiskonfiguratsioonid, PM/FM-mudelid ja poliitikad on juurutatud ja töötavad. Näitame joonisel 2 roheliste joontega teenuse eksemplari.

• Teenuse tagamine järgib suletud ahela lähenemisviisi, kus juurutatud teenuste tingimused läbivad pideva jälgimise ja automatiseeritud elutsükli toiminguid. Kinnituse suletud ahelat kujutame joonisel 2 siniste joontega.

Kokkuvõtvalt võib öelda, et just projekteerimise faas hõlmab olulisel määral käsitsitööd, kuna uue teenuse jaoks on vaja varustada võrk juhistega.

Mis on kavatsused?

IBN-is viitavad kavatsused kõrgetasemelistele eesmärkidele, mida CSP soovib oma võrgus saavutada. Selle asemel, et tegeleda keerukate madala tasemega võrgukonfiguratsioonidega 0. päeva toimingute ajal, nagu eespool kirjeldatud, väljendavad insenerimeeskonnad eesmärke kavatsustega ja kavatsuste aluseks olev loogika muudab need vajalikuks võrgukonfiguratsiooniks, mis täidab eesmärgi eesmärgi.

Pärast konfiguratsioonide rakendamist võrku jälgib AN pidevalt juurutatud teenuseid ja kohandab konfiguratsiooni tagamaks, et toiming jääb kindlaksmääratud eesmärkidega vastavusse. AN laiendab kavatsuste kasutamist 2. päeva operatsioonidele.

IBN ja AN perspektiivid

Järgmisena pakume välja mõned aspektid, mille puhul kavatsused võivad potentsiaalselt muuta kavatsusele eelneva ajastu väljakujunenud tavasid.

• 0. päeva toimingud:
  • Ettevalmistus uuteks teenusteks – Kasutage generatiivset AI-d loomuliku keele sisendi töötlemiseks, et täiendada iseseisvalt teenusenõudeid.
  • Uute teenuste tutvustamine – Määratlege loomuliku keele abil uued teenused, näiteks "pakkuge kohandatud ühenduvuslahendust turvaliseks suhtluseks tervishoiuasutustes" või "lubage asjade Interneti-seadmete side targa linna infrastruktuuris" ja kasutage generatiivset tehisintellekti vajalike teenusevarade automaatseks genereerimiseks.
  • Tarnijapõhiste ressursidraiverite automaatne genereerimine– Kasutage generatiivset AI-d, et luua tarnijaspetsiifilised ressursidraiverid, mis põhinevad hankija dokumentatsioonil.
• 1. päeva toimingud:
  • Teenuse tellimuse lihtsustamine – Võimaldab klientidel taotleda teenuseid loomulikus keeles. See kasutajasõbralik lähenemine võimaldab uudset teenuste tellimise kogemust, näiteks kataloogi pakkumiste segamist ja sobitamist.
  • Teostatavuse kontrollid – Lihtsustab valideerimiskontrolli, kuna kliendid väljendavad oma kavatsusi, hinnates tõhusalt kriitilisi tegureid, nagu fiiberoptilise liini saadavus. Tulemuseks on väiksem võrguinseneride koormus, kiirem teenuse valideerimine ning paindlikum ja reageerivam juurutamine.
• 2. päeva toimingud:
  • Dünaamiline teeninduse tagamine – Võimaldab võrkudel arukalt reageerida muutuvatele tingimustele ja kasutajate vajadustele. Paindlikud kavatsuspõhised poliitikad suurendavad paindlikkust, tagades võrguteenuste reaalajas töökindluse ja reageerimisvõime.

IBN-i ja AN-i väljakutsed

Lahendamist vajavad kaks peamist väljakutset:

1. Kuidas kavatsust väljendada ja edasi anda?
2. Kuidas kavatsust ellu viia: milline näeb välja kavatsuste käsitleja?

TM Forum tutvustas TMF921 Intent-põhist võrguühenduse API-d, pakkudes struktureeritud raamistikku kõrgetasemeliste võrgukavandite määratlemiseks. TM Forum määratleb eesmärgi järgmiselt: "Kavatsus on kõigi tehnilisele süsteemile antud ootuste, sealhulgas nõuete, eesmärkide ja piirangute ametlik kirjeldus.”. Samas osa ametlik spetsifikatsioon tutvustab muret: võrguinsenerid peaksid selle ametliku keelega kurssi viima, et kasutada ära kavatsuste kontseptsiooni kogu potentsiaal. Veelgi enam, formaalse spetsifikatsiooniga kavatsused ei pruugi tingimata vähendada nendega esitatavate parameetrite arvu. See aspekt seab väljakutse võrguhalduse eeldatavale sujuvamaks muutmisele, mida tavaliselt IBN-iga seostatakse.

Peale selle muutub kavatsuste spetsifikatsiooni formaliseerimisel kavatsuste käitleja, IBN-i põhikomponent, mis hoiab kavatsuste tõlgendamise loogikat, pelgalt kavatsuste formaalse keele deterministlikuks tõlgendajaks. Tekib küsimus, kuidas arendada kavatsuste käsitlejat deklaratiivse toimimisviisiga autonoomseks süsteemiks, kus inimesed ei pea ette nägema kõiki võimalikke võrgutingimusi ja andma selle lahendamiseks konkreetseid juhiseid. Vastasel juhul ei saa süsteemi toimimine edukalt üle minna automaatselt autonoomsele (TMF IG1230).

Edaspidistes blogides käsitleme IBN-i ja AN-i väljakutseid ja võimalusi lähemalt. Kas soovite rohkem teada saada? Võtke meiega ühendust aadressil maja.curic@ibm.com, chris.van.maastricht@nl.ibm.com ja tmtattis@ae.ibm.com.

Muutke tulevikuks
telekommunikatsiooniga