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

Large Frames for MS/TP

Expand Messages
  • polars15213
    During the past two MSTP-WG meetings one of the topics discussed has been the possibility of using MS/TP to convey larger format frames. Among the use cases
    Message 1 of 10 , Feb 2, 2011
    • 0 Attachment
      During the past two MSTP-WG meetings one of the topics discussed has been the possibility of using MS/TP to convey larger format frames. Among the use cases for this feature is the idea of transporting IP frames over MS/TP in some of the BACnet/IT proposals being discussed
      in IT-WG.

      Other "regular" BACnet functionality would also benefit from
      this feature, for those devices capable of supporting larger frame
      sizes, for example during up/downloading of configuration and data files as well as larger ReadProperty responses etc.

      I have posted DMF-060-1 as a proposal for one way this might be accomplished.
    • Clifford.H.Copass@jci.com
      Three things that probably need to be considered along with this: 1 - How does a device that can send a large frame determine that another device can accept
      Message 2 of 10 , Feb 4, 2011
      • 0 Attachment

        Three things that probably need to be considered along with this:
        1 - How does a device that can send a large frame determine that another device can accept it?
        2 - These should probably only be used with higher baud rates.
        3 - Will old devices that don't understand the frame type or allow larger messages have problems even if the message is not addressed to them?

        Cliff Copass
        Johnson Controls, Inc.



        From:"polars15213" <dfisher@...>
        To:bacnet-mstpwg@yahoogroups.com
        Date:02/02/2011 02:10 PM
        Subject:[bacnet-mstpwg] Large Frames for MS/TP





        During the past two MSTP-WG meetings one of the topics discussed has been the possibility of using MS/TP to convey larger format frames. Among the use cases for this feature is the idea of transporting IP frames over MS/TP in some of the BACnet/IT proposals being discussed
        in IT-WG.

        Other "regular" BACnet functionality would also benefit from
        this feature, for those devices capable of supporting larger frame
        sizes, for example during up/downloading of configuration and data files as well as larger ReadProperty responses etc.

        I have posted DMF-060-1 as a proposal for one way this might be accomplished.



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

        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
           
        http://groups.yahoo.com/group/bacnet-mstpwg/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           
        http://groups.yahoo.com/group/bacnet-mstpwg/join
           (Yahoo! ID required)

        <*> To change settings via email:
           bacnet-mstpwg-digest@yahoogroups.com
           bacnet-mstpwg-fullfeatured@yahoogroups.com

        <*> To unsubscribe from this group, send an email to:
           bacnet-mstpwg-unsubscribe@yahoogroups.com

        <*> Your use of Yahoo! Groups is subject to:
           
        http://docs.yahoo.com/info/terms/



      • kerlyn2001
        ... I d say configuration or discovery. It seems that the loopback test method could be used for this purpose. Section 9.1.3.1 ends with If the receiving
        Message 3 of 10 , Feb 9, 2011
        • 0 Attachment
          I'll take a pass at this:

          > Three things that probably need to be considered along with this:
          > 1 - How does a device that can send a large frame determine that
          > another device can accept it?

          I'd say configuration or discovery. It seems that the loopback test
          method could be used for this purpose. Section 9.1.3.1 ends with
          "If the receiving node cannot detect the valid reception of frames
          with overlength information fields, then no response shall be
          returned."

          > 2 - These should probably only be used with higher baud rates.

          That is one possibility. It might eliminate many legacy devices
          from the set of nodes that might receive large frames. The concern
          I have (and will elaborate in a separate message) is that the
          probability of a CRC failure (passing bad data up the stack as good)
          is dependent on bit error rate and message size. The former goes up
          with bit rate and the latter goes up with large frames.

          > 3 - Will old devices that don't understand the frame type or allow
          > larger messages have problems even if the message is not addressed
          > to them?

          The new frame(s) will have a different frame type (not 5 or 6). In
          the normal case, a frame will not be unicast to a device that doesn't
          understand it (see #1 above). A device *may* receive a large frame
          that was broadcast. In this case, the device should either reject it
          because of FrameTooLong (set in Receive Frame HEADER CRC state) or
          ReceivedInvalidFrame (set in Master Node IDLE state).

          Comments?

          -K-
        • carlneilson
          1 - I think that the only appropriate methods for determining large versus small would be via the Max_APDU_Length_Accepted property in the device or the
          Message 4 of 10 , Feb 9, 2011
          • 0 Attachment

            1 – I think that the only appropriate methods for determining large versus small would be via the Max_APDU_Length_Accepted property in the device or the similar value in the application request header. Note that routers will take the message they are given and will send to the destination device. The source device of the packet have generated a packet based on what it believes that the destination device can consume.

             

            Carl

             

            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
            Sent: Wednesday, February 09, 2011 5:14 PM
            To: bacnet-mstpwg@yahoogroups.com
            Subject: [bacnet-mstpwg] Re: Large Frames for MS/TP

             

             

            I'll take a pass at this:

            > Three things that probably need to be considered along with this:
            > 1 - How does a device that can send a large frame determine that
            > another device can accept it?

            I'd say configuration or discovery. It seems that the loopback test
            method could be used for this purpose. Section 9.1.3.1 ends with
            "If the receiving node cannot detect the valid reception of frames
            with overlength information fields, then no response shall be
            returned."

            > 2 - These should probably only be used with higher baud rates.

            That is one possibility. It might eliminate many legacy devices
            from the set of nodes that might receive large frames. The concern
            I have (and will elaborate in a separate message) is that the
            probability of a CRC failure (passing bad data up the stack as good)
            is dependent on bit error rate and message size. The former goes up
            with bit rate and the latter goes up with large frames.

            > 3 - Will old devices that don't understand the frame type or allow
            > larger messages have problems even if the message is not addressed
            > to them?

            The new frame(s) will have a different frame type (not 5 or 6). In
            the normal case, a frame will not be unicast to a device that doesn't
            understand it (see #1 above). A device *may* receive a large frame
            that was broadcast. In this case, the device should either reject it
            because of FrameTooLong (set in Receive Frame HEADER CRC state) or
            ReceivedInvalidFrame (set in Master Node IDLE state).

            Comments?

            -K-

          • kerlyn2001
            What about broadcasts on segments that contain both old and new devices? Do you agree that old devices should reject large broadcast frames, or should we
            Message 5 of 10 , Feb 9, 2011
            • 0 Attachment
              What about broadcasts on segments that contain both old and new
              devices? Do you agree that old devices should reject large
              broadcast frames, or should we restrict the length of broadcast
              frames to [0-501]?

              -K-

              --- In bacnet-mstpwg@yahoogroups.com, "carlneilson" <carlneilson@...> wrote:
              >
              > 1 - I think that the only appropriate methods for determining large versus small
              > would be via the Max_APDU_Length_Accepted property in the device or the similar
              > value in the application request header. Note that routers will take the message
              > they are given and will send to the destination device. The source device of the
              > packet have generated a packet based on what it believes that the destination
              > device can consume.
              >
              >
              >
              > Carl
            • Coleman Brumley
              Old devices would simply drop the broadcasted large frames. From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
              Message 6 of 10 , Feb 9, 2011
              • 0 Attachment

                Old devices would simply drop the broadcasted large frames. 

                 

                From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
                Sent: Wednesday, February 09, 2011 8:51 PM
                To: bacnet-mstpwg@yahoogroups.com
                Subject: [bacnet-mstpwg] Re: Large Frames for MS/TP

                 

                 

                What about broadcasts on segments that contain both old and new
                devices? Do you agree that old devices should reject large
                broadcast frames, or should we restrict the length of broadcast
                frames to [0-501]?

                -K-

                --- In bacnet-mstpwg@yahoogroups.com, "carlneilson" <carlneilson@...> wrote:
                >
                > 1 - I think that the only appropriate methods for determining large versus small
                > would be via the Max_APDU_Length_Accepted property in the device or the similar
                > value in the application request header. Note that routers will take the message
                > they are given and will send to the destination device. The source device of the
                > packet have generated a packet based on what it believes that the destination
                > device can consume.
                >
                >
                >
                > Carl

              • carlneilson
                Note that broadcasts are already an issue that developers need to consider as there is no guarantee that devices are capable of receiving the maximum frame
                Message 7 of 10 , Feb 10, 2011
                • 0 Attachment

                  Note that broadcasts are already an issue that developers need to consider as there is no guarantee that devices are capable of receiving the maximum frame size for its medium (except routers). Thus broadcasts are already at risk of being dropped by devices.

                   

                  Carl

                   

                  From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Coleman Brumley
                  Sent: Wednesday, February 09, 2011 9:41 PM
                  To: bacnet-mstpwg@yahoogroups.com
                  Subject: RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

                   

                   

                  Old devices would simply drop the broadcasted large frames. 

                   

                  From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
                  Sent: Wednesday, February 09, 2011 8:51 PM
                  To: bacnet-mstpwg@yahoogroups.com
                  Subject: [bacnet-mstpwg] Re: Large Frames for MS/TP

                   

                   

                  What about broadcasts on segments that contain both old and new
                  devices? Do you agree that old devices should reject large
                  broadcast frames, or should we restrict the length of broadcast
                  frames to [0-501]?

                  -K-

                  --- In bacnet-mstpwg@yahoogroups.com, "carlneilson" <carlneilson@...> wrote:
                  >
                  > 1 - I think that the only appropriate methods for determining large versus small
                  > would be via the Max_APDU_Length_Accepted property in the device or the similar
                  > value in the application request header. Note that routers will take the message
                  > they are given and will send to the destination device. The source device of the
                  > packet have generated a packet based on what it believes that the destination
                  > device can consume.
                  >
                  >
                  >
                  > Carl

                • Clifford.H.Copass@jci.com
                  I think this is yet another reason why the Network Port Object proposal needs a way to find the Network Port Object for the port you are communicating through
                  Message 8 of 10 , Feb 11, 2011
                  • 0 Attachment
                    I think this is yet another reason why the Network Port Object proposal needs a way to find the Network Port Object for the port you are communicating through when there is more than one.

                    Cliff Copass
                    Johnson Controls, Inc.



                    From:"carlneilson" <carlneilson@...>
                    To:<bacnet-mstpwg@yahoogroups.com>
                    Date:02/09/2011 07:29 PM
                    Subject:RE: [bacnet-mstpwg] Re: Large Frames for MS/TP






                    1 – I think that the only appropriate methods for determining large versus small would be via the Max_APDU_Length_Accepted property in the device or the similar value in the application request header. Note that routers will take the message they are given and will send to the destination device. The source device of the packet have generated a packet based on what it believes that the destination device can consume.

                     

                    Carl

                     

                    From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
                    Sent:
                    Wednesday, February 09, 2011 5:14 PM
                    To:
                    bacnet-mstpwg@yahoogroups.com
                    Subject:
                    [bacnet-mstpwg] Re: Large Frames for MS/TP

                     

                     

                    I'll take a pass at this:

                    > Three things that probably need to be considered along with this:
                    > 1 - How does a device that can send a large frame determine that
                    > another device can accept it?

                    I'd say configuration or discovery. It seems that the loopback test
                    method could be used for this purpose. Section 9.1.3.1 ends with
                    "If the receiving node cannot detect the valid reception of frames
                    with overlength information fields, then no response shall be
                    returned."

                    > 2 - These should probably only be used with higher baud rates.

                    That is one possibility. It might eliminate many legacy devices
                    from the set of nodes that might receive large frames. The concern
                    I have (and will elaborate in a separate message) is that the
                    probability of a CRC failure (passing bad data up the stack as good)
                    is dependent on bit error rate and message size. The former goes up
                    with bit rate and the latter goes up with large frames.

                    > 3 - Will old devices that don't understand the frame type or allow
                    > larger messages have problems even if the message is not addressed
                    > to them?

                    The new frame(s) will have a different frame type (not 5 or 6). In
                    the normal case, a frame will not be unicast to a device that doesn't
                    understand it (see #1 above). A device *may* receive a large frame
                    that was broadcast. In this case, the device should either reject it
                    because of FrameTooLong (set in Receive Frame HEADER CRC state) or
                    ReceivedInvalidFrame (set in Master Node IDLE state).

                    Comments?

                    -K-





                  • Coleman Brumley
                    Cliff, I ve been mulling this over since we talked about it in Vegas. How would you be able to make a logical connection/relationship from the NPO on the wire
                    Message 9 of 10 , Feb 11, 2011
                    • 0 Attachment

                      Cliff,

                       

                      I've been mulling this over since we talked about it in Vegas.

                       

                      How would you be able to make a logical connection/relationship from the NPO on the wire to the physical port?  I don't think you can other than with labels, documentation, or whatever.  

                       

                      Consider I/O objects, where this already an issue.   If I have X binary outputs on a device, and I have X BO objects -- how do I (being a BACnet client) know where BO-1 is physically on the board???   I, Coleman, have to look at the board or documentation (as-builds, manufacturers documentation, whatever) and check for a label that says "Binary Output 1" or something that matches the description or whatever.  The point being that there is some entity outside of BACnet for representing this relationship. 

                       

                      The same applies for the NPO.   If I have X MS/TP ports on an device, and I have X NP objects -- how do I (being a BACnet client) know where NPO-1 is physically on the board?

                       

                      - Coleman

                       

                      From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
                      Sent: Friday, February 11, 2011 9:15 AM
                      To: bacnet-mstpwg@yahoogroups.com
                      Subject: RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

                       

                       


                      I think this is yet another reason why the Network Port Object proposal needs a way to find the Network Port Object for the port you are communicating through when there is more than one.

                      Cliff Copass
                      Johnson Controls, Inc.


                      From:

                      "carlneilson" <carlneilson@...>

                      To:

                      <bacnet-mstpwg@yahoogroups.com>

                      Date:

                      02/09/2011 07:29 PM

                      Subject:

                      RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

                       





                      1 – I think that the only appropriate methods for determining large versus small would be via the Max_APDU_Length_Accepted property in the device or the similar value in the application request header. Note that routers will take the message they are given and will send to the destination device. The source device of the packet have generated a packet based on what it believes that the destination device can consume.

                       

                      Carl

                       

                      From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
                      Sent:
                      Wednesday, February 09, 2011 5:14 PM
                      To:
                      bacnet-mstpwg@yahoogroups.com
                      Subject:
                      [bacnet-mstpwg] Re: Large Frames for MS/TP

                       

                       

                      I'll take a pass at this:

                      > Three things that probably need to be considered along with this:
                      > 1 - How does a device that can send a large frame determine that
                      > another device can accept it?

                      I'd say configuration or discovery. It seems that the loopback test
                      method could be used for this purpose. Section 9.1.3.1 ends with
                      "If the receiving node cannot detect the valid reception of frames
                      with overlength information fields, then no response shall be
                      returned."

                      > 2 - These should probably only be used with higher baud rates.

                      That is one possibility. It might eliminate many legacy devices
                      from the set of nodes that might receive large frames. The concern
                      I have (and will elaborate in a separate message) is that the
                      probability of a CRC failure (passing bad data up the stack as good)
                      is dependent on bit error rate and message size. The former goes up
                      with bit rate and the latter goes up with large frames.

                      > 3 - Will old devices that don't understand the frame type or allow
                      > larger messages have problems even if the message is not addressed
                      > to them?

                      The new frame(s) will have a different frame type (not 5 or 6). In
                      the normal case, a frame will not be unicast to a device that doesn't
                      understand it (see #1 above). A device *may* receive a large frame
                      that was broadcast. In this case, the device should either reject it
                      because of FrameTooLong (set in Receive Frame HEADER CRC state) or
                      ReceivedInvalidFrame (set in Master Node IDLE state).

                      Comments?

                      -K-




                    • Clifford.H.Copass@jci.com
                      Actually I don t think this issue has anything at all to do with the physical location/connector on the board necessarily. If a client device is trying to
                      Message 10 of 10 , Feb 11, 2011
                      • 0 Attachment
                        Actually I don't think this issue has anything at all to do with the physical location/connector on the board necessarily.  If a client device is trying to determine if a potential server device can handle a big message, it doesn't care where the connector is located.  It may only want to know which Network Port Object contains the information for the port it is communicating through (assuming there is more than one).

                        An installer may need information on the physical port, but even then I am not convinced they would always care when adding/removing devices to/from an existing bus.  Especially if that bus disappeared off into the unknown reaches of some building where a physically inaccessible device was located that needed something on the appropriate Network Port Object verified or changed.

                        Cliff Copass
                        Johnson Controls, Inc.



                        From:"Coleman Brumley" <bacnet_cb@...>
                        To:<bacnet-mstpwg@yahoogroups.com>
                        Date:02/11/2011 09:04 AM
                        Subject:RE: [bacnet-mstpwg] Re: Large Frames for MS/TP






                        Cliff,

                         

                        I've been mulling this over since we talked about it in Vegas.

                         

                        How would you be able to make a logical connection/relationship from the NPO on the wire to the physical port?  I don't think you can other than with labels, documentation, or whatever.  

                         

                        Consider I/O objects, where this already an issue.   If I have X binary outputs on a device, and I have X BO objects -- how do I (being a BACnet client) know where BO-1 is physically on the board???   I, Coleman, have to look at the board or documentation (as-builds, manufacturers documentation, whatever) and check for a label that says "Binary Output 1" or something that matches the description or whatever.  The point being that there is some entity outside of BACnet for representing this relationship.  

                         

                        The same applies for the NPO.   If I have X MS/TP ports on an device, and I have X NP objects -- how do I (being a BACnet client) know where NPO-1 is physically on the board?

                         

                        - Coleman

                         

                        From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Clifford.H.Copass@...
                        Sent:
                        Friday, February 11, 2011 9:15 AM
                        To:
                        bacnet-mstpwg@yahoogroups.com
                        Subject:
                        RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

                         

                         


                        I think this is yet another reason why the Network Port Object proposal needs a way to find the Network Port Object for the port you are communicating through when there is more than one.


                        Cliff Copass

                        Johnson Controls, Inc.


                        From: "carlneilson" <carlneilson@...>
                        To: <bacnet-mstpwg@yahoogroups.com>
                        Date: 02/09/2011 07:29 PM
                        Subject: RE: [bacnet-mstpwg] Re: Large Frames for MS/TP

                         




                        1 – I think that the only appropriate methods for determining large versus small would be via the Max_APDU_Length_Accepted property in the device or the similar value in the application request header. Note that routers will take the message they are given and will send to the destination device. The source device of the packet have generated a packet based on what it believes that the destination device can consume.

                         

                        Carl

                         

                        From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
                        Sent:
                        Wednesday, February 09, 2011 5:14 PM
                        To:
                        bacnet-mstpwg@yahoogroups.com
                        Subject:
                        [bacnet-mstpwg] Re: Large Frames for MS/TP

                         

                         

                        I'll take a pass at this:

                        > Three things that probably need to be considered along with this:
                        > 1 - How does a device that can send a large frame determine that
                        > another device can accept it?

                        I'd say configuration or discovery. It seems that the loopback test
                        method could be used for this purpose. Section 9.1.3.1 ends with
                        "If the receiving node cannot detect the valid reception of frames
                        with overlength information fields, then no response shall be
                        returned."

                        > 2 - These should probably only be used with higher baud rates.

                        That is one possibility. It might eliminate many legacy devices
                        from the set of nodes that might receive large frames. The concern
                        I have (and will elaborate in a separate message) is that the
                        probability of a CRC failure (passing bad data up the stack as good)
                        is dependent on bit error rate and message size. The former goes up
                        with bit rate and the latter goes up with large frames.

                        > 3 - Will old devices that don't understand the frame type or allow
                        > larger messages have problems even if the message is not addressed
                        > to them?

                        The new frame(s) will have a different frame type (not 5 or 6). In
                        the normal case, a frame will not be unicast to a device that doesn't
                        understand it (see #1 above). A device *may* receive a large frame
                        that was broadcast. In this case, the device should either reject it
                        because of FrameTooLong (set in Receive Frame HEADER CRC state) or
                        ReceivedInvalidFrame (set in Master Node IDLE state).

                        Comments?

                        -K-







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