Neue Technologien: Software Defined Networking und Network

Transcrição

Unternehmensberatung
Netzwerke
UBN
Neue Technologien: Software Defined Networking
und Network Functions Virtualization
Dipl.-Inform. Petra Borowka-Gatzweiler
Netzwerke
UBN
Pascalstraße 25, 52076 Aachen
Tel.: 02408 / 955-500
[email protected]
© UBN Petra Borowka-Gatzweiler
Netzwerk Forum 2016: SDN und NFV - Seite 1
Netzwerke
UBN
Wo steht der SDN-Markt ?
Was ist NFV ?
Abgrenzung, Überlappung NFV / SDN
NFV und Network Services
Wo steht der NFV Markt ?
SDN Architektur v1.1 – Basis Modell
Netzwerke
UBN
 Ein Service
Consumer (Client,
User, Customer =
GRÜN) tauscht
sowohl Daten- als
auch Management-KontrollOperationen mit
einem SDN Server
oder Provider aus
(BLAU).
 Daten werden
durch Ressourcen
(R) weitergeleitet
und verarbeitet
 Obwohl der Provider die Ressourcen hält, kontrolliert der Consumer den Service
SDN Controller Architektur v1.1
Netzwerke
UBN
 Verabschiedet
von der ONF
Architektur WG
in 2016
 Zentrales
Element ist nach
wie vor der
Controller
 A-CPI ist ein
intentionales
Interface für NBI
(North Bound
Interface)
 Der Controller
selbst kann
Server oder
Client sein
Netzwerke
UBN
SDN Marktsegmente und Volumen
 Der weltweite SDN Markt gliedert sich (nach IDC) in




physische Netzwerk Infrastruktur
Virtualisierungs- / Kontroll-Software
SDN Applikationen inkl. Netzwerk- und Sicherheits-Dienste
Professionelle Dienste
 Jährliches Wachstum (CAGR) von 53,9 %
 Geschätztes Volumen von 12,5 Mrd. USD in 2020
(d.h. 2,3 Mrd. USD in 2016)
 (Vergleich: Geschätztes Volumen des SIP Trunking Marktes 2018
liegt nach Frost & Sullivan bei 9,35 Mrd. USD)
Quelle: "SDN Market to Gain Enterprise Headway, Driven by 3rd Platform and Cloud"; IDC Februar 2016
Netzwerke
UBN
SDN Interfaces
North Bound Interface (NBI)
 Arbeitsgruppe der ONF (2013): Schnittstellen mit unterschiedlich tiefgehenden
Netzwerk-Informationen
 Applikationen = High Level
 Load Balancer, Firewall = detaillierterer Low Level
 Kompromiss: "Intent-based" statt "prescriptive" Interface
 Pragmatische Implementierungen: ODL (Open Daylight), ONOS (Open Network
Operating System)
Southbound Interface Alternativen
 Border Gateway Protocol (BGP)
 NETCONF
 Extensible Messaging and Presence Protocol (XMPP)
 Open vSwitch Database Management Protocol (OVSDB)
 MPLS Transport Profile (MPLS-TP)
 Konsens OpenFlow Switch Specification v1.3.4 (v1.5.1 April 2015)
OpenDaylight: Pragmatisch und agnostisch
OpenSource SDN Plattform: Release 3 = Lithium (Juni 2015)
Netzwerke
UBN
Quelle: www.opendaylight.org/lithium
Wo steht SDN in der praktischen Implementierung ?
Netzwerke
UBN
Stand der SDN Implementierung
Prozent
Wir haben SDN noch nicht analysiert
Wir werden SDN wahrscheinlich im Laufe von 2016 analysieren
Wir analysieren aktuell aktiv den potenziellen Mehrwert von SDN
Wir erwarten, dass SDN bei uns innerhalb von 1 Jahr entweder im Labor
oder in einem limitierten Feldversuch läuft
Wir analysieren aktuell aktiv SDN Strategie und Angebote der Hersteller
SDN läuft bei uns aktuell entweder im Labor oder in einem limitierten
Feldversuch
Wir fahren SDN aktuell in einem Teil unseres Produktivnetzwerks
Wir haben SDN evaluiert und entschieden, im nächsten Jahr noch nichts
weiter mit SDN zu tun
Wir erwarten, dass SDN innerhalb von 1 Jahr in einem Teil unseres
Produktivnetzes läuft
Weiß nicht / andere Positionierungen
14%
19%
33%
17%
29%
15%
9%
9%
12%
9%
sdn-nfv2016.xlsx
 Nur 9 Prozent der Befragten gaben an, SDN aktuell teilweise produktiv zu nutzen,
