Mi lenne, ha egyesítenénk a különböző szélső routereket? • A regisztráció

Rendszerszemlélet Az Edge routerek évtizedek óta az internet elengedhetetlen részét képezik, és a hozzáférési hálózatokat – vállalati LAN-okat, mobil- és szélessávú hálózatokat – kapcsolják össze a globális gerinchálózattal.

Ezeknek az eszközöknek gyakran rejtélyes neveik vannak – MPLS VPN Provider Edge útválasztók, mobilhálózatok esetében S/P-átjárók, üvegszálas hálózatok esetében pedig Broadband Network Gateway (BNG) -, de lényegében IP (L3) csomagtovábbítók, néha néha. kiegészítve a kereskedelmi hozzáférés-szolgáltatók által megkövetelt üzleti logikát támogató szolgáltatásokkal. De a világ változik, és vele együtt változik a szélső router alakja és funkciója is.

Figyelembe véve a modern felhőtechnológiát, különösen a peremekre való rohanást, azt várjuk, hogy ritkábban gondoljunk a gerinchálózatokhoz csatlakozó peremhálózatokra. Ehelyett a globális hiperskálázókhoz kapcsolódó helyi peremfelhőkben fogunk gondolkodni. Az eszközök szolgáltatást igényelnek egy szélső felhőtől, amely néha külső felhők felé továbbítja a kéréseket (lásd például a Cloudflare Workers és a Fly.io oldalt), így a valódi végpontok közötti kapcsolatok trendje kivételt képez.

A szélső útválasztó egyre inkább virtuális funkciók bontott gyűjteményeként valósul meg, nem pedig fizikai dobozon keresztül

Az L3-as csatlakozás természetesen továbbra is megvan, de ez egyre inkább a megvalósítási részlet lesz. És amikor ez az átállás megtörténik, az L3 adatsík a peremfelhő kapcsolási struktúrájában lesz elhelyezve, a megfelelő vezérlősíkkal (akár IETF meghatározott, 3GPP meghatározott, BBF meghatározott vagy védett) a felhőben futó mikroszolgáltatások valósítják meg (a él vagy központosított).

Ez azt jelenti, hogy a szélső útválasztó egyre inkább virtuális funkciók bontott gyűjteményeként valósul meg, nem pedig fizikai dobozon keresztül, a felhőben történő vezérléssel és az adatsíkkal, amely speciális infrastruktúrán fut a sebesség és a méretezés érdekében. Ebben az értelemben azt látjuk, hogy az SDN által bevezetett paradigma – logikailag centralizált vezérlés elosztott továbbítással – utat tör magának a peremre.

Az SD-WAN-ok az SDN-architektúra peremen történő alkalmazásának jelenlegi példája, és újabban a felhőalapú Secure Access Service Edge (SASE) szolgáltatások egyesítik a biztonsági rétegeket a megoldásban. De a minta nagyjából ugyanaz – az L3 csomagtovábbítás az adatsíkon gazdag felhőalapú vezérlősíkkal párosulva – jelentős (funkcionális) átfedéssel a hozzáférési átjárók felhő-natív megvalósításaival.

És mivel a mai SD-WAN ajánlatok többsége vertikálisan integrált és szabadalmaztatott, vitatkozhatunk azzal, hogy az SDN előnyei (például a hálózatüzemeltetők képessége a funkciók testreszabására) ezekben a megoldásokban ma már csak részben érvényesülnek.

Ha abbahagyja a „széli útválasztók dedikált eszközként” való gondolkodását, és az „útválasztást egy újabb élfunkciónak” tekinti, ez egy kis lépés annak felismeréséhez, hogy a mai szélső útválasztók sokfélesége alapvetően különbözik egymástól. ugyanaz, és hogy fel lehet építeni egy általánosított (és lebontott) peremútválasztási képességet, amely mindegyiket befogadja. Ez a funkció központilag irányítható és telepíthető, a funkcionális elemek több élen futnak, ahol esetspecifikus csomagfeldolgozásra van szükség.

Könnyebb mondani, mint megtenni, de valószínűnek tűnik, és megér egy kis előregondolást. A legfontosabb betekintés az, hogy a fent vázolt összes forgatókönyv hasonló szerkezetű, az L3 továbbítással az adatsíkon, a következők támogatásával kiegészítve:

• Biztonságos alagutak → kapszulázást/dekapszulálást igényelnek

• A differenciált szolgáltatás → Q-in-Q címkézést és osztályalapú sorokat igényel

• Számlázási és könyvelési → számlálók szükségesek folyamatonként

• Házirend érvényesítése → Hozzáférés-szabályozási szabályok megkövetelése

