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

IT-WG request for comments by August 15

Expand Messages
  • James F. Butler
    Dear IT-WG members, During our recent meeting in San Antonio, Bernhard Isler requested feedback on his two proposals that are under consideration by the IT-WG,
    Message 1 of 3 , Jul 18, 2012
    • 0 Attachment

      Dear IT-WG members,

       

      During our recent meeting in San Antonio , Bernhard Isler requested feedback on his two proposals that are under consideration by the IT-WG, BI-040-3 and BI-041-2.  These documents can be downloaded from our TWiki’s Meetings page (http://bacnetit.cimetrics.com/bin/view/BACnetIT/Meetings), Attachments section.  Bernhard would like to receive your comments by August 15 so that all comments can be taken into consideration as Bernhard drafts revised versions of those two proposals.

       

      I would prefer that post your comments to the IT-WG e-mail list (bacnet-it-wg@yahoogroups.com).  However, you may also write directly to Bernhard.

       

      Our tentative plan is to review Bernard’s revised proposals during a teleconference in late September or early October.

       

      Regards,

       

      - Jim Butler

      BACnet IT-WG Convener

       

       

       

    • Hartman, John
      Attached are markups of BI-040-3 and BI-041-2 with some comments. Two big topics seem to be various issues about addresses, both unicast and multicast; and
      Message 2 of 3 , Aug 9, 2012
      • 0 Attachment

        Attached are markups of BI-040-3 and BI-041-2 with some comments.

         

        Two big topics seem to be various issues about addresses, both unicast and multicast; and UETs.

         

        Addressing:

        For the most part, addresses are “hidden”: the application will use the UET.DeviceID  or a URI, and resolution to an IP address can be done by the BACnet stack.  But the Network Port object requires a datalink to specify its address as a property.  Thus, some sort of address must be made visible for NTB.  And the Device Object has a Device/Address binding property that also exposes addresses.

         

        The VMAC was introduced to avoid defining addresses longer than 7 octets.  This was primarily done to limit the size of the network header, but to the extent that a legacy device can read these address from an NTB device, and such devices are likely NOT to accept 16-octet IPv6 addresses, we need to think about length and format for them, at least as translated by a Proxy and seen from a BIN.

         

        In existing BACnet, network number can often be a convenient way to group devices: a bunch of MS/TP VAV boxes connected to a supervisory controller can be discovered by directing Who-Is broadcasts to that network.  The equivalent on NTB would require setting up multicast addresses on each device, which might require use of a service tool when none was previously required.  Is group-by-network common enough to be worth preserving/translating in some fashion, or is that old-think?

         

        UET:

        How "unique" are the UETs?  Per-installation?  Per vendor?  Globally?

         

        6.2.4 says "Including the BACnet Vendor ID into the UET is an approach for globally unique identification of BACnet NTB devices".  But it also says "Exchanging the HW of a device should not cause the UET to change", which implies that the UET can be changed in the field, as during a replacement and are NOT globally unique like an Ethernet address.

         

        6.3.1 uses a UET in a multicast address.  It would seem that some or many multicast groups would NOT be all of the same vendor's devices.  So this UET seems to have different rules than the UET described in 6.2.4.  Is this the SAME UET as 6.2.4, or do multicasts use a separate UET or set of UET?  It (or at least some of them) would need to be assigned and configured on the job site.

         

        I can imagine that vendor X might want to pre-configure their devices at the factory with a UET:multicast group “All Vendor X devices”.  But there will also need to be “all lighting devices in building X” and the like configured at installation time.

         

         




        The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.
      • James F. Butler
        I would like to remind everyone that Bernhard would like to receive your comments on BI-040-3 and BI-041-2 by August 15. Please send your comments to
        Message 3 of 3 , Aug 10, 2012
        • 0 Attachment

          I would like to remind everyone that Bernhard would like to receive your comments on BI-040-3 and BI-041-2 by August 15.  Please send your comments to bacnet-it-wg@yahoogroups.com as John has done.

           

          Thanks,

           

          - Jim Butler

           

           


          From: bacnet-it-wg@yahoogroups.com [mailto: bacnet-it-wg@yahoogroups.com ] On Behalf Of Hartman, John
          Sent: Thursday, August 09, 2012 5:35 PM
          To: bacnet-it-wg@yahoogroups.com
          Subject: [bacnet-it-wg] Comment on BI-040-3 and BI-041-2

           




          Attached are markups of BI-040-3 and BI-041-2 with some comments.

           

          Two big topics seem to be various issues about addresses, both unicast and multicast; and UETs.

           

          Addressing:

          For the most part, addresses are “hidden”: the application will use the UET.DeviceID  or a URI, and resolution to an IP address can be done by the BACnet stack.  But the Network Port object requires a datalink to specify its address as a property.  Thus, some sort of address must be made visible for NTB.  And the Device Object has a Device/Address binding property that also exposes addresses.

           

          The VMAC was introduced to avoid defining addresses longer than 7 octets.  This was primarily done to limit the size of the network header, but to the extent that a legacy device can read these address from an NTB device, and such devices are likely NOT to accept 16-octet IPv6 addresses, we need to think about length and format for them, at least as translated by a Proxy and seen from a BIN.

           

          In existing BACnet, network number can often be a convenient way to group devices: a bunch of MS/TP VAV boxes connected to a supervisory controller can be discovered by directing Who-Is broadcasts to that network.  The equivalent on NTB would require setting up multicast addresses on each device, which might require use of a service tool when none was previously required.  Is group-by-network common enough to be worth preserving/translating in some fashion, or is that old-think?

           

          UET:

          How "unique" are the UETs?  Per-installation?  Per vendor?  Globally?

           

          6.2.4 says "Including the BACnet Vendor ID into the UET is an approach for globally unique identification of BACnet NTB devices".  But it also says "Exchanging the HW of a device should not cause the UET to change", which implies that the UET can be changed in the field, as during a replacement and are NOT globally unique like an Ethernet address.

           

          6.3.1 uses a UET in a multicast address.  It would seem that some or many multicast groups would NOT be all of the same vendor's devices.  So this UET seems to have different rules than the UET described in 6.2.4.  Is this the SAME UET as 6.2.4, or do multicasts use a separate UET or set of UET?  It (or at least some of them) would need to be assigned and configured on the job site.

           

          I can imagine that vendor X might want to pre-configure their devices at the factory with a UET:multicast group “All Vendor X devices”.  But there will also need to be “all lighting devices in building X” and the like configured at installation time.

           

           

           



          The information contained in this message is privileged and intended only for the recipients named. If the reader is not a representative of the intended recipient, any review, dissemination or copying of this message or the information it contains is prohibited. If you have received this message in error, please immediately notify the sender, and delete the original message and attachments.

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