SDN-based multi-domain Bandwidth on Demand

This demonstrator shows how the Géant solution based on the DynPaC framework provides multi-domain bandwidth on demand services involving SDN domains relying on the NSI-CS protocol. The scenario that we are going to use is composed of three different domains. The first domain is located in Cambridge LAB and uses the DynPaC framework running as an ONOS application. DynPaC is an advanced traffic engineering framework for SDN able to provide resilient layer 2 services. The second domain is Géant BoD an MPLS network that uses AutoBAHN as provisioning tool. The third domain is located in AMRES a 5 node full mesh network with Open VSwitches that also uses the DynPaC framework. End-to-end services across these three domains are provided thanks to the NSI-CS protocol. A protocol widely used for multi-domain BoD. regardless of the underlying networking technology. The DynPaC framework includes a REST interface to communicate with the Network Services Agents that are in charge of the multi-domain aspects of this solution. This is the topology of the Cambridge domain. Two corsa switches are used as edge nodes to enforce rate limiting. No services are enabled yet in the devices and the DynPaC application is active in ONOS. This is the topology in the AMRES domain. where no VLAN services are being provided yet in this domain and the dynpac application is up and running. The services will be requested through Géant BoD’s GUI. We select the start end-point and the VLAN that the requested service is going to use in this domain. We also specify the ending end-point and the VLAN that the service will use in the ending domain. If necessary, the Géant BoD domain will perform a VLAN translation. We specify the start and end times and the desired bandwidth. This service will not have resilience capabilities We do the same for the second service. This service will have a guaranteed backup path. DynPaC distinguishes two types of services: (1) Golden services with a guaranteed backup path (2) Regular services, without resilience capabilities. Services are already reserved in each domain but no flows have been installed yet. This will be done automatically at their start-time. Both services have been requested to enable the communication between two virtual machines. One located at the Cambridge premises and another one in the AMRES premises. Now that the services appear as provisioned, we can check at the AMRES ONOS that the flows for the services with VLANs 501 and 502 have been installed in the devices. Similarly, we can do the same in the Cambridge ONOS We can also check at the Corsa switches that 4 additional flows have been installed. so as the meters to limit the traffic to 20 and 50 Mbps. Now we are going to generate traffic for the two services between the two virtual machines. First, we can check how both virtual machines have interfaces created for VLANs 501 and 502. We start two iperf servers at the AMRES’s VM, bonded to the interfaces previously mentioned. In Cambridge, we generate two UDP streams using iperf. For the gold service, the one that uses the VLAN 501 we are going to generate a 50 Mbps stream. For the regular service that uses the VLAN 502, we are going to generate a 50 Mbps that the corsa switches are going to limit to 20 Mbps. Now at the corsas, we can check how the meters are working correctly, since the packets in the column marked as red are increasing, the packets in the column marked as red are increasing, these are packet that are being discarded by the switch. We can further demonstrate the rate limiting enforced at Cambridge lab with the corsa switches using the speedometer application. The gold service with VLAN 501 is received correctly at AMRES. But the regular service with VLAN 502 is being limited. If we modify the bandwidth of the gold service to 100 Mbps The Corsa switches will limit its traffic to 20 Mbps. In order to demonstrate the resilience capabilities of the DYNPAC framework we are going to eliminate the link that interconnects both corsa switches In order to do so, we disable the port 3 in the Corsa switch. If we check again the flows at each device we can see how the flows installed for vlan 501 the only one with resilience capabilities is now forwarded to one of the pica8 devices. At the pica8 switch, flows for the VLAN 501 have been installed. and the traffic has continued without disruption thanks to the resilience capabilities of DynPaC while the traffic exchange with the VLAN 502 has stopped.

Leave a Reply

Your email address will not be published. Required fields are marked *