IP Broadcasts are not routed...

One of the stated design goals is that a BACnet network can be composed of more than one IP subnet so that large campus-like installations don't consume a multitude of network numbers. As the Internet grew beyond a trival number of nodes, one of the first things done to trim traffic was to ensure that broadcasts are not routed. Many of BACnet's capabilities, such as dynamic name binding and unsolicitied change-of-value notification, stem from the use of broadcast messages, so there needs to be a way to support them in a distributed network.

This problem has come up before on the Internet, so one of our first thoughts was to search for an existing standard. The Internet Group Membership Protocol (IMGP) is specifically designed for multipoint multicast communications. Its design is based on work on the Multicast backBONE (MBONE) used to distribute audio and video teleconferencing.

The basic idea behind IGMP is that devices not only have a class A, B, or C address, but also respond to class D addresses. Class D addresses, where the upper bits of the IP address are '', are managed by routers similar to other IP addresses, except that a packet may be forwarded to more than one destination, possibly on different subnets.

There are a number of advantages to using IGMP:

As usual, there are also a number of disadvantages:

...so enter the BACnet Broadcast Management Device (BBMD)!

Given the low-volume considerations and non-ubiquitous availability of IGMP, we decided that although BACnet/IP should support the use of multicast as an option, another simpler mechanism was needed. To this end, a new device was created, coined a "BACnet Broadcast Management Device" (BBMD) by Jim Butler, which receives broadcast messages on one subnet and forwards them to another subnet. But how should be BBMDs be networked?