Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
This section provides information about the design, implementation, and operation of SDN-IP and its subsystems.
Introduction
SDN-IP is an ONOS application that allows a Software Defined Network to connect to external networks on the Internet using the standard Border Gateway Protocol (BGP). Externally, from a BGP perspective, the SDN network appears as a single Autonomous System (AS) that behaves as any traditional AS. Within the AS, the SDN-IP application provides the integration mechanism between BGP and ONOS. At the protocol level, SDN-IP behaves as a regular BGP speaker. From ONOS perspective, it’s just an application that uses its services to install and update the appropriate forwarding state in the SDN data plane.
Architectural goals
SDN-IP has been designed with the following goals in mind:
- Compatibility - SDN-IP can be integrated with networks that already use BGP - externally, internally, or both.
- Operational flexibility - SDN-IP can run on one or multiple ONOS instances. Moreover, SDN-IP can be used in a variety of BGP deployment scenarios: full-mesh BGP, BGP Route Reflectors, BGP confederations, and with BGP Route Servers.
- High availability - SDN-IP provides HA within the application itself. The SDN-IP service keeps working seamlessly, as long as there is at least one instance of the SDN-IP application running. In addition, SDN-IP leverages the HA mechanisms provided by ONOS for maintaining a consistent forwarding state in the data plane.
- Scalability - Large-scale Software Defined Networks can be controlled by using BGP-based Confederations and multiple ONOS clusters, each running SDN-IP.
- Protocol compatibility and vendor independence - SDN-IP relies on the standard BGP protocol for exchanging network information, and does not require any proprietary or vendor-specific extensions.
Overview
In a typical deployment scenario, an SDN-IP controlled network acts as a transit Autonomous System (AS) interconnecting different IP networks. Each external network is a different AS domain, which interfaces with our SDN network through its BGP-speaking border routers.
The SDN-IP network is composed of OpenFlow switches controlled by ONOS. For high availability and scalability, there should be a cluster of ONOS instances (some of those instances running the SDN-IP application), though SDN-IP can be used even with a single ONOS instance.
Within the SDN-IP network, there are one or more internal BGP speakers. The BGP speakers can be existing BGP routers or any software that implements BGP. The speakers use eBGP to exchange BGP routing information with the border routers of the adjacent external networks, and iBGP to propagate that information amongst themselves and to the SDN-IP application instances.
The routes advertised by the external border routers belonging to external networks are received by the BGP speakers within the SDN-IP network, processed and eventually re-advertised to the other external networks (according to the normal BGP processing and routing policies). Similarly, those routes are also advertised to the SDN-IP application instances which act as iBGP peers. According to the iBGP rules, the best route for each destination is selected by the SDN-IP application and translated into an ONOS Application Intent Request. ONOS translates the Application Intent Request into forwarding rules in the data plane. Those rules are used to forward the transit traffic between the interconnected IP networks.
In addition, SDN-IP creates the appropriate ONOS Intents that would allow the external BGP routers to peer with the BGP speakers by using the data plane. Thus, BGP itself can also detect failures in the data plane that affect the transiting traffic and act accordingly.
Among the SDN-IP application instances, each instance receives and contains exactly the same set of BGP routes (and the corresponding Application Intent Requests), but only one instance at a time (the SDN-IP Leader) is responsible for making the appropriate ONOS API calls to install the necessary intents.