2/25

BACnet/IP - Some basic design criteria...

The most basic consideration is that BACnet/IP devices should behave conceptually like all other BACnet devices in terms of their network activities:

• they should be able to communicate directly with peer devices on their network;
• they should be able to make use of local broadcasts, received by all peer devices on their network;
• they should be able to send remote broadcasts to devices residing on networks with different network numbers;
• and global broadcasting should still work as it does today.

Similarly, routers on B/IP networks should respond to the same network layer messages and perform the same functions as current routers. The implications of these assumptions will hopefully become clear as you work through these slides.

Here are two fundamental assumptions about BACnet devices that we make use of:

• Devices have a unique address, in this case an IP address, and they know what that address is.
• Devices do not know, or at least do not need to know, their BACnet network number (unless the device is a BACnet router).

BACnet/IP uses the User Datagram Protocol (UDP), a connectionless protocol. Here is why UDP was chosen:

• UDP is well supported and has a clean API for all operating systems.

  The ability to leverage an existing code base on a new platform is very important, so the socket library is usually one of the first software components to get ported and all the rest of the IP services come along for the ride.

• TCP, a connection-oriented protocol, has significantly more overhead than UDP and does not allow "one-to-many" messages.

  Other stream oriented protocols, such as ATM, suffer from the same problem. IP over ATM attempts to solve part of this by establishing a connection (called a 'call') for packets to 'new' destinations and keeping the connection open for a while, in a sense caching the connection. This is bad news for connectionless protocols like SNMP that are layered on UDP because there is call setup and closedown overhead for each packet.

• The definition of a new IP packet type (with a new protocol value) would provide no substantial advantage, and some potential disadvantages relative to the use of UDP.

  While extending the kernel for an OS is possible, most application developers want to stay as far away as they can from embedding software with all of the OS and platform specific problems that implies. It also reduces the ability to write portable code. The Berkeley Socket Library, for example, is supported in some form on all common IP platforms while a new IP protocol type would not be.

• A new IP protocol type might not be routable.

  While the market for BACnet/IP devices and support may be huge by some standards, it will most likely never be of the size and scale of other Internet software applications. Existing router manufacturers would probably be happy to include routing of custom packet types, but only for a price.

• Current firewalls do not pass new packet types.

  Even given the earlier assumption that firewalls do not need to allow BACnet/IP packets through, cooperating with existing technology is a consideration.

In the course of this presentation we will show that UDP provides all the power required to construct BACnet/IP internetworks of nearly any architecture.

2/25