Naming, Addressing, & Discovery BACnet IT Naming, Addressing, & Discovery

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

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

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

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)

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

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”

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

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

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

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

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 www.mit.edu 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

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 “www.mit.edu” 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)

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

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