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

RE: IPv6 presents an opportunity for elimination of broadcast

Expand Messages
  • Duffy OCraven
    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
    Message 1 of 7 , Dec 1, 2009
    • 0 Attachment
      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
    • Swan, Bill
      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,
      Message 2 of 7 , Dec 1, 2009
      • 0 Attachment
        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
      • Coleman Brumley
        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.
        Message 3 of 7 , Dec 1, 2009
        • 0 Attachment

          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

        • 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 4 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 5 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 6 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 7 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.