Nettverksfunksjon virtualisering - Network function virtualization

Nettverksfunksjoner virtualisering (også nettverksfunksjonsvirtualisering eller NFV ) er et nettverksarkitekturkonsept som bruker teknologiene til IT- virtualisering for å virtualisere hele klasser av nettverksnodefunksjoner til byggesteiner som kan koble sammen, eller kjede sammen, for å skape kommunikasjonstjenester.

NFV er avhengig av, men skiller seg fra, tradisjonelle servervirtualiseringsteknikker , slik som de som brukes i bedriftens IT. En virtualisert nettverksfunksjon, eller VNF, kan bestå av en eller flere virtuelle maskiner eller containere som kjører forskjellig programvare og prosesser, på toppen av standard høyt volum servere, brytere og lagringsenheter, eller til og med cloud computing- infrastruktur, i stedet for å ha tilpassede maskinvareapparater for hver nettverksfunksjon.

For eksempel kan en virtuell øktgrensekontroller distribueres for å beskytte et nettverk uten de typiske kostnadene og kompleksiteten ved å skaffe og installere fysiske nettverksbeskyttelsesenheter. Andre eksempler på NFV inkluderer virtualiserte lastbalansere , brannmurer , innbruddsdeteksjonsenheter og WAN-akseleratorer .

Bakgrunn

Produktutvikling innen telekommunikasjonsindustrien har tradisjonelt fulgt strenge standarder for stabilitet, protokolloverholdelse og kvalitet, reflektert av bruken av begrepet carrier grade for å betegne utstyr som viser denne påliteligheten. Selv om denne modellen fungerte bra tidligere, førte den uunngåelig til lange produktsykluser, et sakte utviklingstakt og avhengighet av proprietær eller spesifikk maskinvare, f.eks. Skreddersydde applikasjonsspesifikke integrerte kretser (ASIC). Økningen av betydelig konkurranse i kommunikasjonstjenester fra organisasjoner i rask bevegelse som opererer i stor skala på det offentlige Internett (som Google Talk , Skype , Netflix ) har fått tjenesteleverandører til å se etter måter å forstyrre status quo.

Historie

I oktober 2012, en gruppe av teleoperatørene publisert en stortingsmelding på en konferanse i Darmstadt, Tyskland , på programvaredefinerte nettverk (SDN) og Openflow . Handlingsoppfordringen som avsluttet stortingsmeldingen førte til opprettelsen av Network Specifications Virtualization (NFV) Industry Specification Group (ISG) innen European Telecommunications Standards Institute (ETSI). ISG besto av representanter fra telekommunikasjonsindustrien fra Europa og utover. Siden publiseringen av stortingsmeldingen har gruppen produsert over 100 publikasjoner. I 2016 ble en høy ytelse åpen kildekodeversjon av NFV utgitt. openNetVM er en høyytelses NFV-plattform basert på DPDK- og Docker-containere.

Rammeverk

NFV-rammeverket består av tre hovedkomponenter:

  1. Virtualiserte nettverksfunksjoner (VNFs) er programvareimplementeringer av nettverksfunksjoner som kan distribueres på en nettverksfunksjoners virtualiseringsinfrastruktur (NFVI).
  2. Nettverksfunksjoner virtualiseringsinfrastruktur (NFVI) er totaliteten av alle maskinvare- og programvarekomponenter som bygger miljøet der NFV-er er distribuert. NFV-infrastrukturen kan strekke seg over flere steder. Nettverket som gir tilkobling mellom disse stedene betraktes som en del av NFV-infrastrukturen.
  3. Nettverksfunksjoner virtualiseringsadministrasjon og orkestrasjonsarkitektonisk rammeverk (NFV-MANO Architectural Framework) er samlingen av alle funksjonelle blokker, datalagre som brukes av disse blokkene, og referansepunkter og grensesnitt som disse funksjonelle blokkene utveksler informasjon med det formål å administrere og orkestrere NFVI og VNF-er.

