Overview of SDN-IP architecture based on Onos

Editor's note: Sdn-ip is an application on Onos that allows software-defined networks to connect to external networks using standard Border Gateway Protocol (BGP). From a BGP perspective, the SDN network behaves as a single autonomous system (as), with the same behavior as any traditional as. The SDN-IP application based on as provides an integrated integration mechanism between BGP and Onos, SDN-IP behavior in the protocol layer as a regular BGP spokesperson. From a onos perspective, it just uses its services to install and update the appropriate forwarding state applications on the SDN data plane.

1 Architectural goals

1.1 Sdn-ip Design Goals

(1) Compatibility Compatibility:sdn-ip can be integrated with a network that already uses BGP, external, internal, or both, and is well-compatible.

(2) Operational flexibility operational FLEXIBILITY:SDN-IP can run in one or more onos instances. Sdn-ip can also be used in a variety of BGP deployment scenarios, showing a high flexibility.

(3) Highly available high Availability (HA): The SDN-IP application itself provides HA services. As long as one of the SDN-IP application instances is running, the SDN-IP service will remain seamlessly connected. In addition, SDN-IP uses the HA mechanism that provides onos to maintain a consistent forwarding state in the data plane.

(4) Scalability Scalability: Large software-defined networks can be controlled through a running BGP-based network and SDN-IP of multiple onos clusters.

(5) Protocol compatibility and vendor independence protocol compatibility and vendor INDEPENDENCE:SDN-IP relies on the standard BGP protocol to Exchange network information and does not require any proprietary or vendor-specific extensions.

1.2 Architecture Overview

SDN-IP Architecture:

2 Connectivity

2.1 Sdn-ip Application intents

The following is a brief description of the two types of SDN-IP using the application intents.

(1) Intents of single point to single point

A BGP peering session is established between the external router and the SDN BGP speakers using one-way unidirectional intents. Each intents connects two connection points in an SDN network. Each connection point contains the following information: The DPID of the SDN switch, the switch port, and the MAC address of the connected BGP speaker router.

(2) Multi-point to single-point intents

Multipoint-to-point intents are used for unidirectional intents that are connected to hosts in the external network. Each intent is associated with each IP prefix (destination IP) and connects the ingress connection point of the SDN network with a single egress connection point, pointing to the destination IP of the next-hop router. At the edge of the SDN network portal, an IP packet matches the destination IP address. Select the best optimal forwarding item to match the forwarding packet to the corresponding egress connection point. In addition, before the packet is forwarded, the "Change destination MAC address" is applied so that packets containing the egress IP router are forwarded to the destination MAC address.

2.2 SDN Data plane connectivity

The data plane in the SDN-IP network is primarily used for the following scenarios:

(1) BGP traffic control between the internal BGP speaker and the external BGP router (configuration EBGP peerings).

(2) Transmission of data between external IP networks across the SDN-IP network.

EBGP control traffic is related to each EBGP equivalent operation. This traffic is point-to-point, bidirectional, and the endpoint is relatively static based on the EBGP-peer operation configuration. When a data plane fails, it may cause a path change between the endpoints. This fault can be automatically detected and the associated intents will be onos to reset the route. Currently, the specific connection points are related to each BGP speaker, and the external BGP router needs to be configured manually in the Sdn-ip configuration file, but this requirement will be eliminated in the future.

The path for transmitting data traffic is defined by a BGP route that is published by an external bgppeers. Similar to regular BGP deployments, these routes are relatively dynamic and they are very large in number. If a BGP peer advertises a route for a particular IP prefix and is selected as the best-routed next-hop address, SDN-IP will be responsible for establishing the corresponding data path. All traffic determines the IP prefixes that go into the remaining external IP network are forwarded to the most matched external next hop BGP router. Onos application intents, the IP prefix is implemented by creating a multipoint-to-single-point application intents: the egress router (i.e. the best next-hop router) is (egress) a single point of intent, and the remaining external BGP routers are (ingress) multipoint intents.

The SDN-IP application is responsible for generating multipoint-to-single-point application intents requests and intents for updating BGP routed dynamic responses. The Onos itself is responsible for compiling these requests, installing the appropriate forwarding stream on the switch data plane, and intents the routing to prevent the SDN network from failing.

2.3 Sdn Control Plane connectivity

