LAN protocols often rely on multicast or broadcast to keep peers informed on their status. The basic assumptions that work for a LAN may become a problem when scaling up through a mechanism like the Funnel Tunnel. A generic solution is described in what follows.

A few example protocols are RIP (a very simple router-update protocol) and mDNS (a mechanism for announcing ZeroConfig services to peers). As can be seen from this, the approach is used for a broad range of applications, and it is not even an outdated practice.

Motivations behind Multicast

The reasons to rely on multicast are reasonable for a switched LAN, namely cheap and fast local traffic. Locally, there are no real restrictions on bandwidth, nor is there an associated financial cost.

In the case of RIP, an additional observation is that the number of routers connected to a network is usually rather limited. RIP tends to be used in small-network situations; backbones use smarter protocols.

A general reason why Multicast is desirable is that a sender can be blissfully unaware of who its recipients are; it can simply dump its information and be anyone interested takes the responsibility to pick it up. This has the advantage of simpliciy, especially because it saves configuration of the originator with all potential recipients. With that in mind, it should not come as a surprise that this mechanism was used as a basis for ZeroConfig.

Problems with Scaling Up

Multicast cannot run over TCP or even SCTP; it must run over UDP, or directly on top of IP or Ethernet. This means that Multicast is inherently unreliable; there is no builtin feedback, and it also is not very common for protocols to signal an acknowledgement back to the sender.

This means that the sender is unaware if the information sent has arrived with all recipients. Ideally, it should send the same information over and over, as often as possible.

However, when many nodes start to do the same, the network could easily get flooded with mere administrative minutia. So that puts a lower limit on the time between resends. An example where this already is a problem is with WiFi in condensed rural areas; there may be so many contenders on the same bandwidth that the (rather verbose) WiFi protocol clutters the sky and leaves ample room for data. Note that although WiFi networks are usually separate, their frequencies are not.

Sending information every now and then may also lead to updates being delayed to the next moment of change; it may take minutes for RIP routes to reach all nodes because it has a 30-second resend interval. This is a negative point from the perspective of use. But the more participants in a Multicast scheme, the longer these delays have to be.

Normally, Multicast is a LAN mechanism, and does not crossover to other parts of the network: bridges pass Multicast and Broadcast, but routers do not. That is, by default. There is often a desire to share the same information across network segments, so most Multicast protocols have facilities for passing it between routed interfaces. This is always subject to the concern of flooding the network with too much of the Multicasted information, and it is a realistic limitation to scaling up to larger networks.

Generic Solution

We are going to assume that Multicast is no problem at the local level; it is successfully applied in LANs all around the Internet. The problem with Multicast lies when crossing over to other realms.

Note that most information in a Multicast update is repeated information; updates do occur, but mostly it is a matter of avoiding that information gets dropped after a delay. This is a mechanism that can be seen in many, many protocols. Resends can be avoided, provided that a few constraints are met by the protocol:

• The protocol can be passed over a reliable delivery transport
• The protocol has an empty state for initial contact
• The protocol has a query mode which results in dumping all data

Based on this, a reliable delivery channel can be created, and of course SCTP is the best solution for that, because it is a datagram-delivery protocol, and thus closest to UDP. When connecting initially, the state may be assumed empty, but the sides will query for the data involved to change that. Updates do not have to be repeated because the transport is reliable, which saves bandwidth and at the same time enables instant updates.

Reliable delivery connections have explicity termination, in which case either the empty situation or the last-known good situation can be maintained for a configurable time. When re-opening the connection, queried data may even be used to replace the last-known good situation such that data does not disappear.

This provides a transport for Multicast and Broadcast information across networks, without a requirement that they are directly connected. This may call for additional encryption, but that has no impact on scalability.

When a protocol additionally supports explicit retrieval of data, it enables a filtered approach where all communication about the protocol ends up in a network-centric host that handles both GET and SET requests. This puts an end to polling-style behaviour, and only communicates information when it is needed.

Multicast works with explicit registration over MLD or IGMP. This provides an information base that can be used to further administer such processes, and even automate the filtering processes.

Implementation in the Funnel Tunnel

The Funnel Tunnel sits between networks, and may translate between SCTP and UDP and, where required, other IP patterns. It is therefore in a perfect position to handle Multicast centralisation.

To that purpose, the Funnel Tunnel can be setup with subscriptions to desired Multicast and Broadcast traffic on certain of its interfaces. It can detect resends of previously seen information, classify it as coming from the same origin and not forward it in such cases. Also, it can be configured with the various parameters that define a protocol, and detect timeouts like any other participant in the protocol, and then send an empty update to replace the old update.

Since some interfaces might represent multiple separated clients that all arrive over one channel, such as an interface to a dial-in construct or some virtualisation interfaces, there may be a requirement to facilitate hairpin-constructs; basically, this means that selected Multicast or Broadcast traffic should be bounced back to the sender, as well as forwarded to other recipients.

There may be more useful things the Funnel Tunnel could do, but that would be dependent on the protocol being forwarded. The best solution to that is probably to support plugins for such protocol handling. As an example, this could be where GET and SET operations could meet; this would be helpful for mDNS, and permit it to scale to very large numbers of nodes; effectively making mDNS distribute over much wider ranges than a mere LAN segment.

Migration Path for Originators and Recipipents

The parties that currently rely on repeated sends might choose to setup SCTP for their local service as well, to further improve the potential of passing on their information. In this case, the generic functions of the Funnel Tunnel are overtaken by the protocol endpoints, which then connect to remote sites either directly or through a Funnel Tunnel. This could use the same SCTP-based protocol, and its only disadvantage would be that configuration for external connectivity is made at the originator of a protocol.

Note that protocols may also find inspiration to actively support the model where SET can meet GET in the middle; this would for instance be interesting for SNMP, which is now a polling protocol.