Byggesteinen for både NFVI og NFV-MANO er ​​NFV-plattformen. I NFVI-rollen består den av både virtuelle og fysiske prosesserings- og lagringsressurser og virtualiseringsprogramvare. I sin NFV-MANO-rolle består den av VNF- og NFVI-ledere og virtualiseringsprogramvare som opererer på en maskinvarekontroller . NFV-plattformen implementerer funksjoner som bærer klasse som brukes til å administrere og overvåke plattformkomponentene, gjenopprette fra feil og gi effektiv sikkerhet - alt som kreves for det offentlige transportnettverket.

Praktiske aspekter

En tjenesteleverandør som følger NFV-designen implementerer en eller flere virtualiserte nettverksfunksjoner, eller VNF-er . En VNF i seg selv gir ikke automatisk et brukbart produkt eller en tjeneste til leverandørens kunder. For å bygge mer komplekse tjenester brukes forestillingen om tjenestekjeding , der flere VNF-er brukes i rekkefølge for å levere en tjeneste.

Et annet aspekt ved implementering av NFV er orkestrasjonsprosessen . For å bygge svært pålitelige og skalerbare tjenester, krever NFV at nettverket skal kunne instansere VNF-forekomster, overvåke dem, reparere dem, og (viktigst for en tjenesteleverandørvirksomhet) fakturere for de tilbudte tjenestene. Disse attributtene, kalt bæreregenskaper, er allokert til et orkestrasjonslag for å gi høy tilgjengelighet og sikkerhet, og lave drifts- og vedlikeholdskostnader. Det er viktig at orkestreringslaget må kunne administrere VNF-er uavhengig av den underliggende teknologien i VNF-en. For eksempel må et orkestrasjonslag kunne administrere en SBC VNF fra leverandør X som kjører på VMware vSphere like godt som en IMS VNF fra leverandør Y som kjører på KVM.

Distribuert NFV

Den første oppfatningen av NFV var at virtualisert evne skulle implementeres i datasentre. Denne tilnærmingen fungerer i mange - men ikke alle - tilfeller. NFV antar og understreker størst mulig fleksibilitet med hensyn til den fysiske plasseringen av de virtualiserte funksjonene.

Ideelt sett bør virtualiserte funksjoner derfor være plassert der de er mest effektive og minst kostbare. Det betyr at en tjenesteleverandør skal være fri til å lokalisere NFV på alle mulige steder, fra datasenteret til nettverksnoden til kundelokalene. Denne tilnærmingen, kjent som distribuert NFV, har blitt understreket fra begynnelsen da NFV ble utviklet og standardisert, og er fremtredende i de nylig utgitte NFV ISG-dokumentene.

I noen tilfeller er det klare fordeler for en tjenesteleverandør å finne denne virtualiserte funksjonaliteten hos kundens lokaler. Disse fordelene spenner fra økonomi til ytelse til muligheten for funksjonene som virtualiseres.

Den første ETSI NFV ISG-godkjente offentlige multi-vendor proof of concept (PoC) av D-NFV ble utført av Cyan, Inc. , RAD , Fortinet og Certes Networks i Chicago i juni 2014, og ble sponset av CenturyLink . Den var basert på RADs dedikerte kundekant-D-NFV-utstyr som kjørte Fortinets Next Generation Firewall (NGFW) og Certes Networks 'virtuelle krypterings- / dekrypteringsmotor som Virtual Network Functions (VNFs) med Cyans Blue Planet-system som organiserte hele økosystemet. RADs D-NFV-løsning, en Layer 2 / Layer 3- nettverksavslutningsenhet (NTU) utstyrt med en D-NFV X86- servermodul som fungerer som en virtualiseringsmotor i kundekanten, ble kommersielt tilgjengelig innen slutten av den måneden. I løpet av 2014 hadde RAD også organisert en D-NFV Alliance, et økosystem av leverandører og internasjonale systemintegratorer som spesialiserer seg på nye NFV-applikasjoner.

Fordeler med NFV-modularitet

Når du designer og utvikler programvaren som leverer VNF-ene, kan leverandører strukturere den programvaren i programvarekomponenter (implementeringsvisning av en programvarearkitektur) og pakke komponentene i ett eller flere bilder (distribusjonsvisning av en programvarearkitektur). Disse leverandørdefinerte programvarekomponentene kalles VNF Components (VNFCs). VNF-er implementeres med en eller flere VNFC-er, og det antas, uten tap av generalitet, at VNFC-forekomster kartlegger 1: 1 til VM Images.

