SDN - Grundlagen
Netzwerk sind gefühlt immer zu langsam aber Word, Excel und insbesondere Outlook (Cached Mode) sind relativ tolerant und dem Anwender fallen ein paar Sekunden nicht auf. VoIP mit Audio/Video und damit auch Lync ist empfindlicher, was Netzwerkengpässe betrifft.
Reicht CAC und QoS nicht ?
Wenn nicht "genug" Bandbreite zur Verfügung steht, dann muss ein Administrator den Mangel verwalten. Das kann er indem er per CAC die Anzahl und Bandbreite von Lync Audio/Video-Sitzungen über Netzwerklinks limitiert und auf der anderen Seite per QoS eben diese Bandbreite dann auch garantiert. Aber CAC und QoS sprechen nicht miteinander, so dass die Zuweisungen statisch sind. Ein Router kann Lync nicht sagen, dass er doch mehr Bandbreite nutzen könnte, wenn CAC es nur zulassen würde. Umgekehrt kann Lync keine weitergehenden Informationen an "das Netzwerk" über seine Bedürfnisse geben.
Besonders knifflig wird es, wenn eine Verbindung nur nur über einen WAN-Link geht, sondern über mehrere Stationen läuft und auf jedem Link andere QoS-Parameter gelten. Das ist nicht nur für Lync wichtig, sondern auch immer mehr Cloud-Anbieter versprechen ihren Kunden die günstige Bereitstellung von Diensten aber die Verbindung zwischen Kunde und Anbieter über das Internet ist alles andere als garantiert.
SDN kann hier helfen und intelligenter auf die Anforderungen reagieren. Es könnte aber im WAN auch ein Einstieg in eine unterschiedliche Preisgestaltung für Internet-Traffic sein, bei der nicht mehr nur die Bandbreite und das Volumen als solches bezahlt werden, sondern auch die verschiedenen Güteklassen unterscheidbar werden.
Besonders für QoS ist diese
Funktion interessant, da das Netzwerk die
Information bekommt, welche IP-Adressen und
Ports z.B.: Audio und Video übertragen. Über
diese Information kann der Switch z.B. dynamisch
angewiesen werden, genaue diese Verbindungen mit
einem anderen DSCP/QoS-Tagging zu versehen.
Es wird aber noch etwas dauern, bis die
Netzwerkherstelle entsprechende Schnittstellen
bereit stellen.
Software-Defined
Networking
https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-papers/wp-sdn-newnorm.pdf
Software-Defined Networking:
An Overview für unified Communications
http://channel9.msdn.com/events/TechEd/NorthAmerica/2014/OFC-B343
SDN Überblick
Die SDN-Funktion wurde nicht durch Microsoft entwickelt, aber Lync ist das erste Produkt, dass aktiv SDN-Funktionen enthält und unterstützt. SDN ist eine geschickte Kombination verschiedener Komponenten unterschiedlicher Hersteller. Nicht alle Hersteller unterstützen schon SDN und es sicher erst einmal für größere Firmen und WAN-Betreiber interessant. Ein grundlegendes Blockschaltbild sie wie folgt aus:
Am unteren Ende stehen die aktiven Netzwerkkomponenten wie Switche, Router, WiFi-Accesspoints aber auch Firewalls und alle anderen Geräte die Pakete weiterleiten und auf die Reihenfolge und Priorisierung Einfluss nehmen können.
Diese Geräte haben in der Regel eine proprietäre API, über die sie von einer Controller-Software gesteuert werden können. Die Schnittstelle zwischen Controller und Device wird als "Southbound API" bezeichnet. Der "OpenFlow"-Standard ist eine entsprechend API, auf die Hersteller aufsetzen können, um vielleicht doch einmal gegenseitig steuernd aktiv zu werden.
Die Controllersoftware wiederrum kann von ein oder mehreren Applikationen angesprochen werden. Über die als "Northbound"-API bezeichnete Schnittstelle teilen Anwendungen dem Controller mit, welche Verbindungen gerade aktiv sind und ggfls. priorisiert werden müssen. Sie sehen hier, dass Microsoft die aus Netzwerksicht "Applikation" genannte Komponenten seinerseits in die Funktion SDN - Lync Dialog Manager und SDN - Lync Dialog Listener aufgeteilt hat.
Sie können aber schon sehen, dass der Lync SDN Manager durchaus mehrere Controller auch unterschiedlicher Firmen bedienen kann und ein Controller auch von mehreren Applikationen Informationen erhalten kann. Nicht eingezeichnet ist aktuell, dass theoretisch auch ein Controller von Vendor A eine Netzwerkkomponente von Vendor B ansteuern könnte, zumindest wenn sie beide eine kompatible Schnittstelle besitzen. Über den OpenFlow-Standard sollte so etwas möglich sein.
Weitere Links
- SDN mit Lync
- SDN - Lync Dialog Listener
- SDN - Lync Dialog Manager
- SDN - Lync LDL2LDM
- Call Admission Control
- QoS
- Lync and Software-Defined
Networking
http://blogs.technet.com/b/lync/archive/2013/12/17/lync-and-software-defined-networking.aspx - Software-defined networking
http://de.wikipedia.org/wiki/Software-defined_networking - SDN, NFV & OpenFlow APIs and
SDKs
http://www.sdncentral.com/comprehensive-list-of-sdn-apis/ - SDN and Communications: A
Great Match
http://www.nojitter.com/post/240166256/sdn-and-communications-a-great-match/ - Northbound API, Southbound
API, East/North – LAN Navigation
in an OpenFlow World and an SDN
Compass
http://etherealmind.com/northbound-api-southbound-api-eastnorth-lan-navigation-in-an-openflow-world-and-an-sdn-compass/ - What are SDN Northbound APIs
https://www.sdxcentral.com/resources/sdn/north-bound-interfaces-api/ - Who is the Open Networking
Foundation (ONF)?
https://www.sdxcentral.com/resources/sdn/who-is-open-networking-foundation-onf/ - Northbound Interfaces
https://www.opennetworking.org/technical-communities/areas/services/1916-northbound-interfaces - OpenFlow
http://de.wikipedia.org/wiki/OpenFlow - Northbound API guide: The
new network application
http://searchsdn.techtarget.com/guides/Northbound-API-guide-The-rise-of-the-network-applications - KEMP Technologies Delivers
SDN Adaptive Load Balancing as
part of the HP Networking SDN
Ecosystem
http://kemptechnologies.com/de/news/kemp-technologies-delivers-sdn-adaptive-load-balancing-part-hp-networking-sdn-ecosystem/
Holt angeblich aus der Northbound API Daten um das beste Ziel zu ermitteln.