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

RE: [bacnet-ip-wg] Add. AI PPR2 Draft5 has been uploaded

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.