weitere 15 Prozent fahren einen Piloten
SDN im Data Center (1)
Netzwerke
UBN
Gründe für SDN im Data Center
Prozent
Unterstützung der dynamischen Migration, Replikation und Bereitstellung von
Ressourcen
Leichtere Administration von Konfiguration und Provisionierung
Bessere Ausnutzung von Netzwerk Ressourcen
Traffic Engineering mit einer Ende-zu-Ende Sicht des Netzwerks durchführen
zu können
Netzwerk-Funktionalität leichter skalieren
OPEX Reduzierung
Schnellere Weiterentwicklung der Netzwerk-Funktionalität auf Basis eines
Software Lifecycle
CAPEX Reduzierung
Anwendungen dazu befähigen, Dienste vom Netzwerk dynamisch
anzufordern
Sicherheits-Funktionalität wirksamer implementieren
Komplexität reduzieren
QoS leichter implementieren
sdn-nfv2016.xlsx
39%
36%
22%
18%
16%
14%
12%
11%
11%
9%
7%
4%
Quelle: The 2016 Guide to SDN and NFV, Metzler e.a.
Netzwerke
UBN
SDN im Data Center (2)
Gründe gegen SDN im Data Center
Prozent
Bedenken hinsichtlich der SDN Integration mit der restlichen
Infrastruktur
Fehlender Reifegrad der SDN Technologien
Unklarheiten und Definitionslücken bei den Herstellerstrategien
Andere Technologie / Geschäfts-Prioritäten
Es fehlt ein zwingender Geschäftsgrund
Mögliche Sicherheitslücken
Bedenken hinsichtlich der Managebarkeit von SDN
Fehlen einer kritische Masse von (Unternehmen mit) SDN
Implementierungen
Es gibt keine SDN Hindernisse
Bedenken, dass die Skalierung nicht für Enterprise Netzgröße
ausreicht
Andere Gründe
30%
28%
23%
20%
17%
15%
12%
8%
7%
6%
4%
sdn-nfv2016.xlsx
Marktführer für SDN im Data Center
Netzwerke
UBN
 Cisco Systems (ACI, > 1000 Kunden)
 Vmware (NSX, > 1000 Kunden)
 Huawei
 Hewlett Packard Enterprise (6000 VAN SDN Controller Downloads)
 Juniper Networks (Akquisition des SDN Startup Contrail)
 Cumulus (SDN Linux Software Switches)
 NEC (ProgrammableFlow Controller, > 250 Kunden)
 Nuage Networks Virtualized Services Platform (ALE OEM, HPE Helion OpenStack
2.0)
 Brocade (kommerzieller ODL Vertrieb)
 Broadcom (BroadView)
Quelle: "Data Center and Enterprise SDN Vendor Leadership Analysis Report"; IHS, Februar 2016
Netzwerke
UBN
Wo steht der SDN Markt ?
 SDN eine "kommende Technologie" und wird auch noch mindestens ein bis zwei
Jahre in diesem Status verharren
 Die existierenden Open Source Projekte können die SDN-Akzeptanz beschleunigen
 Das Overlay Modell (Hypervisor Tunnel) hat mehr Befürworter als das Underlay
Modell (SDN Fabric)
 ONOS ist zwar Teil der Linux Foundation, zielt aber auf Service Provider
 ODL's Lithium (= Version 3) hat eine vergleichsweise umfangreiche Funktionalität
 Das Hauptinteresse für SDN-Implementierungen liegt im Data Center Umfeld
(51%), an zweiter Stelle rangiert das WAN (31%), an dritter Stelle LAN (22%)
 Hauptfaktoren für eine SDN-Impelmentierung sind Administrations- und
Konfigurations-Erleichterungen sowie bessere Ressourcen-Nutzung (nicht: CAPEXund Komplexitäts-Reduzierung !)
 Hauptsächliche Hinderungsgründe: Bedenken hinsichtlich SDN-Integration mit der
restlichen Infrastruktur, Sicherheits-Bedenken, zwingender Geschäftsgrund fehlt
 OpenFlow hat bislang nur sehr geringe Verbreitung gefunden
Netzwerke
UBN
Was ist NFV ?
Netzwerke
UBN
NFV = Network Function Virtualization (1)
Vision: Netzwerke von proprietären Boxen zu einer Ansammlung von Software-Komponenten
überführen, die auf Industriestandard-Hardware (COTS) laufen
 Betroffene Komponenten







Router, Layer-3 Switches
Load Balancer, WAN-Beschleuniger
Deep Packet Inspection (DPI) Komponenten, Firewalls, NAT-Boxen, SBCs
Test- und Monitoring Komponenten
WLAN Controller
CDN Appliances
Controller für Mobilnetz-Basisstationen, Mobilnetz Packet Gateways
 Januar 2013: Standardisierungs-Gremium: ETSI ISG (Industry Specification Group) NFV konstituiert
