One of the various problems we face in the data networking world is the absolute plethora of tunneling technologies we have available. Going way back to the beginning, there was SNA, GRE, IP-in-IP, and a host of others. In the midterm was have MPLS (though some will argue this isn’t a tunneling protocol — but the point is it can be used as a tunneling encapsulation) and 802.1q, and then more recently VxLAN, LISP, NVGRE, and — yet again — a host of others. Much of the problem around this plethora of protocols is not so much that people really like inventing new tunneling protocols, but rather that people have lots of ideas about how the control plane that overlays the base network should work.
And no new control plane seems complete without a shiny new tunneling protocol to match.
Geneve is, in this sense, a little different. Right in the beginning of the draft, it says hopeful things, like:
Existing tunnel protocols have each attempted to solve different aspects of these new requirements, only to be quickly rendered out of date by changing control plane implementations and advancements. Furthermore, software and hardware components and controllers all different advantages and rates of evolution – a fact that should viewed as a benefit, not a liability or limitation. This draft Geneve, a protocol which seeks to avoid these problems by providing a framework for tunneling for network virtualization rather being prescriptive about the entire system.
Geneve is a simple, flexible tunnel format designed for the overlay network case in a data center fabric, specifically when the underlay is IP — but probably applicable to just about any tunneling situation (other than the quasi-MPLS tunnel). There are a couple of interesting points to note about the tunnel header format.
First, the tunnel header is built more like an IPv6 header, or an IS-IS payload, than an IPv4 header. The basic fields are fixed length, making them easy to parse, but extension headers can be attached as needed to enable different functions. These extension headers are designed to be handled by the tunnel head and tail end only, making any switching based on the tunnel header fields (which should actually be minimal, as we’ll see in a minute) purely about processing the fixed length fields — meaning any necessary switching can be done in silicon.
Second, the tunnel header is actually carried inside a UDP header. The primary reason for this is to avoid problems with middle boxes, but it also allows Geneve to take advantage of the source port for it’s own purposes.
What is this rather interesting use of the UDP source port? As the source port isn’t really used to show the source application or process, it’s used as an entropy label. The value put in the source port is determined by the tunnel head end; the specification encourages using a hash across multiple fields in the packet header to ensure every packet in a single flow is hashed onto the same link at any given ECMP point.
Geneve — if it takes off — may actually clear the air a bit, allowing us to focus on the control plane of any given overlay, rather than the attendant tunnel format. As my old friend Armand used to say — does it work? Hopefully, with the long list of co-authors and supporters, it will.