VNFC-er bør generelt kunne skalere opp og / eller skalere ut . Ved å være i stand til å tildele fleksible (virtuelle) CPUer til hver av VNFC-forekomster, kan nettverksadministrasjonslaget skalere opp (dvs. skalere vertikalt ) VNFC for å gi forventningene for gjennomstrømning / ytelse og skalerbarhet over et enkelt system eller en enkelt plattform. På samme måte kan nettverksadministrasjonslaget skalere ut (dvs. skalere horisontalt ) en VNFC ved å aktivere flere forekomster av slik VNFC over flere plattformer og derfor nå ut til ytelses- og arkitekturspesifikasjonene mens den ikke kompromitterer de andre VNFC-funksjonsstabilitetene.

Tidlige adoptere av slike arkitekttegninger har allerede implementert NFV-modularitetsprinsippene.

Forholdet til SDN

SDN, eller programvaredefinert nettverk , er et konsept relatert til NFV, men de refererer til forskjellige domener. Nettverksfunksjoner virtualisering (NFV) og Deep Packet Inspection (DPI) kan effektivt utfylle SDN-funksjonene.

I hovedsak er programvaredefinert nettverk (SDN) en tilnærming til å bygge datanettverksutstyr og programvare som skiller og abstraherer elementer i disse systemene. Dette gjøres ved å koble kontrollplanet og dataplanet fra hverandre, slik at kontrollplanet befinner seg sentralt og videresendingskomponentene forblir distribuert. Kontrollplanet samhandler både nordgående og sørgående . I nordgående retning gir kontrollplanet en felles abstrakt visning av nettverket til applikasjoner og programmer på høyere nivå som bruker API-er. I sørgående retning programmerer kontrollplanet videresendingsoppførselen til dataplanet ved hjelp av enhetsnivå-API-er for det fysiske nettverksutstyret distribuert rundt nettverket.

Dermed er NFV ikke avhengig av SDN- eller SDN-konsepter. Det er fullt mulig å implementere en virtualisert nettverksfunksjon (VNF) som en frittstående enhet ved hjelp av eksisterende nettverks- og orkestrasjonsparadigmer. Imidlertid er det iboende fordeler ved å utnytte SDN-konsepter for å implementere og administrere en NFV-infrastruktur, spesielt når man ser på forvaltning og orkestrering av VNF-er, og det er derfor det defineres multivendor-plattformer som inkluderer SDN og NFV i samordnede økosystemer.

En NFV-infrastruktur trenger et sentralt orkestrerings- og styringssystem som tar operatørforespørsler tilknyttet en VNF, oversetter dem til riktig prosessering, lagring og nettverkskonfigurasjon som er nødvendig for å bringe VNF i drift. En gang i drift må VNF potensielt overvåkes for kapasitet og utnyttelse, og tilpasses om nødvendig.

Alle disse funksjonene kan oppnås ved hjelp av SDN-konsepter, og NFV kan betraktes som en av de primære SDN-brukssakene i tjenesteleverandørmiljøer. Det er også åpenbart at mange SDN-brukstilfeller kan innlemme konsepter introdusert i NFV-initiativet. Eksempler inkluderer der den sentraliserte kontrolleren styrer en distribuert videresendingsfunksjon som faktisk også kan virtualiseres på eksisterende prosesserings- eller rutingsutstyr.

Industripåvirkning

NFV har bevist en populær standard selv i barndommen. Dens umiddelbare applikasjoner er mange, for eksempel virtualisering av mobile basestasjoner , plattform som en tjeneste (PaaS), innholdsleveringsnettverk (CDN), fast tilgang og hjemmemiljøer. De potensielle fordelene med NFV forventes å være betydelige. Virtualisering av nettverksfunksjoner distribuert på standardisert maskinvare forventes å redusere kapital- og driftsutgifter, samt service- og produktintroduksjonstider. Mange store leverandører av nettverksutstyr har kunngjort støtte for NFV. Dette har falt sammen med NFV-kunngjøringer fra store programvareleverandører som leverer NFV-plattformene som brukes av utstyrsleverandører til å bygge sine NFV-produkter.