sich
 Unter Mitarbeit von weltweit ca. 230+ Unternehmen eine Reihe Technischer Spezifikationen
 September 2014: Linux Foundation legt ein Projekt "Open Platform for NFV" auf (OPNFV),
entwickelt NFV Referenz-Plattform auf der Basis der ETSI-Spezifikationen
 IETF: Arbeitsgruppe SFC zum Thema Service Function Chaining (konkurrierend ?)
 In der Praxis besteht eine NFV Lösung in der Regel aus drei Kernelementen: COTS Hardware,
einem Hypervisor wie KVM oder ESXi, einer Cloud Management Lösung wie OpenStack oder
VMware vSphere.
NFV = Network Function Virtualization (2)
Netzwerke
UBN
 Nicht-virtualisierte Netze: Netzwerk-Funktionen (NFs) sind als Kombination
herstellerspezifischer Hard- und Software implementiert
 Komponenten sind Netzknoten (NN Network Node) oder Netzwerk-Element (NE)
 Insbesondere im Providerumfeld angestrebte Verbesserungen durch NFV im
Vergleich zu heutigen Hardware-Netzen:
 Entkopplung der Hardware von der Software, so dass beide unabhängig voneinander
weiterentwickelt werden können
 flexibles Deployment: Neuzuweisung von Ressourcen und Ressourcen-Sharing bei
Ressourcen-Poolsdurch Software /Hardware Entkopplung
 bessere Automatisierung der aktuellen Instanziierung einer Software
 dynamischer Betrieb durch Bedarfs-Instanziierung einer VNF-Software, somit bessere
und granularere Skalierungs-Möglichkeiten, abhängig von der jeweiligen Verkehrslast
 Die Architektur besteht aus zwei funktionalen Blöcken
 virtualisierte Netzwerk-Funktionen (VNFs)
 NFV Infrastruktur (NFVI)
 Nebengeordnet: Mangement- und Orchestrierungs-Block
Netzwerke
UBN
NFV Architektur-Übersicht
OSS / BSS
VNF
EM 1
EM 2
EM 3
VNF 1
VNF 2
VNF 3
Virtueller Server
Virtueller Speicher
Virtuelles Netzwerk
VNF
Manager
NFVI
Virtualisierter
Infrastruktur
Manager
Virtualisierungs-Schicht (Virtualisation Layer)
Hardware Ressourcen
nfv03.vsd
Quelle: ETSI: Network Functions Virtualisation (NFV) White Paper 2, 10/2013
Orchestrierung
Netzdienst-, VNF
& InfrastrukturBeschreibung
Server
Hardware
Speicher
Hardware
Netzwerk
Hardware
NFV M&O
Der NFVI Block
Netzwerke
UBN
 Network Function Virtualisation Infrastructure deckt die Gesamtheit der Hardwareund Software-Komponenten einer VNF Umgebung ab
 Stellt die virtuellen Ressourcen bereit, die zur Ausführung der VNFs (Virtual
Network Functions) erforderlich sind.
 Besteht grundsätzlich aus drei Sub-Schichten:
 Virtuelle Komponenten
 Virtualisierungs-Schicht
 Hardware Ressourcen
 Kernstück Virtualisierungs-Schicht, verantwortlich für drei Funktionsbereiche:
 Abstraktion und logische Partitionierung der physischen Ressourcen
 Software, die eine NFV implementiert, dazu befähigen, die unterliegende NFVI zu nutzen
 Bereitstellung von virtualisierten Ressourcen für die VNF, die die VNF zur Ausführung
benötigt
 Keine Vorgabe bestimmter Virtualisierungs-Layer Lösungen durch die NFV
Architektur; stattdessen Erwartung, dass eine vorhandene Lösung StandardFeatures und Referenzpunkte (Execution Reference Points) in Richtung VNFs
und Hardware nutzt
Der VNF Block
Netzwerke
UBN
 Software-Implementierung von Netzwerk-Funktionen, die NFVI unterstützen
 Eine VNF kann aus mehreren internen Komponenten zusammengesetzt sein
(Composition) und so über mehrere VMs verteilt implementiert werden.
 Eine oder mehrere VNFs können zusammen mit einem Element Manger (EM)
implementiert sein, soweit dies für spezielle Besonderheiten dieser VNF(s)
erforderlich ist.
 Die VNF hat Dienst-Attribute wie






Zuverlässigkeit
Verfügbarkeit
Managebarkeit
Sicherheit
Leistung
bei einer Composite VNF ergeben sich diese Attribute aus der Summe der Attribute der
einzelnen Unter-VNFs
 Insgesamt wird unterstellt, dass das funktionale Verhalten und die externen
