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

Re: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of broadcast

Expand Messages
  • Joel Bender
    ... A good federated directory service could be stacked on top of our current services, similar to the way I-Am and I-Have can be cached. ... I ve been
    Message 1 of 7 , Dec 2, 2009
    • 0 Attachment
      Buddy wrote:

      > 1) Looking for objects by name, (i.e. doing a who-has for “Outside-Air-Temperature”)
      >
      > 2) Looking for devices by name, (i.e. doing a who-has for “Buddy’s brilliant device”)
      >
      > 3) Looking for a device by id doing a who-is for the device both when you now the remote network and when you don’t.

      A good federated directory service could be stacked on top of our current services, similar to the way I-Am and I-Have can be cached.

      > 4) A unsolicited broadcast event-notification (i.e. setting up a notification class and event-enrollment object to tell everyone something happened so maybe someone can handle it).

      I've been mucking around with the pubsubhubbub project <http://code.google.com/p/pubsubhubbub/> as a way to collect event notifications and re-distribute them to interested subscribers. It's a bit odd turning events into an atom feed, but perhaps there are some architectural bits that can be an inspiration.

      The most important pieces to me are (1) elimination of broadcast services, (2) using a simple confirmed service to notify the hub of new event(s), (3) the hub gathers the events according to its load, (4) publishers and subscribers are de-coupled but can still be centrally monitored, (5) hubs can be scaled vertically (multiple hubs in an organization) and horizontally (boosting the performance of a hub by upgrading the hardware, or using a "cloud" like App Engine), and last but not least, (6) I have to write very little code :-).


      Joel
    • Buddy Lott
      Joel, While I think I understand what you are saying and appreciate the effort, I also think that you need to be careful about creating a single point of
      Message 2 of 7 , Dec 2, 2009
      • 0 Attachment
        Joel,

        While I think I understand what you are saying and appreciate the effort, I also think that you need to be careful about creating a single point of failure.

        The issue also becomes circular. Let's assume for a second that we have a service X that eliminates the need for broadcast of type Y. How does service X gather information to implement that service? If the service is eliminating the need for broadcast Who-Is messages, how does IT discover all of the devices?

        Personally, I don't find broadcast to be as much of a problem as the way that people use them. For instance, sending a who-has request to every one seems pretty reasonable unless you are sending a who-has that everyone (or most) WILL respond too or you are sending it too often. The responses cause as many or more problems then the request. How many times have you seen a global broadcast "Who-Is" go out with an unlimited range? How many times have you seen the 'I-AM' response go out as a global broadcast?

        I think an important thing to clarify is whether you are talking about eliminating IP layer broadcast or BACnet App Layer broadcast.

        To me, some important goals of any BACnet-IP revision should be:

        1) Be NAT & PAT neutral. In other words, avoid using anything that may not be valid when crossing intranet and internet boundaries.
        2) Use host names (or URLs) for addressing instead of IP addresses. This allows for NAT & PAT neutral names and allowing for dynamic addressing support.
        3) Support dynamic addressing (DHCP).
        4) Support IP multicasting (this helps eliminate tradition broadcasting) & legacy BBMD.
        5) Minimize the need for IP level broadcasting and retransmitting while supporting BACnet App layer broadcast.
        6) Be respectful of the dynamic nature of IP versus Ethernet & MS/TP networks. Most intranets are using DHCP and are reconfigured as networks grow. Most intranet/internet boundaries use NAT/PAT. These can be easily (for the most part) reconfigured by IT people as network requirements change. Limiting the problems caused in BACnet when this happens should be a top priority.



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

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

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

        -----Original Message-----
        From: Joel Bender [mailto:jjb5@...]
        Sent: Wednesday, December 02, 2009 10:18 AM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: Re: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of broadcast

        Buddy wrote:

        > 1) Looking for objects by name, (i.e. doing a who-has for "Outside-Air-Temperature")
        >
        > 2) Looking for devices by name, (i.e. doing a who-has for "Buddy's brilliant device")
        >
        > 3) Looking for a device by id doing a who-is for the device both when you now the remote network and when you don't.

        A good federated directory service could be stacked on top of our current services, similar to the way I-Am and I-Have can be cached.

        > 4) A unsolicited broadcast event-notification (i.e. setting up a notification class and event-enrollment object to tell everyone something happened so maybe someone can handle it).

        I've been mucking around with the pubsubhubbub project <http://code.google.com/p/pubsubhubbub/> as a way to collect event notifications and re-distribute them to interested subscribers. It's a bit odd turning events into an atom feed, but perhaps there are some architectural bits that can be an inspiration.

        The most important pieces to me are (1) elimination of broadcast services, (2) using a simple confirmed service to notify the hub of new event(s), (3) the hub gathers the events according to its load, (4) publishers and subscribers are de-coupled but can still be centrally monitored, (5) hubs can be scaled vertically (multiple hubs in an organization) and horizontally (boosting the performance of a hub by upgrading the hardware, or using a "cloud" like App Engine), and last but not least, (6) I have to write very little code :-).


        Joel



        ------------------------------------

        Yahoo! Groups Links
      Your message has been successfully submitted and would be delivered to recipients shortly.