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

Add. AI PPR2 Draft5 has been uploaded

Expand Messages
  • Coleman Brumley
    IP-WG, Please check the Yahoo group for the latest draft. Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will
    Message 1 of 9 , Jan 3, 2012
    • 0 Attachment

      IP-WG,

       

      Please check the Yahoo group for the latest draft. 

       

      Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

       

      Regards,

      Coleman

    • Carl Neilson
      Coleman et al, I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two
      Message 2 of 9 , Jan 4, 2012
      • 0 Attachment

        Coleman et al,

         

        I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two meetings ago. I hope that I can have the opportunity to argue the opposite position.

         

        My reasons for not agreeing are:

         

        1) The problem violates the network vs application layer separations in a manner far beyond simple knowledge transfer. When a device globally broadcasts its IAms, the application layer generates the IAm and passes it to the network layer, the network layer then has to modify the IAm for each port it is sent out. This requires that the network layer inspect every packet that is sent, and adjust the packet contents accordingly.

         

        This is unlike any other layer violation we have considered to date. To date, we have passed information through the layer API: does the service expect a response; the port was the service received on; indications of errors; security information; etc.

         

        2) The perceived problem only impacts inverted networks. In all other cases, either the PDU size will be accurate or will be limited by the directly attached network of the client.

         

        3) The problem is not solved for non-routers or distant routers. The inverted network issue will still exist for non-routers, and for routers not directly attached to the small intervening network.

         

        Carl

         

         

        From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
        Sent: Tuesday, January 03, 2012 7:27 PM
        To: bacnet-ip-wg@yahoogroups.com
        Subject: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

         

         

        IP-WG,

         

        Please check the Yahoo group for the latest draft. 

         

        Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

         

        Regards,

        Coleman

      • Hartman, John
        And my reasons for WANTING I-Am to contain a useful maxAPDU are 1) I-Am is (or was intended to be) the way clients determine how or if they need to
        Message 3 of 9 , Jan 4, 2012
        • 0 Attachment

          And my reasons for WANTING I-Am to contain a useful maxAPDU are

           

          1)      I-Am is (or was intended to be) the way clients determine how or if they need to segment of limit their requests.  Why not make it work?

          2)      Simple devices are generally single-port, so these issues apply only to routers or other multi-port devices, which by definition have greater capability

          3)      Global broadcast of I-Am should be deprecated, if not forbidden.  It makes sense for the relatively few routers on a site to broadcast I-Am-Router at startup.  It is a bad idea for 10000 MS/TP VAV boxes to do so.

          4)      Absent global broadcast, the logic of “which max APDU” goes in the incoming Who-Is handler, just like it would go into the incoming Read Property handler if we use the wildcard port instance

           

           

           

          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
          Sent: Wednesday, January 04, 2012 10:15 AM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

           

           

          Coleman et al,

           

          I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two meetings ago. I hope that I can have the opportunity to argue the opposite position.

           

          My reasons for not agreeing are:

           

          1) The problem violates the network vs application layer separations in a manner far beyond simple knowledge transfer. When a device globally broadcasts its IAms, the application layer generates the IAm and passes it to the network layer, the network layer then has to modify the IAm for each port it is sent out. This requires that the network layer inspect every packet that is sent, and adjust the packet contents accordingly.

           

          This is unlike any other layer violation we have considered to date. To date, we have passed information through the layer API: does the service expect a response; the port was the service received on; indications of errors; security information; etc.

           

          2) The perceived problem only impacts inverted networks. In all other cases, either the PDU size will be accurate or will be limited by the directly attached network of the client.

           

          3) The problem is not solved for non-routers or distant routers. The inverted network issue will still exist for non-routers, and for routers not directly attached to the small intervening network.

           

          Carl

           

           

          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
          Sent: Tuesday, January 03, 2012 7:27 PM
          To: bacnet-ip-wg@yahoogroups.com
          Subject: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

           

           

          IP-WG,

           

          Please check the Yahoo group for the latest draft. 

           

          Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

           

          Regards,

          Coleman




          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.
        • Coleman Brumley
          Carl, Of course you ll have an opportunity. Discussing this along with solutions is the only outstanding action item. The draft 2 language was not put back
          Message 4 of 9 , Jan 4, 2012
          • 0 Attachment

            Carl,

             

            Of course you'll have an opportunity.  Discussing this along with solutions is the only outstanding action item.   The draft 2 language was not put back into draft 5 because we recognized in the last teleconference that the debate needed to occur again. 

             

            However, I'm wondering if there's just not a simpler solution than either we've discussed?  In Draft 5 (and earlier drafts), there's a footnote X that says basically to use the  value from the NPO with the lowest instance in the case of multiple MS/TP ports.  Could we not just have similar language for max-apdu-length-accepted in the Device object and not touch the I-Am service description at all?  I'm likely over-simplifying the problem, but we could on for months about this very issue and potentially still not have a solution as it pertains to the NPO. 

             

            John's point about global broadcasts is well taken, and that issue/topic is LONG overdue, but is the NPO the right place for it? 

             

            Coleman

             

            From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
            Sent: Wednesday, January 04, 2012 11:15 AM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

             

             

            Coleman et al,

             

            I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two meetings ago. I hope that I can have the opportunity to argue the opposite position.

             

            My reasons for not agreeing are:

             

            1) The problem violates the network vs application layer separations in a manner far beyond simple knowledge transfer. When a device globally broadcasts its IAms, the application layer generates the IAm and passes it to the network layer, the network layer then has to modify the IAm for each port it is sent out. This requires that the network layer inspect every packet that is sent, and adjust the packet contents accordingly.

             

            This is unlike any other layer violation we have considered to date. To date, we have passed information through the layer API: does the service expect a response; the port was the service received on; indications of errors; security information; etc.

             

            2) The perceived problem only impacts inverted networks. In all other cases, either the PDU size will be accurate or will be limited by the directly attached network of the client.

             

            3) The problem is not solved for non-routers or distant routers. The inverted network issue will still exist for non-routers, and for routers not directly attached to the small intervening network.

             

            Carl

             

             

            From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
            Sent: Tuesday, January 03, 2012 7:27 PM
            To: bacnet-ip-wg@yahoogroups.com
            Subject: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

             

             

            IP-WG,

             

            Please check the Yahoo group for the latest draft. 

             

            Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

             

            Regards,

            Coleman

          • Carl Neilson
            1) Is not solved for the reasons I indicated. 2) Has no impact on this as it will be that way anyway. 3) I disagree that global broadcasts are bad (and this
            Message 5 of 9 , Jan 4, 2012
            • 0 Attachment

              1) Is not solved for the reasons I indicated.

               

              2) Has no impact on this as it will be that way anyway.

               

              3) I disagree that global broadcasts are bad (and this would be the root of the disagreement).

               

              4) 1+3 make 4 moot. (they also make 4, but that is math not BACnet :)

               

              Carl

               

               

              From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John
              Sent: Wednesday, January 04, 2012 8:25 AM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

               

               

              And my reasons for WANTING I-Am to contain a useful maxAPDU are

               

              1)      I-Am is (or was intended to be) the way clients determine how or if they need to segment of limit their requests.  Why not make it work?

              2)      Simple devices are generally single-port, so these issues apply only to routers or other multi-port devices, which by definition have greater capability

              3)      Global broadcast of I-Am should be deprecated, if not forbidden.  It makes sense for the relatively few routers on a site to broadcast I-Am-Router at startup.  It is a bad idea for 10000 MS/TP VAV boxes to do so.

              4)      Absent global broadcast, the logic of “which max APDU” goes in the incoming Who-Is handler, just like it would go into the incoming Read Property handler if we use the wildcard port instance

               

               

               

              From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
              Sent: Wednesday, January 04, 2012 10:15 AM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

               

               

              Coleman et al,

               

              I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two meetings ago. I hope that I can have the opportunity to argue the opposite position.

               

              My reasons for not agreeing are:

               

              1) The problem violates the network vs application layer separations in a manner far beyond simple knowledge transfer. When a device globally broadcasts its IAms, the application layer generates the IAm and passes it to the network layer, the network layer then has to modify the IAm for each port it is sent out. This requires that the network layer inspect every packet that is sent, and adjust the packet contents accordingly.

               

              This is unlike any other layer violation we have considered to date. To date, we have passed information through the layer API: does the service expect a response; the port was the service received on; indications of errors; security information; etc.

               

              2) The perceived problem only impacts inverted networks. In all other cases, either the PDU size will be accurate or will be limited by the directly attached network of the client.

               

              3) The problem is not solved for non-routers or distant routers. The inverted network issue will still exist for non-routers, and for routers not directly attached to the small intervening network.

               

              Carl

               

               

              From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
              Sent: Tuesday, January 03, 2012 7:27 PM
              To: bacnet-ip-wg@yahoogroups.com
              Subject: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

               

               

              IP-WG,

               

              Please check the Yahoo group for the latest draft. 

               

              Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

               

              Regards,

              Coleman

               



              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.

            • Buddy Lott
              All. I have not read the proposal but after reading this chain I am curious why the Reject-Message-To-Network with a reason code of 4 ( message is too long)
              Message 6 of 9 , Jan 4, 2012
              • 0 Attachment

                All.

                 

                I have not read the proposal but after reading this chain I am curious why the Reject-Message-To-Network with a reason code of 4 ( message is too long) was not “adjusted” to include the “legal” size of message going to that DNET.

                 

                In principle (without much detailed thought):

                1)       Intervening routers could store this information and stop messages that were too “big” much earlier.

                2)       Since the DNET would have a size associated with it (instead of just the device), 1 reject message could adjust all traffic coming to/from a network. Potential reducing congestion.

                3)       This could also allow vendors to modify their routers to “adjust” I-AM messages at the edges versus all the way thru the network (all though it could be done anywhere).

                4)       This could also handle situations where an I-AM was NOT sent before attempting communication.

                 

                I suppose another proposal ( which has probably been made and discarded) would be to  have a network layer “request-path-size” message that could be used to determine the maximum size between 2 devices.

                 

                Thanks,

                 

                 


                From: Carl Neilson [mailto:cneilson@...]
                Sent: Wednesday, January 04, 2012 11:29 AM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                 

                 

                1) Is not solved for the reasons I indicated.

                 

                2) Has no impact on this as it will be that way anyway.

                 

                3) I disagree that global broadcasts are bad (and this would be the root of the disagreement).

                 

                4) 1+3 make 4 moot. (they also make 4, but that is math not BACnet :)

                 

                Carl

                 

                 

                From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John
                Sent: Wednesday, January 04, 2012 8:25 AM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                 

                 

                And my reasons for WANTING I-Am to contain a useful maxAPDU are

                 

                1)      I-Am is (or was intended to be) the way clients determine how or if they need to segment of limit their requests.  Why not make it work?

                2)      Simple devices are generally single-port, so these issues apply only to routers or other multi-port devices, which by definition have greater capability

                3)      Global broadcast of I-Am should be deprecated, if not forbidden.  It makes sense for the relatively few routers on a site to broadcast I-Am-Router at startup.  It is a bad idea for 10000 MS/TP VAV boxes to do so.

                4)      Absent global broadcast, the logic of “which max APDU” goes in the incoming Who-Is handler, just like it would go into the incoming Read Property handler if we use the wildcard port instance

                 

                 

                 

                From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
                Sent: Wednesday, January 04, 2012 10:15 AM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                 

                 

                Coleman et al,

                 

                I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two meetings ago. I hope that I can have the opportunity to argue the opposite position.

                 

                My reasons for not agreeing are:

                 

                1) The problem violates the network vs application layer separations in a manner far beyond simple knowledge transfer. When a device globally broadcasts its IAms, the application layer generates the IAm and passes it to the network layer, the network layer then has to modify the IAm for each port it is sent out. This requires that the network layer inspect every packet that is sent, and adjust the packet contents accordingly.

                 

                This is unlike any other layer violation we have considered to date. To date, we have passed information through the layer API: does the service expect a response; the port was the service received on; indications of errors; security information; etc.

                 

                2) The perceived problem only impacts inverted networks. In all other cases, either the PDU size will be accurate or will be limited by the directly attached network of the client.

                 

                3) The problem is not solved for non-routers or distant routers. The inverted network issue will still exist for non-routers, and for routers not directly attached to the small intervening network.

                 

                Carl

                 

                 

                From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
                Sent: Tuesday, January 03, 2012 7:27 PM
                To: bacnet-ip-wg@yahoogroups.com
                Subject: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                 

                 

                IP-WG,

                 

                Please check the Yahoo group for the latest draft. 

                 

                Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

                 

                Regards,

                Coleman

                 



                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.

              • Coleman Brumley
                Buddy, Thank you for the feedback. Up until this point, we have been avoiding modifying existing services or Network Layer messages as much as possible. Your
                Message 7 of 9 , Jan 4, 2012
                • 0 Attachment

                  Buddy,

                   

                  Thank you for the feedback. 

                   

                  Up until this point, we have been avoiding modifying existing services or Network Layer messages as much as possible.  Your suggestion is a good one, and we've discussed similar approaches in the teleconferences.  We've also discussed modifying the I-Am-Router-To-Network message so that it contains the max-apdu-length-accepted for the next hop router to that network.

                   

                  We also agreed that in order to move this much needed addendum forward, that we would consider modifications to existing network layer messages as a separate proposal. 

                   

                  Having said all that, draft 6 will have new language with how max-apdu-length-accepted is handled in the Device object in the case of multi-port devices but it will not address deprecating or modifying existing services. 

                   

                  Regards,

                  Coleman

                   

                   

                  From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Buddy Lott
                  Sent: Wednesday, January 04, 2012 4:43 PM
                  To: bacnet-ip-wg@yahoogroups.com
                  Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                   

                   

                  All.

                   

                  I have not read the proposal but after reading this chain I am curious why the Reject-Message-To-Network with a reason code of 4 ( message is too long) was not “adjusted” to include the “legal” size of message going to that DNET.

                   

                  In principle (without much detailed thought):

                  1)       Intervening routers could store this information and stop messages that were too “big” much earlier.

                  2)       Since the DNET would have a size associated with it (instead of just the device), 1 reject message could adjust all traffic coming to/from a network. Potential reducing congestion.

                  3)       This could also allow vendors to modify their routers to “adjust” I-AM messages at the edges versus all the way thru the network (all though it could be done anywhere).

                  4)       This could also handle situations where an I-AM was NOT sent before attempting communication.

                   

                  I suppose another proposal ( which has probably been made and discarded) would be to  have a network layer “request-path-size” message that could be used to determine the maximum size between 2 devices.

                   

                  Thanks,

                   

                   


                  From: Carl Neilson [mailto:cneilson@...]
                  Sent: Wednesday, January 04, 2012 11:29 AM
                  To: bacnet-ip-wg@yahoogroups.com
                  Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                   

                   

                  1) Is not solved for the reasons I indicated.

                   

                  2) Has no impact on this as it will be that way anyway.

                   

                  3) I disagree that global broadcasts are bad (and this would be the root of the disagreement).

                   

                  4) 1+3 make 4 moot. (they also make 4, but that is math not BACnet :)

                   

                  Carl

                   

                   

                  From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John
                  Sent: Wednesday, January 04, 2012 8:25 AM
                  To: bacnet-ip-wg@yahoogroups.com
                  Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                   

                   

                  And my reasons for WANTING I-Am to contain a useful maxAPDU are

                   

                  1)      I-Am is (or was intended to be) the way clients determine how or if they need to segment of limit their requests.  Why not make it work?

                  2)      Simple devices are generally single-port, so these issues apply only to routers or other multi-port devices, which by definition have greater capability

                  3)      Global broadcast of I-Am should be deprecated, if not forbidden.  It makes sense for the relatively few routers on a site to broadcast I-Am-Router at startup.  It is a bad idea for 10000 MS/TP VAV boxes to do so.

                  4)      Absent global broadcast, the logic of “which max APDU” goes in the incoming Who-Is handler, just like it would go into the incoming Read Property handler if we use the wildcard port instance

                   

                   

                   

                  From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
                  Sent: Wednesday, January 04, 2012 10:15 AM
                  To: bacnet-ip-wg@yahoogroups.com
                  Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                   

                   

                  Coleman et al,

                   

                  I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two meetings ago. I hope that I can have the opportunity to argue the opposite position.

                   

                  My reasons for not agreeing are:

                   

                  1) The problem violates the network vs application layer separations in a manner far beyond simple knowledge transfer. When a device globally broadcasts its IAms, the application layer generates the IAm and passes it to the network layer, the network layer then has to modify the IAm for each port it is sent out. This requires that the network layer inspect every packet that is sent, and adjust the packet contents accordingly.

                   

                  This is unlike any other layer violation we have considered to date. To date, we have passed information through the layer API: does the service expect a response; the port was the service received on; indications of errors; security information; etc.

                   

                  2) The perceived problem only impacts inverted networks. In all other cases, either the PDU size will be accurate or will be limited by the directly attached network of the client.

                   

                  3) The problem is not solved for non-routers or distant routers. The inverted network issue will still exist for non-routers, and for routers not directly attached to the small intervening network.

                   

                  Carl

                   

                   

                  From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
                  Sent: Tuesday, January 03, 2012 7:27 PM
                  To: bacnet-ip-wg@yahoogroups.com
                  Subject: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                   

                   

                  IP-WG,

                   

                  Please check the Yahoo group for the latest draft. 

                   

                  Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

                   

                  Regards,

                  Coleman

                   



                  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.

                • goetz_philippe
                  Dear Members, I m starting the review of the PPR2 Draft 5. Starting from 12.X.43 and following: - In Table 12-13, Max_Master type is Unisgne8 and not Unsigned
                  Message 8 of 9 , Jan 5, 2012
                  • 0 Attachment
                    Dear Members,

                    I'm starting the review of the PPR2 Draft 5.
                    Starting from 12.X.43 and following:
                    - In Table 12-13, Max_Master type is Unisgne8 and not Unsigned (see Clause 12.11.32)
                    - In Table 12-13, the X footnote doesn't apply to Slave_Proxy_Enable, Auto_Slave_Discovery (BACnetARRAY[N] whose array element represent a MS/TP Port) as well as Manual_Slave_Address_binding and Slave_Address_Binding that includes the MS/TP port linking through the network-number field of the deviceAddress field of the BACnet_AddressBinding.
                    - In Clause 21, remove the ',' after bbmd (2) in BACnetIPMode type.
                    - In Clause 21, remove the ',' after disconnected (2) in BACnetNetworkReachability type.

                    The review up to 12.X.43 will follow in the coming days.

                    Regards,
                    Philippe GOETZ (Commenter 0005 on PPR1)

                    Siemens AG
                    Infrastructure & Cities Sector
                    Building Technologies Division
                    Fire Safety and Security
                    IC BT FSS SYS R&D KHE
                    Siemensallee 84
                    76187 Karlsruhe, Deutschland

                    Siemens Aktiengesellschaft: Vorsitzender des Aufsichtsrats: Gerhard Cromme; Vorstand: Peter Löscher, Vorsitzender; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Süß; Sitz der Gesellschaft: Berlin und München, Deutschland; Registergericht: Berlin Charlottenburg, HRB 12300, München, HRB 6684; WEEE-Reg.-Nr. DE 23691322


                    --- In bacnet-ip-wg@yahoogroups.com, "Coleman Brumley" <bacnet_cb@...> wrote:
                    >
                    > IP-WG,
                    >
                    >
                    >
                    > Please check the Yahoo group for the latest draft.
                    >
                    >
                    >
                    > Please note that I did not reinstate the draft 2 max-apdu-length-accepted
                    > changes, and we will revisit that discussion during the teleconference.
                    > It's my hope that other than editorial changes, that there won't be many
                    > other discussion points.
                    >
                    >
                    >
                    > Regards,
                    >
                    > Coleman
                    >
                  • Buddy Lott
                    All, It just occurred to me that there was a proposed ( or approved?) change to the standard that added a LARGER frame to MS/TP network. This has me wondering:
                    Message 9 of 9 , Jan 5, 2012
                    • 0 Attachment

                      All,

                       

                      It just occurred to me that there was a proposed ( or approved?) change to the standard that added a LARGER frame to MS/TP network. This has me wondering:

                       

                      The cause of an Inverted network is a Lower-NPDU-Sized network being used to connect two ( or more)  Larger-NPDU-Sized networks. The largest NPDU sizes are for Ethernet and IP.   Of smaller NPDU size networks:

                                  ZigBee seems intended for low bandwidth and low power uses which ( to me) would excluded connecting two larger NPDU networks.

                                  ArcNet & LonTalk I have never seen in action, but I wonder if they are really being used to connect larger NPDU sized networks.

                                  MS/TP looks like it might get larger data frame sizes which would solve this problem.

                                  PTP, which is the first “reasonable” (IMHO) cause of an inverted network, could also benefit from the larger data frame sizes which would fix this problem.

                       

                       

                      Another suggestion/thought would be Network Layer “segmentation” for messages that are going from router-to-router ( i.e. The message came into one router and is going to another router for more routing). This would not need to be as robust as the Application Layer Segmentation, but good enough to handle a message going between two routers.

                       

                       


                      From: Coleman Brumley [mailto:bacnet_cb@...]
                      Sent: Wednesday, January 04, 2012 4:57 PM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                       

                       

                      Buddy,

                       

                      Thank you for the feedback. 

                       

                      Up until this point, we have been avoiding modifying existing services or Network Layer messages as much as possible.  Your suggestion is a good one, and we've discussed similar approaches in the teleconferences.  We've also discussed modifying the I-Am-Router-To-Network message so that it contains the max-apdu-length-accepted for the next hop router to that network.

                       

                      We also agreed that in order to move this much needed addendum forward, that we would consider modifications to existing network layer messages as a separate proposal. 

                       

                      Having said all that, draft 6 will have new language with how max-apdu-length-accepted is handled in the Device object in the case of multi-port devices but it will not address deprecating or modifying existing services. 

                       

                      Regards,

                      Coleman

                       

                       

                      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Buddy Lott
                      Sent: Wednesday, January 04, 2012 4:43 PM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                       

                       

                      All.

                       

                      I have not read the proposal but after reading this chain I am curious why the Reject-Message-To-Network with a reason code of 4 ( message is too long) was not “adjusted” to include the “legal” size of message going to that DNET.

                       

                      In principle (without much detailed thought):

                      1)       Intervening routers could store this information and stop messages that were too “big” much earlier.

                      2)       Since the DNET would have a size associated with it (instead of just the device), 1 reject message could adjust all traffic coming to/from a network. Potential reducing congestion.

                      3)       This could also allow vendors to modify their routers to “adjust” I-AM messages at the edges versus all the way thru the network (all though it could be done anywhere).

                      4)       This could also handle situations where an I-AM was NOT sent before attempting communication.

                       

                      I suppose another proposal ( which has probably been made and discarded) would be to  have a network layer “request-path-size” message that could be used to determine the maximum size between 2 devices.

                       

                      Thanks,

                       

                       


                      From: Carl Neilson [mailto:cneilson@...]
                      Sent: Wednesday, January 04, 2012 11:29 AM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                       

                       

                      1) Is not solved for the reasons I indicated.

                       

                      2) Has no impact on this as it will be that way anyway.

                       

                      3) I disagree that global broadcasts are bad (and this would be the root of the disagreement).

                       

                      4) 1+3 make 4 moot. (they also make 4, but that is math not BACnet :)

                       

                      Carl

                       

                       

                      From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Hartman, John
                      Sent: Wednesday, January 04, 2012 8:25 AM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                       

                       

                      And my reasons for WANTING I-Am to contain a useful maxAPDU are

                       

                      1)      I-Am is (or was intended to be) the way clients determine how or if they need to segment of limit their requests.  Why not make it work?

                      2)      Simple devices are generally single-port, so these issues apply only to routers or other multi-port devices, which by definition have greater capability

                      3)      Global broadcast of I-Am should be deprecated, if not forbidden.  It makes sense for the relatively few routers on a site to broadcast I-Am-Router at startup.  It is a bad idea for 10000 MS/TP VAV boxes to do so.

                      4)      Absent global broadcast, the logic of “which max APDU” goes in the incoming Who-Is handler, just like it would go into the incoming Read Property handler if we use the wildcard port instance

                       

                       

                       

                      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Carl Neilson
                      Sent: Wednesday, January 04, 2012 10:15 AM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                       

                       

                      Coleman et al,

                       

                      I am uncomfortable with the decision to have IAms reflect the MaxAPDU size by port, a switch in the position from the teleconference two meetings ago. I hope that I can have the opportunity to argue the opposite position.

                       

                      My reasons for not agreeing are:

                       

                      1) The problem violates the network vs application layer separations in a manner far beyond simple knowledge transfer. When a device globally broadcasts its IAms, the application layer generates the IAm and passes it to the network layer, the network layer then has to modify the IAm for each port it is sent out. This requires that the network layer inspect every packet that is sent, and adjust the packet contents accordingly.

                       

                      This is unlike any other layer violation we have considered to date. To date, we have passed information through the layer API: does the service expect a response; the port was the service received on; indications of errors; security information; etc.

                       

                      2) The perceived problem only impacts inverted networks. In all other cases, either the PDU size will be accurate or will be limited by the directly attached network of the client.

                       

                      3) The problem is not solved for non-routers or distant routers. The inverted network issue will still exist for non-routers, and for routers not directly attached to the small intervening network.

                       

                      Carl

                       

                       

                      From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Coleman Brumley
                      Sent: Tuesday, January 03, 2012 7:27 PM
                      To: bacnet-ip-wg@yahoogroups.com
                      Subject: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

                       

                       

                      IP-WG,

                       

                      Please check the Yahoo group for the latest draft. 

                       

                      Please note that I did not reinstate the draft 2 max-apdu-length-accepted changes, and we will revisit that discussion during the teleconference.  It's my hope that other than editorial changes, that there won't be many other discussion points. 

                       

                      Regards,

                      Coleman

                       



                      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.