below one was the example for SDN as per my knowledge, if useful please give reward points.
Verizon SDN-NFV Based Network:
The following are key features of the network based on SDN and NFV:
Enhancements to the Software Defined Networking (SDN) Concept :
The fundamental concept of ‘Software Defined Networking’ (SDN) changes the current network
design paradigm by introducing network programmability and abstraction. In its initial, narrow
definition, SDN is about separating the network control and data planes in L1, L2, L3, and L4
switches. This enables independent scaling of control plane resources and data plane resources,
maximizing utilization of hardware resources. In addition, control plane centralization reduces
the number of managed control plane instances, simplifies operations, and enables orchestration.
The idea of centralized network control can be generalized, resulting in the broader definition of
SDN: the introduction of standard protocols and data models that enable logically centralized
control across multivendor and multi-layer networks. Such SDN Controllers expose abstracted
topology and service data models towards northbound systems, simplifying orchestration of end-
to-end services and enabling the introduction of innovative applications that rely on network
programmability.
Platform SDN Considerations:
Network changes are initiated by the VIM to provide VNFC connectivity and establish service
chains between VNFs as instructed by EEO. The VIM and the DC SDN controller communicate
using common interfaces to implement the necessary networking changes.
Scope of Control – SDN controller vs. other NFV system elements:
The interface between End-to-End Orchestration, non-network controllers (like non-network
OpenStack services) and the network controller is important for interoperability. There are
efforts currently underway in ONF, Open Daylight, ONOS, OpenStack, IETF, and elsewhere to
implement a common Northbound Interface (NBI) to support operator critical use cases. The
primary purpose of the SDN controller is to (re)establish some clean layering between
subsystems that exclusively control their respective resources. The DC SDN controller
subsystem (VIM + SDN Controller) is responsible for controlling connectivity, QoS, path
selection, selection of VNF network placement, inter- VNFC connections, etc. In the ETSI
definition of Forwarding Graphs (FG), the FG passed to the network controller only specifies the
types/flavors of VNFs to use for specific subscriber traffic and the order in which to apply VNFs
of various types/flavors. This allows the SDN controller to have latitude in deciding how best to
satisfy the functional requirements of a given forwarding graph. In addition, this clean layering
of decision making allows for network changes and faults that would be service impacting to be
healed within the network control plane without requiring interaction and direction from the
orchestration layer. The software systems outs.
Kisan Call Centre - To harness potential of ICT in Agriculture by answer farm...
below one was the example for SDN as per my knowledge, if useful ple.pdf
1. below one was the example for SDN as per my knowledge, if useful please give reward points.
Verizon SDN-NFV Based Network:
The following are key features of the network based on SDN and NFV:
Enhancements to the Software Defined Networking (SDN) Concept :
The fundamental concept of ‘Software Defined Networking’ (SDN) changes the current network
design paradigm by introducing network programmability and abstraction. In its initial, narrow
definition, SDN is about separating the network control and data planes in L1, L2, L3, and L4
switches. This enables independent scaling of control plane resources and data plane resources,
maximizing utilization of hardware resources. In addition, control plane centralization reduces
the number of managed control plane instances, simplifies operations, and enables orchestration.
The idea of centralized network control can be generalized, resulting in the broader definition of
SDN: the introduction of standard protocols and data models that enable logically centralized
control across multivendor and multi-layer networks. Such SDN Controllers expose abstracted
topology and service data models towards northbound systems, simplifying orchestration of end-
to-end services and enabling the introduction of innovative applications that rely on network
programmability.
Platform SDN Considerations:
Network changes are initiated by the VIM to provide VNFC connectivity and establish service
chains between VNFs as instructed by EEO. The VIM and the DC SDN controller communicate
using common interfaces to implement the necessary networking changes.
Scope of Control – SDN controller vs. other NFV system elements:
The interface between End-to-End Orchestration, non-network controllers (like non-network
OpenStack services) and the network controller is important for interoperability. There are
efforts currently underway in ONF, Open Daylight, ONOS, OpenStack, IETF, and elsewhere to
implement a common Northbound Interface (NBI) to support operator critical use cases. The
primary purpose of the SDN controller is to (re)establish some clean layering between
subsystems that exclusively control their respective resources. The DC SDN controller
subsystem (VIM + SDN Controller) is responsible for controlling connectivity, QoS, path
selection, selection of VNF network placement, inter- VNFC connections, etc. In the ETSI
definition of Forwarding Graphs (FG), the FG passed to the network controller only specifies the
types/flavors of VNFs to use for specific subscriber traffic and the order in which to apply VNFs
of various types/flavors. This allows the SDN controller to have latitude in deciding how best to
satisfy the functional requirements of a given forwarding graph. In addition, this clean layering
of decision making allows for network changes and faults that would be service impacting to be
healed within the network control plane without requiring interaction and direction from the
2. orchestration layer. The software systems outside of the SDN controller can’t possibly
understand the state of network resources and their usage enough to make the best decisions
about network proximity, network utilization, interface speeds, protocol limitations, etc. and thus
are forbidden from specifying network specific instances and paths. The design for the Service
Function Chaining (SFC) interface (also called SGi-LAN) must include allowing the SDN
controller to choose specific instances of VNFs for assignment and to choose the network paths
which are used to forward traffic along the chain of chosen instances.
Network Virtualization:
In addition to the subscriber oriented services delivered by an NFV solution, the NFV developer
and operator is expected to have diverse multi-tenant (possible MVNO) virtual networking
requirements that must be supported by a controller-based NetVirt implementation. Shared
infrastructure ultimately needs logical separation of tenant networks and like cloud providers,
NFV operators can be expected to require support for a scale-out NetVirt solution based on a
single logical controller and large numbers of high-performance virtual networks with highly
customized network behaviors.
Extensible SDN controller:
A multi-service DC SDN controller platform that can integrate and manage resource access
among diverse, complimentary SDN services is critical to a successful NFVI. A NetVirt-only
controller and NBI are insufficient, just as an SFC-only controller is insufficient. A controller
architecture where multiple, independently developed services share access to forwarding tables
by cooperating at the flow-rules level is chaotic and unmanageable. Therefore, an extensible
SDN controller platform and orchestration-level coordination is required to implement the virtual
networking layer of the NFVI.
Solution
below one was the example for SDN as per my knowledge, if useful please give reward points.
Verizon SDN-NFV Based Network:
The following are key features of the network based on SDN and NFV:
Enhancements to the Software Defined Networking (SDN) Concept :
The fundamental concept of ‘Software Defined Networking’ (SDN) changes the current network
design paradigm by introducing network programmability and abstraction. In its initial, narrow
definition, SDN is about separating the network control and data planes in L1, L2, L3, and L4
switches. This enables independent scaling of control plane resources and data plane resources,
maximizing utilization of hardware resources. In addition, control plane centralization reduces
the number of managed control plane instances, simplifies operations, and enables orchestration.
3. The idea of centralized network control can be generalized, resulting in the broader definition of
SDN: the introduction of standard protocols and data models that enable logically centralized
control across multivendor and multi-layer networks. Such SDN Controllers expose abstracted
topology and service data models towards northbound systems, simplifying orchestration of end-
to-end services and enabling the introduction of innovative applications that rely on network
programmability.
Platform SDN Considerations:
Network changes are initiated by the VIM to provide VNFC connectivity and establish service
chains between VNFs as instructed by EEO. The VIM and the DC SDN controller communicate
using common interfaces to implement the necessary networking changes.
Scope of Control – SDN controller vs. other NFV system elements:
The interface between End-to-End Orchestration, non-network controllers (like non-network
OpenStack services) and the network controller is important for interoperability. There are
efforts currently underway in ONF, Open Daylight, ONOS, OpenStack, IETF, and elsewhere to
implement a common Northbound Interface (NBI) to support operator critical use cases. The
primary purpose of the SDN controller is to (re)establish some clean layering between
subsystems that exclusively control their respective resources. The DC SDN controller
subsystem (VIM + SDN Controller) is responsible for controlling connectivity, QoS, path
selection, selection of VNF network placement, inter- VNFC connections, etc. In the ETSI
definition of Forwarding Graphs (FG), the FG passed to the network controller only specifies the
types/flavors of VNFs to use for specific subscriber traffic and the order in which to apply VNFs
of various types/flavors. This allows the SDN controller to have latitude in deciding how best to
satisfy the functional requirements of a given forwarding graph. In addition, this clean layering
of decision making allows for network changes and faults that would be service impacting to be
healed within the network control plane without requiring interaction and direction from the
orchestration layer. The software systems outside of the SDN controller can’t possibly
understand the state of network resources and their usage enough to make the best decisions
about network proximity, network utilization, interface speeds, protocol limitations, etc. and thus
are forbidden from specifying network specific instances and paths. The design for the Service
Function Chaining (SFC) interface (also called SGi-LAN) must include allowing the SDN
controller to choose specific instances of VNFs for assignment and to choose the network paths
which are used to forward traffic along the chain of chosen instances.
Network Virtualization:
In addition to the subscriber oriented services delivered by an NFV solution, the NFV developer
and operator is expected to have diverse multi-tenant (possible MVNO) virtual networking
requirements that must be supported by a controller-based NetVirt implementation. Shared
4. infrastructure ultimately needs logical separation of tenant networks and like cloud providers,
NFV operators can be expected to require support for a scale-out NetVirt solution based on a
single logical controller and large numbers of high-performance virtual networks with highly
customized network behaviors.
Extensible SDN controller:
A multi-service DC SDN controller platform that can integrate and manage resource access
among diverse, complimentary SDN services is critical to a successful NFVI. A NetVirt-only
controller and NBI are insufficient, just as an SFC-only controller is insufficient. A controller
architecture where multiple, independently developed services share access to forwarding tables
by cooperating at the flow-rules level is chaotic and unmanageable. Therefore, an extensible
SDN controller platform and orchestration-level coordination is required to implement the virtual
networking layer of the NFVI.