operationalen Schnittstellen einer physischen Netzwerkfunktion (PNF) und
einer VNF identisch sind
Der MANO Block
Netzwerke
UBN
 Deckt die Orchestrierung und das Lifecycle Management der VNFs sowie der
physischen und Software Ressourcen ab, die die Infrastruktur-Virtualisierung
unterstützen
 MANO fokussiert sich auf die virtualisierungs-spezifischen ManagementAufgaben des NFV Frameworks
 MANO interagiert mit den OSS/BSS Tools zur Integration in die allgemeine
Mangement-Landschaft
 Der M&O Block ist analog zu den Funktionsblöcken hierarchisch unterteilt
 Orchestrierung
 darunter VNF Manager (einer oder mehrere) für die Handhabung der VNFs
 darunter Virtualisierter Infrastruktur Manager für die Handhabung virtualisierter Ressourcen
Netzwerk-Dienste in NFV
Netzwerke
UBN
 Ein Netzwerk-Dienst kann architekturmäßig als ein Weiterleitungs-Graph (FG) von
Netzwerk-Funktionen (NFs) betrachtet werden
 Verbindung durch die unterliegende Netzwerk-Infrastruktur
 Jede einzelne NF trägt zur Gesamtfunktion des Netzwerk-Dienstes bei, d.h.
 Der Ende-zu-Ende Dienst ist eine Kombination der einzelnen funktionalen Blöcke
 die Einzel-NFs
 zusammengesetzte NFs
 NF-Gruppen
 Ein NF-Forwarding Graph kann Netzknoten beinhalten, die durch logische,
unidirektionale, bidirektionale oder Broadcast Links angebunden sind.
 In jedem Fall enthält der NF-Forwarding Graph an beiden Enden die Endsysteme,
zwischen denen der Dienst geleistet wird (End Node)
 Einfaches Beispiel: Kette von Netzwerk-Funktionen (Service Chain), wie zum
Beispiel Ende-zu-Ende Dienst zwischen Smartphone und CDN-Server Pool, der
über ein Wireless Netz, eine DPI-Komponente, einen Firewall und einen Load
Balancer verläuft
Netzwerk-Dienst Beispiel: Smartphone und CDN Server
 End Point A
ist das
Smartphone
Firewall
 NF1 ist der
DPI
DPI
Load Balancer
PoP-Netz
nfv04.vsd
CDN-Server
Pool
Netzwerke
UBN
 NF2 ist der
Firewall
 NF3 ist der
Load
Balancer
 End Point B
ist der CDNServer Pool
Netzwerk-Dienst Beispiel: Forwarding Graph
Netzwerke
UBN
Ende-zu-Ende Netzwerk-Dienst
Network Function (NF) Forwarding Graph
nfv05.vsd
Endpunkt A
NFV 1
Infrastruktur
Netzwerk 1
NFV 2
Infrastruktur
Netzwerk 2
Endpunkt B
NFV 3
Infrastruktur
Netzwerk 3
 Zugehöriger Forwarding Graph zum Ende-zu-Ende Netzwerk-Dienst
Netzwerke
UBN
Netzwerk-Dienst Beispiel: VNF Forwarding Graph
Ende-zu-Ende Netzwerk-Dienst
 Zugehöriger VNF
Forwarding Graph
VNF-FG-2
korrespondierender
VNF-FG zum NF
Forwarding Graph
in Abbildung 2.4
VNF-2B
VNF-2A
VNF-3
VNF-1
Endpunkt A
VNF-2C
Endpunkt B
nfv06.vsd
 VirtualisierungsLayer gehört zur
VNFI (Pfeil
"Virtualisierung")
Vitualisation Layer
NFVI-PoP
Physischer Link
Logischer Link
Virtualisierung
 Ressourcen für
Server, Speicher
und Netzwerk
sind in den NFVIPoPs enthalten
Hardware
Ressourcen in
physischen
Lokationen
 Virtualisierte
NetzwerkFunktionen laufen
oberhalb des
VirtualisierungsLayer ab
NFV Einsatzszenarien
Netzwerke
UBN
 Infrastruktur als Dienstleistung (IaaS)
 Virtuelle Netzwerk-Funktion als Dienstleistung (VNFaaS)
 Virtuelle Netzwerk-Plattform als Dienstleistung (VNPaaS)
 VNF Forwarding Graphen
 Virtualisierung des Mobilfunk Core Netzwerks und des IMS
 Virtualisierung der Mobilfunk-Basisstation
 Virtualisierung der Home Umgebung
 Virtualisierung von CDNs (vCDN)
 Virtualisierung der Netzwerk-Funktionen für den Festnetz-Zugang (Last Mile / DSL)
