Including a networking device in a niche application often introduces unique challenges. One way to handle these challenges is to use a flexible software implementation of the network stack. A recent customer project for an L3 Switch prompted the development of network protocols on a bare metal platform.
A networked system requires protocols to manage packet routes and increase efficiency. The Address Resolution Protocol (ARP) and Internet Group Management Protocol (IGMP) are two of the protocols used to manage a network. Implementing these protocols on bare metal meant that development was driven by the RFC standards. RFC standards are often written to describe a protocol that has already been implemented and is also generalized to be applicable to a variety of networks, so it was no small feat to take the description and translate it to a new application.
According to RFC 826, “The Address Resolution Protocol (ARP) is a communication protocol used for discovering the link layer address, such as a MAC address, associated with a given internet layer address, typically an IPv4 address.” Storing IPv4 to MAC address translation information is important for many reasons. If a host on the network needs to send an outgoing IPv4 packet, it must have the IPv4 and MAC information for its destination. If it does not, the host will send an ARP request with the MAC information that it has and wait for an ARP reply containing the corresponding IPv4 address. This information is stored in tables and times out if the entry is not refreshed. On a switch or router, ARP information is stored passively through ARP snooping and is used to make routing more efficient.
The standard for ARP (RFC 826) references packets and functions in pseudo code to guide the reader through what functionality should look like. Because the RFC is generalized to be applicable to multiple systems, there are some situations and corner cases that are not defined. To bridge these gaps, the behavior of a CISCO switch was observed. The developed switch functionality has similar configuration options and capabilities. A user can configure the amount of time a dynamic entry will stay in the switch’s ARP table, how often a refresh ARP request will be sent for a dynamic entry, and static entries in the switch’s table as well.
ARP covers one-to-one packet traffic, but some systems require a one-to-many send pattern. This is done through multicast groups and is managed by IGMP. IGMP is a communication protocol responsible for managing a host or router’s membership to certain multicast groups. IGMP cuts down on unnecessary traffic by pruning routes where no hosts have a membership to the relevant multicast group. With IGMPv3, the system can also do source-filtering on multicast traffic. This means that a host can request to be a member of a multicast group and receive those packets, but not if they come from a specific source or group of sources. It also allows the host to instead specify a source or group of sources that it does want to receive traffic from, while excluding all others.
The standard for IGMPv3 (RFC 3378) uses diagrams for packet structure and is generally very clear compared to the ARP RFC. It also details how IGMPv3 works with older versions of the protocol, which each have their own RFCs (RFC 1112 for v1, RFC 2236 for v2). Understanding the intricacies of IGMPv3 was the largest hurdle. The switch is backwards-compatible with versions 1 and 2 of IGMP, which introduces complexities in the implementation of the protocol. The switch keeps track of the version of membership reports that it receives and the version of other routers on the network.
Maintaining version compatibility, source filtering, and various timers are the trickiest tasks of IGMP. This was accomplished through detailed study of the standard along with observation of CISCO’s operation to fill in the gaps. Like ARP, this protocol aids in creating routes that reduce bandwidth usage by maintaining a map of the destinations that have requested multicast traffic.
Implementing ARP and IGMP without using external libraries preserves the flexibility of the system and allows for a simpler certification process for safety-critical applications. Certifying external libraries may require the certification and analysis of code that could potentially affect the system but does not contribute to the functionality.
If you are facing a networking challenge that requires deep technical expertise, schedule a meeting with us today. Our team with collaborate with you on a plan to turn your ideas into reality.