• A megfigyelhetőség → sávon belüli hálózati telemetriát igényel

És egy mikroszolgáltatás-alapú vezérlősík, amely megvalósítja:

• Hitelesítés → módosítások engedélyezése az adatsík alagutakban

• Előfizetők kezelése → a számlálók és sorok frissítését folyamatonként indíthatja el

• Mobilitás és útválasztás → Indítsa el a továbbítási módosításokat az erőforrások elérhetősége alapján

• Munkamenet- és házirend-kezelés → változások hozzáférés-szabályozási szabályokat váltanak ki

• Diagnosztika és anomáliák észlelése → változások kiváltása a sávon belüli hálózati telemetriában

Az adatsík összes funkciója megvalósítható P4 programozási továbbítási csővezetékekben (erről később), ahol a vezérlőfüggvények listájában szereplő “triggering” kapcsolat segít megérteni, hogyan hozhatunk létre konvergens vezérlő/adatsík interfészt – valami ún. P4-Runtime (P4RT) támogatás.

Az általánosított adatsíkra már létezik példa, és az SDN-könyvünkben leírjuk. Ez a fabric.p4 program valósítja meg az ONF SD-Fabric továbbítási folyamatát, amely (a) L3 továbbítást valósít meg az élfelhőben található levél-gerinc kapcsolószövet számára, és (b) kiterjeszthető különböző bejáratok. hálózati technológiák (5Gs UPF és PON-alapú BNG) az internetre.

A jelenlegi megvalósítás kissé nyers (használ #ifdef), de az ötlet egyértelmű: meg lehet építeni egy L3 forwarding pipeline-t, amely hozzáférés-specifikus “bővítményekkel” bővíthető.

Amikor felugrik egy szintet, képzelje el, hogy addig iterál a fabric.p4-en, amíg nem rendelkezik egy kiterjeszthető élfelhő adatsíkkal, amely alkalmas a fent leírt összes felhasználási esetre. A P4RT által generált interfész ezután több vezérlősík-bérlőt is támogathat, például lehetővé téve a 3GPP által definiált magnak és egy SD-WAN vezérlőnek, hogy egymástól függetlenül állítsák be a sorparamétereket, határozzák meg a beágyazási/kicsomagolási címkéket, telepítsék a továbbítási szabályokat és így tovább.

A konvergencia egy megosztott adatsíkon, de annak elfogadása, hogy több vezérlősík is létezik együtt, jó kiindulási pont. De a konvergencia a vezérlősíkon is elérhető közelségbe kerülhet, ahol azt várhatjuk, hogy egy konvergens adatsík katalizálja ezt a folyamatot.

Véleményem szerint ez főként az ösztönzők összehangolásáról szól a különböző területeken. A BBF már dolgozik egy konvergens hozzáférési hálózat vezérlősíkon, amely igazodik a 3GPP által definiált mobil maghoz, főként azért, mert a távközlési cégeknek van ösztönzése ennek megvalósítására.

Egy másik jó példa a Magma, amely egységes vezérlősíkot és programozható adatsíkot határoz meg mind a RAN-alapú, mind a Wi-Fi alapú vezeték nélküli hálózatokhoz. Ahogy a vállalatok elkezdik kiépíteni a privát 5G-t, a kezelésük egységesítésére irányuló nyomás csak növekedni fog.

Az SD-WAN használati eset inkább helyettesítő karakter. Egyrészt az SD-WAN meglepően hasonlít az SD-RAN-hoz abban a funkcionalitásban, amelyre egy szélső útválasztótól szüksége van. Másrészt az SD-WAN ajánlatok eddig ellenálltak a szétbontásnak. Ugyanez természetesen egészen a közelmúltig igaz volt a távközlési hozzáférési hálózatokra is.

A szolgáltatók lehetőséget kapnak a funkciók testreszabására ahelyett, hogy elfogadnák a router gyártójától származó csomagot.

Ha elfogadjuk, hogy lehetséges a peremútválasztás egységesítése, akkor egy ésszerű következő kérdés: kívánatos-e? Azt mondanám, hogy az érték először a bontásból származik, ahogyan azt már láthattuk más környezetekben, például a felhőalapú adatközpontban.

Miután a vezérlősíkot elválasztják az adatsíktól, az innováció mindkettőben könnyebben megtörténhet, és ezen eszközök kezelői lehetőséget kapnak a funkciók testreszabására, ahelyett, hogy elfogadnák a router gyártójától származó csomagot.

Másodszor pedig lehetőség nyílik a perem holisztikusabb megtekintésére, lehetőséget kínálva a hozzáférési technológiától független konzisztens hálózati irányelvek alkalmazására. De ez egy másik bejegyzés témája. ®