Quelle: "NFV 001: NFV; Use Cases"; ETSI
Netzwerke
UBN
Was ist NFV ?
Der Zusammenhang zwischen SDN und NFV (1)
Netzwerke
UBN
Zusammenhang zwischen SDN und NFV
Prozent
Es sind total verschiedene Aktivitäten
Es sind komplementäre Aktivitäten dergestalt, dass jede ohne die andere auskommen
kann, aber jede den Mehrwert der anderen vergrößern kann
In mindestens einigen Fällen erfordert NFV SDN
In mindestens einigen Fällen erfordert SDN NFV
Weiß nicht
8%
65%
17%
12%
18%
sdn-nfv2016.xlsx
 Ursprünglich waren SDN und NFV separate Initiativen, die sich unabhängig voneinander
entwickeln sollten
 2014 haben ONF und ETSI NFV ISG ein MOU (Memorandum of Understanding)
verabschiedet
 " Die Organisationen werden gemeinsam die Anwendung von SDN Konfigurations- und
Kontroll-Protokollen erforschen, als Basis einer Netzwerk-Infrastruktur, die NFV
unterstützt; und ebenso umgekehrt die Möglichkeiten, die NFV zur Virtualisierung der
Forwarding Plane Funktionen eröffnet"
 Ein ETSI Whitepaper erklärt, dass NFV und SDN weitgehend komplementäre
Bestrebungen sind
Der Zusammenhang zwischen SDN und NFV (2)
Netzwerke
UBN
ETSI Beispiele für die NFV und SDN Komplementarität
 Der SDN Controller passt gut in das breitere Konzept des Netzwerk Controllers in
einer NFV-Infrastruktur (NFVI)
 SDN kann sowohl physisch als auch virtuell eine wichtige Rolle in der
Orchestrierung der NFVI Ressourcen spielen, indem es für Provisionierung,
Konfiguration der Netzwerk-Konnektivität, Bandbreiten-Bereitstellung,
Automatisierung von Monitoring, Sicherheitsregeln und Policy Kontrolle genutzt wird
 SDN kann die Netzwerk-Virtualisierung bereitstellen, die für mandantenfähige
NFVIs benötigt wird
 Forwarding Graphen können mit einem SDN Controller implementiert werden, der
automatisiertes Service Chaining bei gleichzeitig starker und konsistenter
Sicherheits-Implementierung bereitstellt
 Der SDN Controller kann als VNF betrieben werden; er ist dann selbst Teil einer
Service-Kette, die auch noch andere VNFs enthält 
 D.h. Anwendungen und Dienste, die ursprünglich den SDN Controller benötigten,
können ebenso als separate VNFs implementiert werden
Netzwerke
UBN
Zwischenfazit: SDN und NFV
 SDN und NFV werden meistens für komplementäre Technologien
gehalten, die "irgendwie" zusammenhängen
 Viele Unternehmen haben keine gut durchdachte Strategie, wie
die Orchestrierung von SDN und NFV implementiert werden soll
 SDN und NFV bieten Management Verbesserungen auf der einen,
jedoch Sicherheits-Herausforderungen auf der anderen Seite
 SDN und NFV wird durchaus Potenzial zugetraut, IT Organisationen, ihre dynamische
Umgebungs-Änderungen zu ermöglichen, um SLAs gerecht zu werden
 Voraussetzung: Applikationen und Dienste müssen Ende-zu-Ende eingerichtet werden
(können)
 Anforderung: Unabhängige Einrichtung von physischen und virtuellen Umgebungen;
 Netzwerk-Management Organisationen sollen jedoch beide Management-Datasets
korrelieren und konsolidieren können, insbesondere operationeller Einblick in die
Ende-zu-Ende Dienstqualität ist erforderlich
 SDN und NFV und fortschreitende Adaption software-basierter IT Funktionalität werden
die Struktur von IT-Organisationen sowie die IT-Arbeitsplätze nachhaltig verändern
Netzwerke
UBN
Was ist NFV ?
Netzwerke
UBN
Technologien: Service Chaining
 Wichtige bis kritische Layer-4-7 Dienste sind auf dem Weg in die Virtualisierung
 Typischerweise komplexere, "Composite" Dienste mit hohen operativen Kosten
 Server Load Balancing (SLB)
 Intrusion Detection / Protection System (IDS, IPS)
 Firewall (FW)
 Diese Dienste werden oft in einer festgelegten Reihenfolge durchlaufen, z.B.
