China
Africa
Explore chapters and articles related to this topic
SDN and NFV
Published in Dijiang Huang, Ankur Chowdhary, Sandeep Pisharody, Software-Defined Networking and Security, 2018
Dijiang Huang, Ankur Chowdhary, Sandeep Pisharody
RouteFlow controller interacts with RouteFlow Server through RouteFlow Protocol. The Virtual Environment (VE) consists of RouteFlow Client and Routing Engine. The Route-Flow Client collects Forwarding Information Base (FIB) from the Routing Engine (Quagga, BIRD, XORP, etc). RouteFlow Client transforms these FIBs into OpenFlow tuples that are forwarded to the RouteFlow Server that is responsible for establishing routing logic out of these tuples. The routing logic is transferred to RouteFlow controller that defines the match field and action against each match. The VE is connected directly to the RouteFlow controller through a Virtual Switch, such as OVS. The direct connection between VE and controller reduces the delay by providing a direct mapping of physical and virtual topology. There were no databases used in the first phase of the development of RouteFlow, which may choke the RouteFlow Server. To overcome this issue, NoSQL (MongoDB, Redis, CouchDB) was introduced in the RouteFlow architecture to provide inter-process communication between different components of the architecture. Routeflow performs multiple operations in different scenarios: i) logical split, ii) multiplexing and iii) aggregation. The entire routing tasks are done by the virtual environment that provides flexibility. The different phases of RouteFlow development makes it possible to integrate it with SDN, so much so that RouteFlow is considered the basic architecture to control routing in SDNs.
Extending Open Shortest Path First for Mobile Ad Hoc Network Routing
Published in Jonathan Loo, Jaime Lloret Mauri, Jesús Hamilton Ortiz, Mobile Ad Hoc Networks, 2016
Katherine Isaacs, Julie Hsieh, Melody Moh
Spagnolo [25] compared OSPF MDR, OSPF OR/SP, and the nonextended OSPF protocol in simulation using the Georgia Tech Network Simulation (GTNetS) and the Quagga routing daemon. Each scheme was tested using full adjacency/full topology advertisement, minimal adjacency/full topology advertisement, and minimal adjacency/minimal topology advertisement. In addition, simulations were run using the other levels of adjacency formation and topology advertisement that OSPF MDR offers. Measurements included average control message bandwidth, delivery ratio, number of adjacencies, adjacency stability, route stability, route stretching, and LSA generation rate.
Key Management in Wireless Mesh Networks
Published in Yan Zhang, Jun Zheng, Honglin Hu, Security in Wireless Mesh Networks, 2008
Figure 10.2 shows that in the case where there is a routing middleware (like Zebra1 or Quagga2), the middleware routing table will contain the validated routes from the SAODV daemon combined with the ones from the other routing daemons, and the routing table in the kernel the ones with lowest “administrative distance” (in case there is a route to the same destination provided by two different routing daemons).
Model and simulations of multipath bridge routing for inter-swarm UAV communications in EMANE/CORE
Published in International Journal of Modelling and Simulation, 2022
Zhe Chu, Fei Hu, Elizabeth Serena Bentley, Sunil Kumar
With a private network stack, the network protocols and applications can be configured in each node. To set up the protocols for each virtual machine, the concept of services is used in CORE to specify the processes or scripts. Multiple software plug-ins can provide services. For example, the Quagga routing suite can support routing protocols, such as OSPFv2. EMANE is also a plug-in in this case and can provide multiple transport services such as IEEE802.11b.