For å realisere de forventede fordelene med virtualisering, forbedrer leverandører av nettverksutstyr imidlertid IT-virtualiseringsteknologi for å innlemme operatørklasse-egenskaper som kreves for å oppnå høy tilgjengelighet , skalerbarhet, ytelse og effektive nettverksadministrasjonsfunksjoner. For å minimere de totale eierkostnadene (TCO), må operatørkvalitetsfunksjoner implementeres så effektivt som mulig. Dette krever at NFV-løsninger bruker overflødige ressurser effektivt for å oppnå fem-nins tilgjengelighet (99,999%), og av databehandlingsressursene uten å gå på kompromiss med ytelsesforutsigbarhet.

NFV-plattformen er grunnlaget for å oppnå effektive NFV-løsninger for bærere. Det er en programvareplattform som kjører på standard flerkjernemaskinvare og er bygd ved hjelp av åpen kildekode-programvare som inneholder bæreregenskaper. NFV-plattformprogramvaren er ansvarlig for dynamisk omfordeling av VNF-er på grunn av feil og endringer i trafikkbelastningen, og spiller derfor en viktig rolle for å oppnå høy tilgjengelighet. Det er mange initiativer på gang for å spesifisere, justere og fremme NFV-operatørkvalitetsegenskaper som ETSI NFV Proof of Concept, ATIS Open Platform for NFV Project, Carrier Network Virtualization Awards og forskjellige leverandørøkosystemer.

VSwitch, en nøkkelkomponent i NFV-plattformer, er ansvarlig for å tilby tilkobling både VM-til-VM (mellom virtuelle maskiner) og mellom virtuelle maskiner og det eksterne nettverket. Dens ytelse bestemmer både båndbredden til VNF-ene og kostnadseffektiviteten til NFV-løsninger. Standard Open vSwitch (OVS) ytelse har mangler som må løses for å møte behovene til NFVI-løsninger. Betydelige ytelsesforbedringer rapporteres av NFV-leverandører for både OVS- og Accelerated Open vSwitch (AVS) -versjoner.

Virtualisering endrer også måten tilgjengeligheten spesifiseres, måles og oppnås i NFV-løsninger. Ettersom VNF-er erstatter tradisjonelt funksjons dedikert utstyr, er det et skifte fra utstyrsbasert tilgjengelighet til en tjenestebasert, end-to-end, lagvis tilnærming. Virtualisering av nettverksfunksjoner bryter den eksplisitte koblingen med spesifikt utstyr, derfor defineres tilgjengeligheten av tilgjengeligheten av VNF-tjenester. Fordi NFV-teknologi kan virtualisere et bredt spekter av nettverksfunksjonstyper, hver med sine egne forventninger om tjenestetilgjengelighet, bør NFV-plattformer støtte et bredt utvalg av feiltoleransealternativer. Denne fleksibiliteten gjør at CSP-er kan optimalisere NFV-løsningene for å oppfylle ethvert VNF-tilgjengelighetskrav.

Ledelse og orkestrering (MANO)

ETSI har allerede indikert at en viktig del av å kontrollere NFV-miljøet gjøres gjennom automatisering og orkestrering. Det er en egen strøm MANO innen NFV som skisserer hvordan fleksibilitet skal kontrolleres.

ETSI leverer et komplett sett med standarder som muliggjør et åpent økosystem hvor virtualiserte nettverksfunksjoner (VNF) kan være interoperable med uavhengig utviklede styrings- og orkestreringssystemer, og hvor komponentene i et administrasjons- og orkestrasjonssystem selv er interoperable. Dette inkluderer et sett med avslappende API- spesifikasjoner, samt spesifikasjonene for et emballasjeformat for levering av VNF-er til tjenesteleverandører og distribusjonsmaler som skal pakkes sammen med programvarebildene for å muliggjøre administrasjon av livssyklusen til VNF-er. Implementeringsmaler kan være basert på TOSCA eller YANG .