FW2  IPS12  SLB5
 1:N Beziehung zwischen Service Chain und Service Path
 Neu: Anstelle von statischen Appliances sind Service Funktionen jetzt flexible
Ressourcen mit Attributen, die entsprechend der Scheduling Reihenfolge assoziiert
werden
 Notwendige Policy Informationen hierfür werden als Metadaten übertragen
 Umsetzung: Data Plane Header, um eine dedizierte Service Plane zu generieren
 Cisco / IETF: NSH Network Services Header (Draft 05, Jan. 2015)
 Basis-Enkapsulierung: beliebig, z.B. VXLAN, VXLAN GPE, GRE, NVGRE, LISP, …
Netzwerke
UBN
Service Chaining: NSH Header (1)
32 Bit
0
31
Transport
Enhapsulierung
Ver
Basis Header
Mandatory Context Header
=
Netzwerk Plattform Kontext (4 Byte)
=
Netzwerk Shared Kontext (4 Byte)
= Service Plattform Kontext (4 Byte)
= Netzwerk Shared Kontext (4 Byte)
Optionale
Context Header,
variable Länge
nsh01.vsd
Länge
MD Type
TLV Klasse
Next Protocol
Service Index
Flow ID(SI)
Service Path Information (SPI)
Service Path Header
NSH Header
0 C R R R R R R
Typ
R R R
10
Länge
Variable Metadaten
 SPI: Service Path Information definiert die durchzuführende Service Aktion
 SI: Service Index entspricht "TTL", gibt die Anzahl noch auszuführender Dienste an
Netzwerke
UBN
Service Chaining: NSH Header (2)
 O = OAM Bit
 C = Critical Metadata TLV
 Länge = Anzahl 4-Byte Worte des gesamten NSH (muss ≥ 6 sein)
 Next Protocol
 0x1 = IPv4
 0x2 = IPv6
 0x3 = Ethernet
 MD Typ (Metadaten): definiert das NSH Format, das auf den Basis-Header folgt
sowie den Typ der transportierten Metadaten
 0x1 für NSH Basis-Header mit 4 fixen Context Headern
 0x2 für NSH Header mit Context Headern variabler Länge
 SPI = Service Path Information
 SI = Lokation im Pfad (  TTL), wird nach Dienst-Ausführung beendet /
heruntergezählt
Netzwerke
UBN
NSH Einsatzbeispiel (1)
SDN Controller
Plattform
1
1
Service Classifier
2
KlassifizierungsPolicy
3
SF1
SF2
4
6
(v) TOR1
(v) TOR2
5
Paket
7
Paket
nsh02.vsd
VXLAN: D-IP
NSH: SPI: 10, SI:2
C1: User
C2: Application
Paket
VXLAN: D-IP
NSH: SPI: 10, SI:1
C1: User
C2: Application
Paket
Netzwerke
UBN
1
Klassifizierungs Policy
Klassifizierungs Policy
User1:
If Application1 
Permit AND set C3: Rate-Limit
If User1 AND Application1
AND Rate-Limit 
enforce Limit
2
SF1
SF2
3
5
(v) TOR1
(v) TOR2
4
6
Paket
Paket
nsh03.vsd
VXLAN: D-IP
NSH: SPI: 10, SI:2
C1: User1
C2: Application1
Paket
VXLAN: D-IP
NSH: SPI: 10, SI:1
C1: User
C2: Application
C3: Rate-Limit
Paket
Netzwerke
UBN
1. Eine SDN Controller Plattform ist für die Konfiguration der Klassifizierungs-Policies verantwortlich,
die mit einer bestimmten Service Chain assoziiert werden. Jedes Netzwerk Element, das in den
Service Pfad involviert ist, wird entsprechend provisioniert (z.B. mit OpenFlow, PCRF,
NETCONF/YANG oder direkter Geräte-Programmierung [!])
2. NSH wird in die Pakete eingefügt, die einen Klassifizierungs-Match ergeben; im Beispiel wird SPI
10 und SI 2 am Ingress Service Classifiert eingefügt
3. Basierend auf der SPI/SI Information wird ein Lookup durchgeführt und die entsprechende
Transport Enkapsulierung angewendet (im Beispiel VXLAN). Das Paket wird zum ToR Switch
gesendet, der die Konnektivität zur ersten Service Funktion leistet.
Im Beispiel wird sowohl die Applikation als auch der Nutzer durch die Klassifikation identifiziert;
beides wird in die NSH Kontext-Header eingetragen
4. Der ToR Switch entfernt den Transport Enkaps. Header, interpretiert NSH via SPI/SI und sendet
das Paket an die erste Service Funktion (SF1, z.B. Policy Enforcement); das SI Feld wird
aktualisiert
5. Nach SF1 wird das Paket an den ToR Switch zurückgesendet, der die nächste Service Funktion
identifiziert (SF2, z.B. Traffic Shaper, konkret Ratenlimitierung)
6. der ToR Switch sendet das Paket an das entsprechende Service Element (SF2)
7. Nach Durchführung der letzten Service Funktion wird das Paket zum endgültigen Empfänger
weitergeleitet
Netzwerke
UBN
Was ist NFV ?
Wo steht NFV in der praktischen Implementierung ?
Netzwerke
UBN
Stand der NFV Implementierung
Prozent
Wir analysieren aktuell aktiv den potenziellen Mehrwert von NFV
Wir werden NFV wahrscheinlich im Laufe von 2016 analysieren
Wir analysieren aktuell aktiv NFV Strategie und Angebote der Hersteller
SDN läuft bei uns aktuell entweder im Labor oder in einem limitierten
Feldversuch
Wir haben SDN noch nicht analysiert
Wir erwarten, dass SDN bei uns innerhalb von 1 Jahr entweder im Labor
oder in einem limitierten Feldversuch läuft
Wir fahren SDN aktuell in einem Teil unseres Produktivnetzwerks
Wir haben SDN evaluiert und entschieden, im nächsten Jahr noch nichts
weiter mit SDN zu tun
Wir erwarten, dass SDN innerhalb von 1 Jahr in einem Teil unseres
Produktivnetzes läuft
Weiß nicht / andere Positionierungen
25%
24%
23%
18%
18%
17%
14%
8%
7%
7%
sdn-nfv2016.xlsx
 Nur 14 Prozent der Befragten gaben an, NFV aktuell teilweise produktiv zu nutzen,
