Content deleted Content added
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 |
|||
| (45 intermediate revisions by 19 users not shown) | |||
Line 7:
}}
'''Software-defined networking''' ('''SDN''') is an approach to [[network management]] that
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 86:
|title=Inside Google's Software-Defined Network
|author=brent salisbury
|work=Network Computing
|date=May 14, 2013
}}</ref> Later, Google announced the first OpenFlow/Onix deployments in is datacenters.<ref>{{cite web
Line 114 ⟶ 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 127 ⟶ 128:
; Changing traffic patterns
: Within the enterprise data center, traffic patterns have changed significantly. In contrast to client-server applications where the bulk of the communication occurs between one client and one server, today's applications access different databases and servers, creating a flurry of [[East-west traffic|east-west machine-to-machine traffic]] before returning data to the end user device in the classic [[north-south traffic]] pattern. At the same time, users are changing network traffic patterns as they push for access to corporate content and applications from any type of device, connecting from anywhere, at any time. Finally, many enterprise data center managers are deploying a utility computing model, which may include a private cloud, public cloud, or some mix of both, resulting in additional traffic across the wide-area network.
; The
: Users are increasingly employing mobile personal devices such as smartphones, tablets, and notebooks to access the corporate network. IT is under pressure to accommodate these personal devices in a fine-grained manner while protecting corporate data and intellectual property and meeting compliance mandates.
; The rise of cloud services
: Enterprises have enthusiastically embraced both public and private cloud services, resulting in unprecedented growth of these services. Many enterprise
;
: Handling today's
; Energy use
: As [[Internet of
==Architectural components==
[[File:SDN-architecture-overview-transparent.png|thumb|right|upright=2|A high-level overview of the software-defined networking architecture]]
The following list defines and explains the SDN architectural components:<ref>{{cite web|url=http://www.opennetworking.org/images/stories/downloads/sdn-resources/technical-reports/SDN-architecture-overview-1.0.pdf|title=SDN Architecture Overview|website=Opennetworking.org|access-date=22 November 2014}}</ref>
; SDN
: SDN
; 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 176 ⟶ 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 183 ⟶ 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 211 ⟶ 210:
==Relationship to DPI==
== 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==
Line 225 ⟶ 224:
* [[List of SDN controller software]]
* [[Network functions virtualization]]
* [[Network virtualization]]▼
* [[ONOS]]
* [[OpenDaylight Project]]
Line 232:
* [[Software-defined protection]]
* [[Virtual Distributed Ethernet]]
▲* [[Network virtualization]]
{{Div col end}}
==References==
{{Reflist
{{Authority control}}
| |||