Loading ...
Sorry, an error occurred while loading the content.
 

Is DHCP really a problem for BACnet/ip and BACnet ?

Expand Messages
  • Buddy Lott
    All, I was pondering this question last night and I started putting some pieces together that I thought I would share. Here are my pieces: 1) DHCP would
    Message 1 of 1 , Feb 8, 2006

      All,

       

      I was pondering this question last night and I started putting some pieces together that I thought I would share. Here are my pieces:

       

      1)      DHCP would probably not work really well if modern OSs , RTOSs & libraries didn’t handle an IP address change in a useful manner.

      2)      2 of the last 3 OS  I have used, allow the programmer to write code to catch and process DHCP changes.

      a.       The third might, but I haven’t looked.

      3)      The MAC address (which is the IP address and port for BACnet/IP)  is really the important part of any change.

      4)      I am told some vendors already support auto MAC addressing for MS/TP. Is DHCP really all that different? In fact, some already support auto-Network Numbering.

      5)      NAT is going to cause problems regardless of  DHCP.

      6)      Although DHCP can cause spontaneous address changes, it typically doesn’t.

       

      When I put all the pieces together, I came up with this solution to DHCP:

       

      1)      Add a clause to state that all devices ( my definition defines a device as having a device instance) send an I-Am message on all MAC address changes.

      a.       this would include Ethernet and MSTP and support dynamic address schemes here

      2)      Add a clause that states all routing devices will send an I-Am-Router-To-Network message on all MAC address changes.

      a.       this would include Ethernet and MSTP and support dynamic address schemes here.

      3)      Add a clause (if there is not one already) that states all device binding tables will update on I-Am & I-Am-Router-To-Network messages.

      a.       Only those entries referencing the device instance would need to change.

      b.      Only those entries reference networks in the I-am-Router-To-Network message would need to change.

      c.       Both of these should already be done to better support network architecture changes.

                                                                     i.      Half-Router commanding is a good example of this issue.

      4)      Add a clause (if there is not one already) that states all device binding entries that “appear” to not work should :

      a.        trigger rediscovery if Who-Is/I-Am is supported

                                                                     i.      (OPTIONAL?) An event notification would be great  since it could tip off the user to other problems.

                                                                   ii.      (OPTIONAL?)  some kind of “discover not successful) alarm/event would be great since it could tip off the user to other problems.

      b.      Trigger an alarm/event if Who-is/I-Am is NOT supported.

      5)      Add a clause that states Foreign Devices that support DHCP CANNOT use a permanent TTL.

      a.       Permanent TTL is bad from a NAT perspective anyways.

      6)      Add a clause that states Foreign Devices must re-register on all MAC address changes.

       

       

      I think the above “solution” fixes all the problems (and more) that are caused by DHCP with the exception of BBMD related problems.

       

      My temptation for BBMD:

      1)      Add a clause that states a BBMD must update its own BDT entry with the new address resulting from a MAC change.

      a.       I like this with respect to manual and DHCP related IP/Port address changes.

      2)      Add a clause that states a BBMD must do a Write-Broadcast-Distribution-Table to all other BBMDs when a MAC changes.

      a.       I cringe at this last part. I see too many race conditions that can cause major problems.

      b.      My temptation would be to have a Update-Broadcast-Distribution-Table message that would have the old address and the new. This would reduce/eliminate the race conditions if define correctly.

      c.       I like the purpose with respect to manual and DHCP related IP/Port address changes.

       

      I don’t address NAT issues in anywhere in this solution. I think this is a separate and much harder problem.

       

       

       

      *******************************************************************

       

      Buddy Lott
      Firmware Design Engineer
      19476 Industrial Dr .
      New Paris , IN 46553
      574.831.5250 x 197
      blott@...

       

      ******************************************************************* 

       

       

                                                          **********************************************************************

      This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify your system manager.

      This footnote also confirms that this email message has been scanned for the presence of computer viruses.

                                                          **********************************************************************

    Your message has been successfully submitted and would be delivered to recipients shortly.