weitere 18 Prozent fahren einen Piloten
Wo steht der NFV Markt ? (1)
Netzwerke
UBN
 Die Hälfte der IT Mitarbeiter glaubt, dass NFV relevant oder sehr relevant für
Enterprise IT Architekturen ist
 Nur die wenigsten halten SDN und NFV für unabhängig voneinander
 Viele Unternehmen analysieren NFV aktuell, implementiert ist es bei wenigen
 Zwei Drittel der Unternehmen haben mit ihrer geplanten NFV Architektur keine
Fortschritte gemacht
 Haupttreiber für Interesse an NFV ist die erhoffte Zeiteinsparung, um neue Dienste
auszurollen
 Haupthindernisse für NFV sind:






das Fehlen eines zwingenden Business Case
Bedenken über die tatsächliche Ende-zu-Ende Provisionierung
Sicherheitsbedenken
fehlende Produktreife aktueller Produkte
erforderlicher Know How Aufbau
Management Herausforderungen
Wo steht der NFV Markt ? (2)
Netzwerke
UBN
 Etwa ein Drittel der IT Unternehmen glaubt, dass NFV in den nächsten 2 Jahren
einen signifikanten Einfluss auf ihr Unternehmen haben wird
 NFV ermöglicht neue HA-Konzepte
 Sofern VNF's zum Einsatz kommen, sollte auf Modularität geachtet werden
