SRv6 - Linux Kernel implementation


Using SRv6

Testing

Development

Software Resolved Networks

References

edit SideBar

SRN

Filed in: SRN.SRN · Modified on : Thu, 07 Jun 18

Overview

Software Resolved Networks (SRN) are a variant of the SDN architecture. An SRN is a network that is managed by a logically centralized controller. The name SRN originates from the fact that the architecture co-locates its controller with a DNS resolver and uses extensions of the DNS protocol to interact with endhosts.

When an application initiates a conversation, it performs the following operations. First, it issues a DNS request to resolve the DNS server name and adds its requirements. In this example, the application wants to reach server.com through a path latency of at most 8ms.

Then, the controller chooses a network path that meets those requirements. The controller can use any optimization algorithm to select this path. Once the path is chosen, it is transformed into a list of SRv6 segments. The controller adds a rule in the access router to trigger encapsulation of an SRH on packets whose current segment is P1. Finally, the controller issues a DNS replies with the server address and the Path-ID P1 instead of the actual list of SRv6 Segments. This level of indirection enables the controller to change the offered path without communicating with the host, e.g. in case of link failure.

The application inserts an SRH in every packet with the Path-ID in the segment list. The access router adds to these packets the SRH enforcing their path.

Controller architecture

The controller is composed of several modules interacting with the actual controller through an OVSDB database. The network state daemon uses OSPF-TE to monitor the state of the network, i.e., bandwidth and latency of the links. It updates the database so that the SDN controller knows the topology of the network.

The DNS proxy is the interface between the endhost, the DNS resolver and the controller. It resolves the server name by interacting with the DNS server and encodes the request along with the DNS answer in the database.

The SDN controller processes the request and generates a Path-ID P1 along with the SRv6 Segment list matching the desired requirements. It encodes the flow information in the database. When the access router notices the change, it inserts the mapping between P1 and the SRv6 Segment list in its routing table. When the rule is installed, the DNS proxy sends back a DNS reply containing the P1 and the server address.

More details can be found in this article.

Source code

All sources for Software Resolved Networks is available at github.


Powered by PmWiki