...

SDN-IP allows an SDN network to peer and exchange traffic with adjacent external network using the BGP routing protocol. 

FIGURE 1 shows the topology various elements we expect in our in the SDN-IP network model.

• The most fundamental building block is, of course, the SDN network. This is the network that is controlled by ONOS

...

• and will use SDN-IP to communicate with the outside world

...

• .
• The network is controlled by a cluster of ONOS instances (one or more).
• SDN-IP runs as an application on a subset of ONOS instances
• External BGP routers are connected at the edge of the SDN network.

...

• These are routers belonging to other administrative domains that will peer with the SDN network through BGP. The SDN network needs to have direct (not routed) IP connectivity to each external router it needs to peer with.

• Inside the SDN network there are one or more internal BGP speakers. There are no specific requirements on the implementation of the BGP speakers - as long as they support both external

...

• BGP (eBGP) and internal BGP (iBGP) peering sessions they will work. For our testing and deployments we use open-source software routers such as BIRD or Quagga. The internal BGP speakers peer in two different ways:
  • Each BGP speaker must have at least one connection to the SDN data plane network. The BGP speaker will peer with external BGP routers over this connection using eBGP. 
  • Each BGP speaker also needs to peer with each SDN-IP instance using iBGP so it can relay routes to the SDN-IP instances.

...

• • The connectivity for this peering must be out-of-band of the data plane

...

• • .

BGP Peering

...

Topology

There are no strict requirements on how the BGP topology should be set up, as long as each SDN-IP instance is able to receive all routes advertised to the SDN network through iBGP. In saying that, there are recommended deployment scenarios that we use and have tested thoroughly.

Image Removed

Reference scenario

BGP speakers a deployed as BGP software running on a Linux host.

...

use and have tested thoroughly.

Image Added

FIGURE 2 shows an example BGP configuration. The icons show various nodes in the network and the lines show BGP peering sessions. Black lines are eBGP sessions between an internal BGP speaker and an external BGP router, and red lines are iBGP sessions amongst BGP speakers and SDN-IP instances.

Each external BGP router peers with one or more internal BGP speakers. SDN-IP does not currently support multihop BGP for external peering sessions, so each peering sessions must take place in the same subnet. Different peering sessions can be in different subnets however. In order to peer with external routers, the SDN network needs an IP address for each peering session. The IP addresses on the SDN network side are assigned to the BGP speakers so they can peer. It is not required that each internal BGP speaker peer with each external router, because the BGP speakers can redistribute routes between themselves using iBGP. However, for fully redundant peering with external networks, an external peer should have peering sessions with multiple internal BGP speakers. This can be seen in the figure where BGP router 1 has a peering session to each internal BGP speaker.

Inside the network the BGP speakers peer with SDN-IP instances (running on ONOS) using iBGP. SDN-IP is a passive iBGP peer - it listens to BGP updates but never advertises updates of its own. iBGP peering sessions within the network can be set up in multiple ways. The easiest way is to have a full mesh of iBGP peering sessions between the BGP speakers and the SDN-IP instances. This can be seen with the red iBGP peering sessions in the figure. In this way, all BGP nodes within the network can learn all the routes. Note it is not necessary (or possible) to have iBGP sessions between two SDN-IP instances, because the SDN-IP instances never advertise routes of their own.

Router Abstraction

sdfdsfds

Configuration

SDN-IP currently uses a simple JSON file format to import configuration data. There are two separate files: addresses.json for IP and MAC address data, and sdnip.json for BGP peering session data.

...

Network configuration files

These configuration files need to be placed in the config directory. Currently this is located at KARAF_ROOT/../config, and the path is not currently configurable.

When using the ONOS cell mechansim to deploy and ONOS cluster, the config files can be placed in ONOS_ROOT/tools/package/config. Then they will be automatically be copied to the correct location on the cell instances when the cluster is deployed.

There are two simple JSON files for configuring the network:

• addresses.json is used to configure IP and MAC addresses.
• sdnip.json is used to configure BGP peering sessions.

IP and MAC addresses

The addresses.json file is used to configure the addresses that ONOS uses to talk with the outside world. This configuration is mainly used for proxy ARP, so that the proxy ARP module knows how to respond to ARP requests coming from outside the network.

...

When running SDN-IP, each address used by the SDN network to peer with an external router needs to be configured in the addresses.json file.

...

BGP configuration

The sdnip.json file contains details of the BGP peering sessions, as well as the connectivity between internal BGP speakers and external BGP peers.

...