1. Naming, Addressing, & Discovery
BACnet IT
Naming, Addressing, & Discovery

2. Identifying things Devices Objects Properties Device ID Device Name
Network address (network + “MAC” address)
Objects
Object Name
Object ID (Object Type + Object Instance Number)
Properties
Property ID

3. Identifying things Three ways of identifying a device causes problems
Difficult to keep all three device “identifiers” unique and consistent with each other
Some vendors ensure Device ID is unique, others only ensure the name is unique
It’s difficult to avoid collisions in a small namespace (e.g. Device ID, network number)
Brittle – BACnet clients can persist any of the three identifiers, so
Changes at the network level (e.g. IP address change) can break things at the BACnet level (BBMDs, COVs)
The requirement that the naming tuple (ID, Name, Address) be stable makes it difficult to change any part

4. Network Address issues
Network address <-> Device ID <-> Device Name
One to one to one mapping makes it difficult to host more than one BACnet device on a single physical device
To workaround device must create its own virtual network
Adds complexity
Exacerbates network address space management issues
It’s difficult to keep small integer namespace unique
Merging two networks almost certainly requires renumbering Device IDs, Network numbers
BACnet’s “MAC” layer addresses leak into upper layers
Doesn’t work with NATs

5. Why multiple identifiers?
Most BACnet operations (e.g. Read Property) just use the network address
The rest of the identifiers are only there to support multiple forms of discovery:
Lookup by Device ID (Who-is)
Lookup by Device Name (Who-Has)
Lookup by Network address (Device Object 222-1)

6. Naming rules
No restriction on characters that can appear in a BACnet name
In theory quotes, slashes and other problematic characters could appear in names
Limits toolset available to programmers for handling BACnet names
BACnet supports several character encodings
E.g. ANSI X3.4, DBCS
Could potentially be an interoperability issue
Different vendors allow different max lengths
Could be impediment to interoperability

7. BACnet IT naming What can we do to improve the situation in BACnet IT?
Have one way to name a device, not three
Be clear about what should be persisted and what shouldn’t
Persist names, not addresses!
Make it easy to support multiple devices on a single “host”

8. Naming recommendations
BACnet devices should only have names
Impose reasonable syntax restrictions
Borrow rules from some other spec – e.g. only what’s allowed in an XML NMTOKEN, or a DNS hostname?
Use Unicode
Specify a single industry wide max length
Describe the procedure for obtaining a network address from a BACnet device name
Copy obvious design paradigm from URLs
Host name part is looked up via DNS
Recommended that IP addresses not be persisted long term except in unusual cases

9. Use URLs for names? Why not? Very successful for the web
Are there advantages to being able to identify host, device, object, and property in one string?
Can name just host, or host+device, or host+device+object, or host+device+object+property
Potential synergy with upcoming new BACnet Web Services specification

10. URI/URLs E.g.: We probably do not want to fix the hierarchy levels:
bacnet://host/device/object/property
We probably do not want to fix the hierarchy levels:
bacnet://host/building/floor/device/object
Alternative example of a single device on a host:
bacnet://host/object/property

11. Multiple devices per host
This isn’t hard if it’s part of your naming scheme
bacnet://host/device1/object/property
bacnet://host/device2/object/property
But it should also be possible to do:
bacnet://host1/object/property
bacnet://host2/object/property
host1 & host2 could each resolve to the same IP address
DNS has no problem supporting arrangements like this
But some unfortunate design designs on the web have confused this issue

12. Several web sites, one host
A single IP host can have as many DNS names as you want
Can have many “A” records resolve to the same IP address
Or use CNAME records (recommended)
This works fine for http
Hostname portion of the URL is looked up in DNS
Get an IP address
Open a TCP connection to the web server (port 80)
Send an http GET command, & include the full URL being requested
E.g.: GET //ocw.mit.edu/index.htm instead of just: GET /index.htm
If is located on the same server as ocw.mit.edu, the web server can parse the GET URI to determine which web site is being requested

13. SSL is the problem https uses SSL, not TLS
SSL establishes the secure connection before any information is exchanged
So when the web server provides your web browser with its authentication certificate, it doesn’t yet know what web site you wanted
So its only choice is to give you a default certificate for the whole web service on that host
E.g. you wanted for ocw.mit.edu, but the certificate says “
So your web browser puts up a warning
Workarounds: “wildcard” names in certificates (but now many hosts share a secret), or Subject Alternative Names (need to know all possible names when certificate is issued)

14. Avoid it with TLS TLS first establishes a TCP connection
So the conversation can start by identifying which “web site” (or BACnet device) is being requested, before the authentication step
The tradeoff is that this name is sent in the clear
SMTP works this way
For BACnet, we would probably want to send only the device name in the clear
Then establish a secure TLS connection and then specify the object & property names being requested

15. These names are too long
I miss my compact device ID/Network address!
There are ways to deal with this
Allow the use of short-identifiers (e.g. 32-bit numbers) to name devices, objects, or properties
But only to help transmission efficiency
Limited lifetime – no long-term persistence!
But how to manage lifetime?
In a connection-oriented architecture, short identifiers would only be valid as long the connection was open
To be efficient – keep a nailed up TCP (or TLS) connection to those you converse with often
Look up the property you reference a lot once, and for the rest of the conversation just use the token
If/when the connection drops, the token becomes invalid