Fazit
Netzwerke
UBN
SDN und NFV sind Technologien, die aktuell vom
Markt nur schleppend akzeptiert werden
Handlungsbedarf besteht für Evaluierungen und die
Erarbeitung einer Strategie.
Noch ist jedoch unsicher, in welchem Umfang, wie
schnell und wie dauerhaft einzelne Lösungen sich
im Markt durchsetzen werden.
Die Standardisierung tut sich schwer und etabliert
sich eher im Rahmen von Industrie-Standards.
Abkürzungen
ACI
A-CPI
ALE
ANSI
API
BGP
BSS
CAGR
CAPEX
CBI
CDMA
CDN
CES
COTS
CPU
DC
D-CPI
DPI
DSL
EDGE
EM
ETSI
FG
FW
GRE
HA
HPE
HTML
IaaS
ID
IDC
IEEE
IETF
IDS
IM
Netzwerke
UBN
Application Centric Infrastructure (Cisco
Applications-Controller Plane Interface
Alcatel Lucent Enterprise
American National Standards Institute
Applications Programming Interface
Border Gateway Protocol
Business Support System
Compound Annual Growth Rate
CAPital EXpenditure
Computer-Brain Interface
Code Division Multiple Access
Content Delivery Network
Consumer Electronics Show
Commercial-Of-The-Shelf
Central Processing Unit
Data Center
Data-controller plane interface
Deep Packet Inspection
Digital Subscriber Line
Enhanced Data Rates for GSM Evolution
Element Manager
Euopean Telecommunications Standards Institute
Forwarding Graph
Firewall
Generic Routing Encapsulation
High Availiability
Hewlett Packard Enterprise
Hypertext Markup Language
Infrastructure as a Service
Identifikator
International Data Corporation
Institute of Electrical and Electronics Engineers
Internet Engineering Task Force
Intrusion Detection System
Instant Messaging
Abkürzungen
IMS
IP
IPS
ISG
IT
ITU
ITU-T
L2/L3
LACP
LAG
LAN
LB
LISP
LTE
M&O
MAC
MANO
MC
MC-LAG
MOU
MP
MPLS
MPLS-TP
NAC
NAT
NBI
NE
NETCONF
NF
NFV
NFVI
NIC
NN
NSH
NVGRE
ODL
OEM
OF
Netzwerke
UBN
IP Multimedia Subsystem
Internet Protocol
Intrusion Protection System
Industry Specification Group (ETSI)
Informations-Technologie
International Telecommunications Union
International Telecommunications Union – Telecommunication Standards
Layer-2/ Layer-3
Ling Aggregation Control Protocol
Link Aggregation Group (IEEE 802.3ad)
Local Area Network
Load Balancing
Locator/ID Separation Protocol
Long Term Evolution
Management and Orchestration
Media Access Control
Management and Orchestration
Multicast
Multi-Chassis Link Aggregation Group
Memorandum of Understanding
Multiprotocol / Multipath
Multi Protocol Label Switching
MPLS Transport Profile
Network Access Control
Network Address Translation
Northbound Interface
Network Element
Network Configuration
Network Function
Network Function Virtualisation
NFV Infrastruktur
Network Interface Card (Coupler)
Network Node
Network Services Header
Network Virtualization using Generic Routing Encapsulation
OpenDaylight
Open Equipment Manufacturer
OpenFlow
Abkürzungen
OFDM
ONF
ONOS
OPEX
OPNFV
OSPF
OSS
OVS
OVSDB
PAN
PoC
PC
PCRF
PSU
PYANG
QoS
REST
RFC
RMON
RZ
SBC
SDN
SFC
SI
SIP
SLA
SPB
SPBM
SPBV
SPI
TE
TLV
TRILL
TTP
UC
UMTS
Netzwerke
UBN
Orthogonal Frequency-Division Multiplexing
Open Networking Foundation
Open Network Operating System
OPerational EXpenditure
Open Platform for NFV Projekt
Open Shortest Path First
Operations Support System
Open Virtual Switch
Open vSwitch Database Management Protocol
Personal Area Network
Proof of Concept
Personal Computer
Policy an Charging Rules Function
Power Supply Unit
in Python geschriebenes YANG
Quality of Service
Representational State Transfer
Request For Comment; TCP/IP Standard-Dokument
Remote Network Monitoring MIB (SNMP)
Rechenzentrum
Session Border Controller
Software-Defined Networking
Service Function Chaining
Service Index
Session Initiation Protocol
Service Level Agreement
Shortest Path Bridging
Shortest Path Bridging MAC
Shortest Path Bridging VID
Service Path Information
Traffic Engineering
Type – Lenth – Value
TRansparent Interconnection of Lots of Links
Table Type Patterns (OpenFlow)
Unified Communications
Universal Mobile Telecommunications System
Abkürzungen
VID
vLAG
VLAN
VM
VNF
VNI
VSL
VSS
VXLAN
VXLAN GPE
W
WAN
W-CDMA
WG
WiMAX
WLAN
XMPP
YANG
Netzwerke
UBN
VLAN ID
Virtual Link Aggregation Group
Virtual Local Area Network
Virtual Machine
Virtual Network Function
VXLAN Network Identifier
Virtual Switch Link (Cisco)
Virtual Switching System
Virtual Extensible VLAN
Generic Protocol Extension for VXLAN
Watt
Wide Area Network
Wideband Code Division Multiple Access
Working Group
Worldwide Interoperability for Microwave Access
Wireless LAN
Extensible Messaging and Presence Protocol
Yet Another Next Generation

Neue Technologien: Software Defined Networking und Network

Transcrição

Documentos relacionados

14. Juli 2015 / Nr. 108 Jugend trainert für Olympia

Ferien- Fußball- Camp 2016

Einladung zum NFV-BEACHSOCCER CUP im Nettebad Osnabrück

24. Juli 2014 / Nr. 124 Jugend trainert für Olympia: Gymnasium

29. Februar 2016 / Nr. 42 12. Krombacher Ü 40

Ein starkEs stück LEbEn - Niedersächsischer Fußballverband eV

Anschriftenverzeichnis der Hildesheimer

am Leben - sdn Soziale Dienste Nordhorn

Aktuelles über SAP Master Data Management

Niedersächsischer Fußballverband Heidekreis Spielausschuss