Content deleted Content added
Revision deleted multiple references. Revision deleted a whole section created years ago. Reason provided does not match the edit. Possibly the reverted edit was a mistake. |
Citation bot (talk | contribs) Add: article-number, bibcode. Removed URL that duplicated identifier. Removed parameters. Some additions/deletions were parameter name changes. | Use this bot. Report bugs. | Suggested by Headbomb | Linked from Wikipedia:WikiProject_Academic_Journals/Journals_cited_by_Wikipedia/Sandbox | #UCB_webform_linked 499/967 |
||
| (34 intermediate revisions by 16 users not shown) | |||
Line 7:
}}
'''Software-defined networking''' ('''SDN''') is an approach to [[network management]] that uses abstraction to enable dynamic and programmatically efficient network configuration to create grouping and segmentation while improving network performance and monitoring in a manner more akin to [[cloud computing]] than to traditional network management.<ref name="ReferenceA">{{Cite journal | doi=10.1002/sec.1737|title = Software-defined networking (SDN): A survey| journal=Security and Communication Networks| volume=9| issue=18| pages=5803–5833|year = 2016|last1 = Benzekki|first1 = Kamal| last2=El Fergougui| first2=Abdeslam| last3=Elbelrhiti Elalaoui| first3=Abdelbaki}}</ref> SDN is meant to improve the static architecture of traditional networks and may be employed to centralize network intelligence in one network component by disassociating the forwarding process of [[network packet]]s ([[data plane]]) from the routing process ([[control plane]]).<ref>{{Cite journal|last=Montazerolghaem|first=Ahmadreza|date=2020-07-13|title=Software-defined load-balanced data center: design, implementation and performance analysis|url=http://link.springer.com/10.1007/s10586-020-03134-x|journal=Cluster Computing|volume=24|issue=2|pages=591–610|language=en|doi=10.1007/s10586-020-03134-x|s2cid=220490312|issn=1386-7857}}</ref> The control plane consists of one or more controllers, which are considered the brains of the SDN network, where the whole intelligence is incorporated. However, centralization has certain drawbacks related to security,<ref name="ReferenceA"/> scalability and elasticity.<ref name="ReferenceA"/><ref>{{Cite journal|last=Montazerolghaem|first=Ahmadreza|date=2021|title=Software-defined Internet of Multimedia Things: Energy-efficient and Load-balanced Resource Management
SDN was commonly associated with the [[OpenFlow]] protocol for remote communication with network plane elements to determine the path of [[network packet]]s across [[network switch]]es since OpenFlow's emergence in 2011. However, since 2012, proprietary systems have also used the term.<ref name="TechTarget: SDN is not OpenFlow">{{cite web |url=http://searchsdn.techtarget.com/news/2240158633/Software-defined-networking-is-not-OpenFlow-companies-proclaim |website=searchsdn.techtarget.com |title=Software-defined networking is not OpenFlow, companies proclaim}}</ref><ref name="TechTarget: OpenFlow not the only show in town">{{cite web |url=http://searchsdn.techtarget.com/guides/Guide-OpenFlow-SDN-not-the-only-show-in-town-for-vendors|title=InCNTRE's OpenFlow SDN testing lab works toward certified SDN product|date=10 February 2016 }}</ref> These include [[Cisco Systems]]' Open Network Environment and [[Nicira]]'s [[network virtualization platform]].
Line 14:
==History==
The history of SDN principles can be traced back to the separation of the control and data
The [[Internet Engineering Task Force]] (IETF) began considering various ways to decouple the control and data forwarding functions in a proposed interface standard published in 2004 named Forwarding and Control Element Separation (ForCES).<ref>{{cite IETF
Line 27:
|author=T. V. Lakshman, T. Nandagopal, R. Ramjee, K. Sabnani, and T. Woo
|date=Nov 2004
}}</ref> Additional early standards from the IETF that pursued separating control from data planes include the Linux Netlink as an IP services protocol,<ref>{{cite journal
|url=https://tools.ietf.org/html/rfc3549
|title=Linux Netlink as an IP Services Protocol
Line 33:
|date=July 2003
|doi=10.17487/RFC3549
|url-access=subscription
}}</ref> and a path computation element (PCE)-based architecture.<ref>{{cite journal
|url=https://tools.ietf.org/html/rfc4655
Line 39 ⟶ 40:
|date=August 2006
|doi=10.17487/RFC4655
|url-access=subscription
}}</ref>
Line 44 ⟶ 46:
The use of open-source software in these separated architectures traces its roots to the Ethane project at [[Stanford]]'s computer science department. Ethane's simple switch design led to the creation of OpenFlow,<ref>{{cite web
|url=
|title=Ethane: Taking Control of the Enterprise
|author=Martìn Casado, Michael J. Freedman, Justin Pettit, Jianying Luo, and Nick McKeown (Stanford University)
Line 60 ⟶ 62:
}}</ref>
SDN research included [[emulator]]s such as vSDNEmul,<ref>{{cite arXiv|last1=Farias|first1=Fernando N. N.|last2=Junior|first2=Antônio de O.|last3=da Costa|first3=Leonardo B.|last4=Pinheiro|first4=Billy A.|last5=Abelém|first5=Antônio J. G.|date=2019-08-28|title=vSDNEmul: A Software-Defined Network Emulator Based on Container Virtualization|eprint=1908.10980|class=cs.NI}}</ref> EstiNet,<ref>{{Cite journal|last1=Wang|first1=S.|last2=Chou|first2=C.|last3=Yang|first3=C.|date=September 2013|title=EstiNet openflow network simulator and emulator|journal=IEEE Communications Magazine|volume=51|issue=9|pages=110–117|doi=10.1109/MCOM.2013.6588659|bibcode=2013IComM..51i.110W |s2cid=14375937|issn=1558-1896}}</ref> and Mininet.<ref>{{Cite book|last1=Oliveira|first1=R. L. S. de|last2=Schweitzer|first2=C. M.|last3=Shinoda|first3=A. A.|last4=Ligia Rodrigues Prete|title=2014 IEEE Colombian Conference on Communications and Computing (COLCOM) |chapter=Using Mininet for emulation and prototyping Software-Defined Networks |date=June 2014|pages=1–6|doi=10.1109/ColComCon.2014.6860404|isbn=978-1-4799-4340-1|s2cid=17915639}}</ref>▼
▲SDN research included [[emulator]]s such as vSDNEmul,<ref>{{cite arXiv|last1=Farias|first1=Fernando N. N.|last2=Junior|first2=Antônio de O.|last3=da Costa|first3=Leonardo B.|last4=Pinheiro|first4=Billy A.|last5=Abelém|first5=Antônio J. G.|date=2019-08-28|title=vSDNEmul: A Software-Defined Network Emulator Based on Container Virtualization|eprint=1908.10980|class=cs.NI}}</ref> EstiNet,<ref>{{Cite journal|last1=Wang|first1=S.|last2=Chou|first2=C.|last3=Yang|first3=C.|date=September 2013|title=EstiNet openflow network simulator and emulator|journal=IEEE Communications Magazine|volume=51|issue=9|pages=110–117|doi=10.1109/MCOM.2013.6588659|s2cid=14375937|issn=1558-1896}}</ref> and Mininet.<ref>{{Cite book|last1=Oliveira|first1=R. L. S. de|last2=Schweitzer|first2=C. M.|last3=Shinoda|first3=A. A.|last4=Ligia Rodrigues Prete|title=2014 IEEE Colombian Conference on Communications and Computing (COLCOM) |chapter=Using Mininet for emulation and prototyping Software-Defined Networks |date=June 2014|pages=1–6|doi=10.1109/ColComCon.2014.6860404|isbn=978-1-4799-4340-1|s2cid=17915639}}</ref>
Work on OpenFlow continued at Stanford, including with the creation of testbeds to evaluate the use of the protocol in a single campus network, as well as across the WAN as a backbone for connecting multiple campuses.<ref>{{cite web
Line 68:
|title=GENI. Campus OpenFlow topology
|date=2011
}}</ref> In academic settings, there were several research and production networks based on OpenFlow switches from [[NEC]] and [[Hewlett-Packard]], as well as those based on [[Quanta Computer]]
|url=https://www.internet2.edu/presentations/fall11/20111003-wang-openflow.pdf
|archive-url=https://web.archive.org/web/20180103133512/https://www.internet2.edu/presentations/fall11/20111003-wang-openflow.pdf
Line 115:
==Concept==
SDN architectures decouple network control ([[control plane]]) and forwarding ([[data plane]]) functions, enabling the network control to become directly programmable and the underlying infrastructure to be abstracted from applications and network services.<ref>{{cite web|url=http://www.opennetworking.org/sdn-resources/sdn-definition|title=Software-Defined Networking (SDN) Definition|website=Opennetworking.org|access-date=26 October 2014}}</ref> The OpenFlow protocol is one of the protocols used in SDN technologies.
* Directly programmable: Network control is directly programmable because it is decoupled from forwarding functions.
* Agile: Abstracting control from forwarding lets administrators dynamically adjust network-wide [[Traffic flow (computer networking)|traffic flow]] to meet changing needs.
* Centrally managed: Network intelligence is (logically) centralized in software-based SDN controllers that maintain a global view of the network, which appears to applications and policy engines as a single, logical switch.
* Programmatically configured: SDN lets network managers configure, manage, secure, and optimize network resources very quickly via dynamic, automated SDN programs, which they can write themselves because the programs do not depend on proprietary software.<ref>{{Cite journal|last1=Montazerolghaem|first1=Ahmadreza|last2=Yaghmaee|first2=Mohammad Hossein|last3=Leon-Garcia|first3=Alberto|date=September 2020|title=Green Cloud Multimedia Networking: NFV/SDN Based Energy-Efficient Resource Allocation
* Open standards-based and vendor-neutral: When implemented through open standards, SDN simplifies network design and operation because instructions are provided by SDN controllers instead of multiple, vendor-specific devices and protocols.
Line 140:
; Energy use in large data centers
: As [[Internet of things]], [[cloud computing]] and [[SaaS]] emerged, the need for larger data centers has increased the energy consumption of those facilities. Many researchers have improved SDN's [[Efficient energy use|energy efficiency]] applying existing routing techniques to dynamically adjust the network data plane to save energy.<ref>{{cite journal |last1=Assefa |first1=Beakal Gizachew |last2=Özkasap |first2=Öznur |title=RESDN: A Novel Metric and Method for Energy Efficient Routing in Software Defined Networks |journal=IEEE Transactions on Network and Service Management |date=June 2020 |volume=17 |issue=2 |pages=736–749 |doi=10.1109/TNSM.2020.2973621 |url=https://doi.org/10.1109/TNSM.2020.2973621|arxiv=1905.12219 |bibcode=2020ITNSM..17..736A |s2cid=199442001 }}</ref> Also techniques to improve control plane energy efficiency are being researched.<ref>{{cite journal |last1=Oliveira |first1=Tadeu F. |last2=Xavier-de-Souza |first2=Samuel |last3=Silveira |first3=Luiz F. |title=Improving Energy Efficiency on SDN Control-Plane Using Multi-Core Controllers |journal=Energies |date=May 2021 |volume=14 |issue=11 |pages=3161 |doi=10.3390/en14113161 |language=en|doi-access=free }}</ref>
==Architectural components==
Line 147:
; SDN application
: SDN applications are programs that communicate their network requirements and desired network behavior to the SDN controller via a [[northbound interface]] (NBI). In addition, they may consume an abstracted view of the network for their internal decision-making purposes. An SDN Application consists of SDN application logic and one or more NBI drivers. SDN applications may themselves expose another layer of abstracted network control, thus offering one or more higher-level NBIs through respective NBI agents.
; SDN
: The SDN
; SDN
: The SDN
; SDN Control to Data-Plane Interface (CDPI)
: The SDN CDPI is the interface defined between an SDN
; SDN Northbound Interfaces (NBI)
: SDN NBIs are interfaces between SDN
==SDN
The implementation of the SDN control plane can follow a centralized, hierarchical, or decentralized design. Initial SDN control plane proposals focused on a centralized solution, where a single control entity
▲The implementation of the SDN control plane can follow a centralized, hierarchical, or decentralized design. Initial SDN control plane proposals focused on a centralized solution, where a single control entity has a global view of the network. While this simplifies the implementation of the control logic, it has scalability limitations as the size and dynamics of the network increase. To overcome these limitations, several approaches have been proposed in the literature that fall into two categories, hierarchical and fully distributed approaches. In hierarchical solutions,<ref name= Yeganeh>{{cite journal|first1=S.H.|last1=Yeganeh|first2=Y.|last2=Ganjali|title=Kandoo: A Framework for Efficient and Scalable Offloading of Control Applications|doi=10.1145/2342441.2342446|s2cid=193153|doi-access=free}}</ref><ref name= Ahmed>{{cite journal|first1=R.|last1=Ahmed|first2=R.|last2=Boutaba|title=Design considerations for managing wide area software defined networks|journal=IEEE Communications Magazine|year=2014|volume=52|issue=7|pages=116–123|doi=10.1109/MCOM.2014.6852092|s2cid=7912785}}</ref> distributed controllers operate on a partitioned network view, while decisions that require network-wide knowledge are taken by a logically centralized root controller. In distributed approaches,<ref name= Koponen>{{cite journal|url=https://www.usenix.org/legacy/events/osdi10/tech/full_papers/Koponen.pdf|first1=T.|last1=Koponen|title=Onix: A Distributed Control Platform for Large scale Production Networks|journal=Proceedings USENIX, Ser. OSDI'10|___location=Vancouver, Canada|year=2010}}</ref><ref name= Tuncer1>{{cite journal|title=Adaptive Resource Management and Control in Software Defined Networks|journal=IEEE Transactions on Network and Service Management|volume=12|issue=1|pages=18–33|date=March 2015|doi=10.1109/TNSM.2015.2402752|last1=Tuncer|first1=Daphne|last2=Charalambides|first2=Marinos|last3=Clayman|first3=Stuart|last4=Pavlou|first4=George|hdl=10044/1/63600|s2cid=9215618|url=https://discovery.ucl.ac.uk/id/eprint/1478892/|hdl-access=free}}</ref> controllers operate on their local view or they may exchange synchronization messages to enhance their knowledge. Distributed solutions are more suitable for supporting adaptive SDN applications.
A key issue when designing a distributed SDN control plane is to decide on the number and placement of control entities. An important parameter to consider while doing so is the [[network delay|propagation delay]] between the controllers and the network devices,<ref name= Heller>{{cite book|first1=B.|last1=Heller|first2=R.|last2=Sherwood|first3=N.|last3=McKeown|title=Proceedings of the first workshop on Hot topics in software defined networks - HotSDN '12|chapter=The Controller Placement Problem|year=2012|page=7|doi=10.1145/2342441.2342444|isbn=9781450314770|s2cid=1770114 }}</ref> especially in the context of large networks. Other objectives that have been considered involve control path [[Reliability (computer networking)|reliability]],<ref name= Hu>{{cite journal|title=On the placement of controllers in software-defined networks|year=2012|doi=10.1016/S1005-8885(11)60438-X|last1=Hu|first1=Yan-nan|last2=Wang|first2=Wen-Dong|last3=Gong|first3=Xiang-Yang|last4=Que|first4=Xi-Rong|last5=Cheng|first5=Shi-Duan|journal=The Journal of China Universities of Posts and Telecommunications|volume=19|pages=92–171}}</ref> [[fault tolerance]],<ref name= Ros>{{cite book|chapter=Five nines of southbound reliability in software-defined networks|year=2014|doi=10.1145/2620728.2620752|last1=Ros|first1=Francisco Javier|last2=Ruiz|first2=Pedro Miguel|title=Proceedings of the third workshop on Hot topics in software defined networking |pages=31–36|isbn=9781450329897|s2cid=17088018}}</ref> and application requirements.<ref name= Tuncer2>{{cite book|chapter=On the Placement of Management and Control Functionality in Software Defined Networks|doi=10.1109/CNSM.2015.7367383|title=2015 11th International Conference on Network and Service Management (CNSM)|year=2015|last1=Tuncer|first1=Daphne|last2=Charalambides|first2=Marinos|last3=Clayman|first3=Stuart|last4=Pavlou|first4=George|pages=360–365|isbn=978-3-9018-8277-7|s2cid=6977724|url=https://discovery.ucl.ac.uk/id/eprint/1502968/}}</ref><!--[[User:Kvng/RTH]]-->▼
▲A key issue when designing a distributed SDN control plane is to decide on the number and placement of control entities. An important parameter to consider while doing so is the propagation delay between the controllers and the network devices,<ref name= Heller>{{cite book|first1=B.|last1=Heller|first2=R.|last2=Sherwood|first3=N.|last3=McKeown|title=Proceedings of the first workshop on Hot topics in software defined networks - HotSDN '12|chapter=The Controller Placement Problem|year=2012|page=7|doi=10.1145/2342441.2342444|isbn=9781450314770|s2cid=1770114 }}</ref> especially in the context of large networks. Other objectives that have been considered involve control path reliability,<ref name= Hu>{{cite journal|title=On the placement of controllers in software-defined networks|year=2012|doi=10.1016/S1005-8885(11)60438-X|last1=Hu|first1=Yan-nan|last2=Wang|first2=Wen-Dong|last3=Gong|first3=Xiang-Yang|last4=Que|first4=Xi-Rong|last5=Cheng|first5=Shi-Duan|journal=The Journal of China Universities of Posts and Telecommunications|volume=19|pages=92–171}}</ref> fault tolerance,<ref name= Ros>{{cite book|chapter=Five nines of southbound reliability in software-defined networks|year=2014|doi=10.1145/2620728.2620752|last1=Ros|first1=Francisco Javier|last2=Ruiz|first2=Pedro Miguel|title=Proceedings of the third workshop on Hot topics in software defined networking |pages=31–36|isbn=9781450329897|s2cid=17088018}}</ref> and application requirements.<ref name= Tuncer2>{{cite book|chapter=On the Placement of Management and Control Functionality in Software Defined Networks|doi=10.1109/CNSM.2015.7367383|title=2015 11th International Conference on Network and Service Management (CNSM)|year=2015|last1=Tuncer|first1=Daphne|last2=Charalambides|first2=Marinos|last3=Clayman|first3=Stuart|last4=Pavlou|first4=George|pages=360–365|isbn=978-3-9018-8277-7|s2cid=6977724|url=https://discovery.ucl.ac.uk/id/eprint/1502968/}}</ref>
==SDN Data Plane==
Line 177 ⟶ 175:
* ''Software Switch-Based SDNs:'' Some physical switches may implement SDN support using software on the device, such as [[Open vSwitch]], to populate flow tables and to act as the SDN agent when communicating with the controller. [[Hypervisor]]s may likewise use software implementations to support SDN protocols in the virtual switches used to support their [[virtual machine]]s.
* ''Host-Based SDNs:'' Rather than deploying the data plane and SDN agent in network infrastructure, host-based SDNs deploy the SDN agent inside the operating system of the communicating endpoints.<ref>{{cite book |last1=Taylor |first1=Curtis |last2=MacFarland |first2=Douglas |last3=Smestad |first3=Doran |last4=Shue |first4=Craig |title=IEEE INFOCOM 2016 - the 35th Annual IEEE International Conference on Computer Communications |chapter=Contextual, flow-based access control with scalable host-based SDN techniques |date=10 April 2014 |pages=1–9 |doi=10.1109/INFOCOM.2016.7524498 |isbn=978-1-4673-9953-1 |s2cid=17491115 |chapter-url=https://par.nsf.gov/servlets/purl/10055769}}</ref> Such implementations can provide additional context about the application, user, and activity associated with network flows.<ref>{{cite book |last1=Chuluundorj |first1=Zorigtbaatar |last2=Taylor |first2=Curtis |last3=Walls |first3=Robert |last4=Shue |first4=Craig |title=2021 Eighth International Conference on Software Defined Systems (SDS) |chapter=Can the User Help? Leveraging User Actions for Network Profiling |date=6 December 2021 |pages=1–8 |doi=10.1109/SDS54264.2021.9732164 |isbn=978-1-6654-5820-7 |s2cid=244036711
Flow table entries may be populated in a proactive, reactive, or hybrid fashion.<ref>{{cite web|url=http://networkstatic.net/openflow-proactive-vs-reactive-flows/ |title=OpenFlow: Proactive vs Reactive |website=NetworkStatic.net |date= 2013-01-15|access-date=2014-07-01}}</ref><ref>{{cite web|url=https://devcentral.f5.com/articles/reactive-proactive-predictive-sdn-models |title=Reactive, Proactive, Predictive: SDN Models | F5 DevCentral |website=Devcentral.f5.com |date= 2012-10-11|access-date=2016-06-30}}</ref> In the proactive mode, the controller populates flow table entries for all possible traffic matches possible for this switch in advance. This mode can be compared with typical routing table entries today, where all static entries are installed ahead of time. Following this, no request is sent to the controller since all incoming flows will find a matching entry. A major advantage in proactive mode is that all packets are forwarded in line rate (considering all flow table entries in TCAM) and no delay is added. In the reactive mode, entries are populated on demand. If a packet arrives without a corresponding match rule in the flow table, the SDN agent sends a request to the controller for further instruction it the reactive mode. The controller examines the SDN agent requests and provides instructions, installing a rule in the flow table for the corresponding packet if necessary. The hybrid mode uses the low-latency proactive forwarding mode for a portion of traffic while relying on the flexibility of reactive mode processing for the remaining traffic.
Line 184 ⟶ 182:
=== SDMN ===
[[Software-defined mobile network]]ing (SDMN)<ref name= MobileFlow>{{Cite journal |doi = 10.1109/MCOM.2013.6553677|title = Mobileflow: Toward software-defined mobile networks|journal = IEEE Communications Magazine|volume = 51|issue = 7|pages = 44–53|year = 2013|last1 = Pentikousis|first1 = Kostas|last2 = Wang|first2 = Yan|last3 = Hu|first3 = Weihua| bibcode=2013IComM..51g..44P |s2cid = 10655582}}</ref><ref>{{Cite book|url=http://eu.wiley.com/WileyCDA/WileyTitle/productCd-1118900286.html|title=Software Defined Mobile Networks (SDMN): Beyond LTE Network Architecture|last=Liyanage|first=Madhusanka|publisher=John Wiley|year=2015|isbn=978-1-118-90028-4|___location=UK|pages=1–438}}</ref> is an approach to the design of mobile networks where all protocol-specific features are implemented in software, maximizing the use of generic and commodity hardware and software in both the [[core network]] and [[radio access network]].<ref>{{cite book|chapter=SDN and NFV Integration in Generalized Mobile Network Architecture|doi=10.1109/EuCNC.2015.7194059|title=2015 European Conference on Networks and Communications (EuCNC)|year=2015|last1=Costa-Requena|first1=Jose|last2=Liyanage|first2=Madhusanka|last3=Ylianttila|first3=Mika|last4=De Oca|first4=Edgardo Montes|last5=Santos|first5=Jesus Llorente|last6=Guasch|first6=Vicent Ferrer|last7=Ahokas|first7=Kimmo|last8=Premsankar|first8=Gopika|last9=Luukkainen|first9=Sakari|last10=Perez|first10=Oscar Lopez|last11=Itzazelaia|first11=Mikel Uriarte|last12=Ahmad|first12=Ijaz|pages=154–158|isbn=978-1-4673-7359-3|s2cid=2453962}}</ref> It is proposed as an extension of SDN paradigm to incorporate [[mobile network]] specific functionalities.<ref>{{cite book|chapter=Securing the Control Channel of Software-Defined Mobile Networks|doi=10.1109/WoWMoM.2014.6918981|title=Proceeding of IEEE International Symposium on a World of Wireless, Mobile and Multimedia Networks 2014|year=2014|last1=Liyanage|first1=Madhusanka|last2=Ylianttila|first2=Mika|last3=Gurtov|first3=Andrei|pages=1–6|isbn=978-1-4799-4786-7|s2cid=1378181}}</ref> Since 3GPP Rel.14, a Control User Plane Separation was introduced in the Mobile Core Network architectures with the [[PFCP]] protocol.
===SD-WAN===
Line 215 ⟶ 213:
== Quality of Experience (QoE) estimation using SDN ==
When using an SDN based model for transmitting multimedia traffic, an important aspect to take account is the QoE estimation. To estimate the QoE, first we have to be able to classify the traffic and then, it's recommended that the system can solve critical problems on its own by analyzing the traffic.<ref>{{Cite journal|last=Canovas|first=Alejandro|title=A robust multimedia traffic SDN-Based management system using patterns and models of QoE estimation with BRNN|url=https://www.sciencedirect.com/science/article/pii/S1084804519303583|journal= Journal of Network and Computer Applications|year=2020|volume=150|
==See also==
| |||