En OpenAPI (aka Swagger) representasjon av API-spesifikasjonene er tilgjengelig på ETSI forge- serveren , sammen med TOSCA- og YANG-definisjonsfiler som skal brukes når du lager distribusjonsmaler.

Hele settet med publiserte spesifikasjoner er oppsummert i tabellen nedenfor.

Spesifikasjon Tittel
ETSI GS NFV-SOL 001 NFV-deskriptorer basert på TOSCA-spesifikasjon
ETSI GS NFV-SOL 002 RESTful protokollspesifikasjon for Ve-Vnfm referansepunkt
ETSI GS NFV-SOL 003 RESTful protokollspesifikasjon for Or-Vnfm referansepunkt
ETSI GS NFV-SOL 004 VNF-pakke og PNFD-arkivspesifikasjon
ETSI GS NFV-SOL 005 RESTful protokollspesifikasjon for Os-Ma-nfvo referansepunkt
ETSI GS NFV-SOL 006 NFV-deskriptorer basert på YANG-spesifikasjon
ETSI GS NFV-SOL 007 Network Service Descriptor filstruktur spesifikasjon
ETSI GS NFV-SOL 009 RESTful protokollspesifikasjon for styring av NFV-MANO
ETSI GS NFV-SOL 010 VNF Snapshot Package spesifikasjon
ETSI GS NFV-SOL 011 RESTful protokollspesifikasjon for Or-Or referansepunkt
ETSI GS NFV-SOL 012 RESTful protokollspesifikasjon for Policy Management-grensesnittet
ETSI GS NFV-SOL 013 Spesifikasjon av vanlige aspekter for RESTful NFV MANO APIer
ETSI GS NFV-SOL 014 YAML datamodelspesifikasjon for deskriptorbasert virtualisert ressursadministrasjon
ETSI GS NFV-SOL 015 Spesifikasjon av mønstre og konvensjoner for RESTful NFV-MANO APIer
ETSI GS NFV-SOL 016 NFV-MANO prosedyrer spesifikasjon

En oversikt over de forskjellige versjonene av OpenAPI-representasjonene av NFV-MANO APIer er tilgjengelig på ETSI NFV- wiki .

OpenAPI-filene, samt TOSCA YAML-definisjonsfilene og YANG-modulene som gjelder NFV-deskriptorer, er tilgjengelige på ETSI Forge .

Prestasjonsstudie

Nylig ytelsesstudie på NFV fokuserte på gjennomstrømning, ventetid og jitter av virtualiserte nettverksfunksjoner (VNFer), samt NFV-skalerbarhet når det gjelder antall VNFer som en enkelt fysisk server kan støtte. Åpen kildekode NFV-plattformer er tilgjengelig, en representant er openNetVM. openNetVM er en høyytelses NFV-plattform basert på DPDK- og Docker-containere. openNetVM gir et fleksibelt rammeverk for distribusjon av nettverksfunksjoner og sammenkobling av dem for å bygge servicekjeder. openNetVM er en åpen kildekodeversjon av NetVM-plattformen beskrevet i NSDI 2014 og HotMiddlebox 2016-papirene, utgitt under BSD-lisensen. Kildekoden finner du på github: openNetVM

Cloud-Native Network Funksjoner

I 2018 begynte mange infrastrukturleverandører å migrere mange av sine VNF-er til en containerbasert arkitektur. Disse Cloud-Native Network Funksjonene bruker mange av de samme innovasjonene som ofte brukes på internettinfrastruktur. Disse inkluderer automatisk skalering, støtte en kontinuerlig leverings- / DevOps-distribusjonsmodell og effektivitetsgevinster ved å dele vanlige tjenester på tvers av plattformer. Gjennom oppdagelse og orkestrering av tjenester vil et system basert på CNF være mer motstandsdyktig mot nodefeil. Å bruke containere, og dermed dispensere med overhead iboende i tradisjonell virtualisering gjennom eliminering av gjeste-operativsystemet, kan øke ressurseffektiviteten.

Se også

Referanser

Eksterne linker