BGP speaker Communication uses IBGP in the SDN network and SDN-IP application instances. The peer session is created in the control plane, so each BGP speaker is connected to it.

In any BGP deployment, the BGP speaker and SDN-IP application instances are interconnected: a complete IBGP mesh, route reflection, and so on. The only difference is that there is no need for IBGP peerings between Sdn-ip instances, they only need to interconnect with BGP speaker.

SDN-IP implements a subset of the IBGP protocol: receives only BGP routing information from BGP speaker, but never initiates or re-sends BGP routes. Once the SDN-IP receives a notification from an external router (received via BGP speaker), it transforms the routing information into a intents request to Onos. The Onos itself transforms it into a openflow stream table entry in the switch.

BGP speaker uses IBGP to transmit routing information to SDN-IP application instances, and it is important to achieve interoperability across the network or with the appropriate servers using routing in a regular BGP deployment. Therefore, we can use the failure failure provided by BGP itself. There is no need for IBGP peering between SDN-IP application instances: Peering is between the BGP speaker and SDN-IP application instances.

2.4 High Availability support

SDN-IP provides support for high availability using hot backup mode. SDN-IP applications can be loaded on multiple Onos instances. All SDN-IP applications Listen for routing updates for BGP arrival information, but only one SDN-IP instance is designated as the primary instance responsible for pushing intents to Onos. If the primary instance fails, one of the remaining instances will become the new primary instance to continue pushing intents to onos.

Sdn-ip uses Onos to lead the election service to select the main sdn-ip instance. We have to make sure that only one instance pushes intents at any time, preventing the wrong intents from being pushed to Onos. When each Sdn-ip instance starts, it participates in the lead election attempt to become the primary instance. Elections ensure that only one instance at any one time can be the primary instance. When the primary instance fails, the electoral mechanism detects a failure and allows another instance to take over the responsibility to become the primary instance. The new primary instance first makes intents synchronization to ensure that the BGP routes learned before the intents update. Once the synchronization is complete, the primary instance is working and continues to install and remove intents in response to the BGP update.

Although the SDN-IP application supports HA (high availability), the system is still vulnerable to component failures unless there is redundancy between the internal BGP speaker and the BGP peer session. Each SDN-IP instance is able to receive BGP updates from BGP speaker, ensuring that multiple internal BGP speaker are deployed in the SDN network.

3 Limitations

The following limitations are present in the current implementation of the SDN-IP application:

(1) Detailed configuration information can only be configured before Sdn-ip is started. After startup, the user cannot change the configuration, for example, when SDN-IP is running, the user cannot add other external BGP peers.

(2) Only the transmission IP traffic is supported. In other words, IP traffic from the host or the host in the SDN-IP network is not supported. As a workaround, the user can manually create a dedicated intents that allows the internal host to communicate with the external network in the future this should be done automatically by SDN-IP.

(3) Sdn-ip the default listener for BGP connections is non-standard port 2000, which is not the normal standard port 179 for BGP connections. However, this port number is configurable and can be configured to 179, but it must be run as root and bound to a protected port. Running Onos as root is not currently supported.

(4) Sdn-ip between Onos instances is not load balanced. All the work is done by a single master instance. If an instance fails, you can switch to a backup to run the case.

(5) There is no explicit IBGP session configuration on the SDN-IP application side. By default, the Sdn-ip app will accept all BGP open messages and will automatically be configured to use the as number of the original BGP speaker.

(6) If all SDN-IP application instances are uninstalled, the associated application intents is not automatically removed from Onos.

(7) If the MAC address of the next hop changes, the intents is not updated and the traffic stops flowing.

(8) currently only supports IPV4.

(9) Peer sessions between the external BGP router and the internal BGP speaker must use TCP port 179 for peering connections. Only TCP connections to port 179 are allowed to access the peer IP address of the SDN network.

(10) Due to the limitations of the intents framework, the 1.0.0 version of the system can handle approximately 15000 routes.

This article is from Sdnlab, click here to read the original. If you are interested in this article, you can participate in the following interactive ways to communicate with the author in close range.

If you are interested in this article, you can participate in the following interactive ways to communicate with the author in close range.

(1) Weibo (http://weibo.com/sdnlab/)

(2) ( account No.:Sdnlab)

(3) QQ Group

SDN Research Group (214146842)

Opendaylight Research Group (194240432)

Overview of SDN-IP architecture based on Onos