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

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

Expand Messages
  • Roland Laird
    I too have recently been thinking about broadcasts in IP. I would like to eliminate the BBMD as we know it. I agree with Duffy that we should reconsider the
    Message 1 of 7 , Dec 1, 2009
    • 0 Attachment

      I too have recently been thinking about broadcasts in IP. I would like to eliminate the BBMD as we know it.  I agree with Duffy that we should reconsider the approach of RL-003 which just maintains status quo.  

       

      I don’t have any problems with broadcasts or multicasts on a local segment, but don’t think we should go to the BBMD trouble to extend broadcasts through IP routers.  The indirection created by a BBMD forwarding other devices broadcasts is troublesome. As long as each subnet is a separate BACnet network directed broadcasts would be sufficient to reach all devices.  

       

      Roland Laird

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
      Sent: Tuesday, December 01, 2009 4:22 PM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of broadcast

       

       

      Bill, Duffy, et al,

       

      I hope to have a re-draft of RL-003-10 before the Orlando meetings.  I'll distribute it to this list for discussion prior to the meetings. 

       

      However, what I'd like to do before then is to get together a list of goals.  For example, eliminate broadcasts.  Another example is how to handle "Jumbo payload" with our current APDU size rules.  IMHO, it would be wrong to restrict IPv6 packets to 1497 bytes. 

       

      I certainly hope to address and adopt the "IPv6 way" of eliminating broadcasts sooner rather than later.  IPv6 doesn't even allow the ability for an implementation to globally broadcast the way we do today, anyway.  There is a "link-scope all-hosts multicast" address (ff02::1), which corresponds to the subnet broadcast address 255.255.255.255 but this is used strictly for multicast.  Multicast is not optional in IPv6 like IPv4.

       

      IPv6 also introduced the use an anycast address.  How will that concept be used in BACnet going forward?  What about security in IPv6?  Use of IPsec is mandatory in IPv6.  How does that impact NS?  These are all questions this group will have to work into this proposal.

       

      These are just a few of the things that we cannot and must not ignore going forward with IPv6.  Otherwise, let's just make some IPv6 to IPv4 gateways and call it a day.  I, for one, don't think that's the correct approach at all. 

       

      Of course, I have no intentions of doing this all before or at Orlando (it's too big of a bite), but we'll need to have some discussion points going forward. 

       

      Coleman

       

      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Swan, Bill
      Sent: Tuesday, December 01, 2009 4:50 PM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: RE: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of broadcast

       

       

      Duffy et al,

      "I am not thoroughly versed in the pros and cons of broadcast..."

      Speaking from Alerton's perspective and experience with some very large
      systems, it would be A Very Good Thing if we could eliminate broadcasts,
      particularly global broadcasts.

      Bill Swan
      Honeywell
      Buildings Standards Initiatives Leader - LEED AP
      Alerton & Honeywell
      6670 - 185th Ave NE, Redmond, WA 98052, USA
      +1 (425) 897-3981
      http://BACnetBill.blogspot.com

      -----Original Message-----
      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
      On Behalf Of Duffy OCraven
      Sent: Tuesday, December 01, 2009 1:42 PM
      To: bacnet-ip-wg@yahoogroups.com
      Subject: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination
      of broadcast

      Introduction of routing support for IPv6 as described in RL-003-10,
      specifies using Virtual MAC Addressing (Annex H.X)

      It then goes on to specify functions in concept identical to the
      BACnet/IP network type (Annex J) with respect to the inclusion of the
      BACnet Virtual Link Layer (BVLL) described in Annex J.2. BACnet
      broadcasts are replaced by the appropriate scope IPv6 multicasts.

      When Annex H and Virtual MAC Addressing for Zigbee was being introduced,
      I foresaw this being the advent of BACnet data-link layers which did not
      use broadcast for device address binding, relegating that device address
      binding step to the routers by maintaining a map from BACnet Device ID
      to address in the local network data-link layer technology, as Zigbee
      does in Annex H.

      IPv6 could go that route as well. I am not thoroughly versed in the pros
      and cons of broadcast, nor in how well the combination of BBMDs, FDTs,
      ARP, and Annex J have served the BACnet community. Those on the outside
      looking in, however, who are familiar with the IT world but who have
      also participated in and commented in BACnet-L, seem to see that the
      better road forward would be for BACnet to be more like the myriad
      technologies that work without broadcast.

      I wanted to at least put it into consideration, at this point in time
      when our support for IPv6 is nascent, as this is an opportunity for
      elimination of broadcast in another BACnet specified data-link layer
      technology. And even if we do not choose complete elimination of
      broadcast, we can alternately at least not use broadcast in our primary
      mechanism for device address binding. Does the Zigbee address binding
      approach in Annex H work well? Can that approach be just as well
      implemented in the IPv6 specification?
      - Duffy O'Craven

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

      Yahoo! Groups Links





      ************************************************************************************
      This footnote confirms that this email message has been scanned by
      PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
      ************************************************************************************

    • Buddy Lott
      All, While I dislike the rampant use of global-broadcast, they do have their place. Before you can remove BBMDs and global broadcast, you have to consider
      Message 2 of 7 , Dec 2, 2009
      • 0 Attachment

        All,

         

        While I dislike the rampant use of global-broadcast, they do have their place.  Before you can remove BBMDs and global broadcast, you have to consider several scenarios:

         

        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.

        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 really like the idea of being able to use multicasting, but as I recall there is/was a fair amount of setup involved and required IT support. I don’t know how that would fly on some sites.

         

        I like the idea of big packet sizes for “JUMBO” messages but I have been in on troubleshooting sessions when problems arose when intermediate routers/devices did not like the sizes or segmentation.

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

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

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


        From: Roland Laird [mailto:rlaird@...]
        Sent: Wednesday, December 02, 2009 1:23 AM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: RE: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of broadcast

         

         

        I too have recently been thinking about broadcasts in IP. I would like to eliminate the BBMD as we know it.  I agree with Duffy that we should reconsider the approach of RL-003 which just maintains status quo.  

         

        I don’t have any problems with broadcasts or multicasts on a local segment, but don’t think we should go to the BBMD trouble to extend broadcasts through IP routers.  The indirection created by a BBMD forwarding other devices broadcasts is troublesome. As long as each subnet is a separate BACnet network directed broadcasts would be sufficient to reach all devices.  

         

        Roland Laird

         

        From: bacnet-ip-wg@ yahoogroups. com [mailto:bacnet- ip-wg@yahoogroup s.com] On Behalf Of Coleman Brumley
        Sent: Tuesday, December 01, 2009 4:22 PM
        To: bacnet-ip-wg@ yahoogroups. com
        Subject: RE: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of broadcast

         

         

        Bill, Duffy, et al,

         

        I hope to have a re-draft of RL-003-10 before the Orlando meetings.  I'll distribute it to this list for discussion prior to the meetings. 

         

        However, what I'd like to do before then is to get together a list of goals.  For example, eliminate broadcasts.  Another example is how to handle "Jumbo payload" with our current APDU size rules.  IMHO, it would be wrong to restrict IPv6 packets to 1497 bytes. 

         

        I certainly hope to address and adopt the "IPv6 way" of eliminating broadcasts sooner rather than later.  IPv6 doesn't even allow the ability for an implementation to globally broadcast the way we do today, anyway.  There is a "link-scope all-hosts multicast" address (ff02::1), which corresponds to the subnet broadcast address 255.255.255. 255 but this is used strictly for multicast.  Multicast is not optional in IPv6 like IPv4.

         

        IPv6 also introduced the use an anycast address.  How will that concept be used in BACnet going forward?  What about security in IPv6?  Use of IPsec is mandatory in IPv6.  How does that impact NS?  These are all questions this group will have to work into this proposal.

         

        These are just a few of the things that we cannot and must not ignore going forward with IPv6.  Otherwise, let's just make some IPv6 to IPv4 gateways and call it a day.  I, for one, don't think that's the correct approach at all. 

         

        Of course, I have no intentions of doing this all before or at Orlando (it's too big of a bite), but we'll need to have some discussion points going forward. 

         

        Coleman

         

        From: bacnet-ip-wg@ yahoogroups. com [mailto:bacnet- ip-wg@yahoogroup s.com] On Behalf Of Swan, Bill
        Sent: Tuesday, December 01, 2009 4:50 PM
        To: bacnet-ip-wg@ yahoogroups. com
        Subject: RE: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of broadcast

         

         

        Duffy et al,

        "I am not thoroughly versed in the pros and cons of broadcast..."

        Speaking from Alerton's perspective and experience with some very large
        systems, it would be A Very Good Thing if we could eliminate broadcasts,
        particularly global broadcasts.

        Bill Swan
        Honeywell
        Buildings Standards Initiatives Leader - LEED AP
        Alerton & Honeywell
        6670 - 185th Ave NE , Redmond , WA 98052 , USA
        +1 (425) 897-3981
        http://BACnetBill. blogspot. com

        -----Original Message-----
        From: bacnet-ip-wg@ yahoogroups. com [mailto:bacnet-ip-wg@ yahoogroups. com]
        On Behalf Of Duffy OCraven
        Sent: Tuesday, December 01, 2009 1:42 PM
        To: bacnet-ip-wg@ yahoogroups. com
        Subject: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination
        of broadcast

        Introduction of routing support for IPv6 as described in RL-003-10,
        specifies using Virtual MAC Addressing (Annex H.X)

        It then goes on to specify functions in concept identical to the
        BACnet/IP network type (Annex J) with respect to the inclusion of the
        BACnet Virtual Link Layer (BVLL) described in Annex J.2. BACnet
        broadcasts are replaced by the appropriate scope IPv6 multicasts.

        When Annex H and Virtual MAC Addressing for Zigbee was being introduced,
        I foresaw this being the advent of BACnet data-link layers which did not
        use broadcast for device address binding, relegating that device address
        binding step to the routers by maintaining a map from BACnet Device ID
        to address in the local network data-link layer technology, as Zigbee
        does in Annex H.

        IPv6 could go that route as well. I am not thoroughly versed in the pros
        and cons of broadcast, nor in how well the combination of BBMDs, FDTs,
        ARP, and Annex J have served the BACnet community. Those on the outside
        looking in, however, who are familiar with the IT world but who have
        also participated in and commented in BACnet-L, seem to see that the
        better road forward would be for BACnet to be more like the myriad
        technologies that work without broadcast.

        I wanted to at least put it into consideration, at this point in time
        when our support for IPv6 is nascent, as this is an opportunity for
        elimination of broadcast in another BACnet specified data-link layer
        technology. And even if we do not choose complete elimination of
        broadcast, we can alternately at least not use broadcast in our primary
        mechanism for device address binding. Does the Zigbee address binding
        approach in Annex H work well? Can that approach be just as well
        implemented in the IPv6 specification?
        - Duffy O'Craven

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

        Yahoo! Groups Links





        ************ ********* ********* ********* ********* ********* ********* ********* *********
        This footnote confirms that this email message has been scanned by
        PineApp Mail-SeCure for the presence of malicious code, vandals & computer viruses.
        ************ ********* ********* ********* ********* ********* ********* ********* *********

      • 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 3 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 4 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.