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

Question on MS/TP Service Specification

Expand Messages
  • kerlyn2001
    The service primitives DL-UNITDATA.request and DL-UNITDATA.indication are described in clause 9.1.1 and 9.1.2, respectively. These are based on the ISO 8802-2
    Message 1 of 4 , Feb 9, 2011
    • 0 Attachment
      The service primitives DL-UNITDATA.request and DL-UNITDATA.indication
      are described in clause 9.1.1 and 9.1.2, respectively. These are
      based on the ISO 8802-2 specification. The SA and DA parameters for
      both primitives are described as follows:

      "Each source and destination address consists of a logical
      concatenation of a medium access control (MAC) address and a link
      service access point (LSAP). For the case of MS/TP devices, since
      MS/TP supports only the BACnet network layer, the LSAP is omitted
      and these parameters consist only of the device MAC address."


      In clause 9.5.6.2, ReceivedDataNoReply, the BACnet spec says:

      "If ReceivedValidFrame is true... and FrameType is equal to BACnet
      Data Not Expecting Reply, Test_Response, or a proprietary type know
      to this node... then indicate successful reception to the higher
      layers..."

      My question is this - doesn't FrameType effectively communicate LSAP?
      If so, why don't the abstract service primitives account for this?
      How is FrameType generally communicated in practice to the upper
      layers?

      The basis for my question concerns how to transmit data that is NOT
      BACnet, e.g. native IP. It seems that one approach would be to use a
      proprietary frame type. We might also choose to dedicate a frame type
      from the reserved range. But I expect any proposal along those lines
      would need to contain proposed changes to the spec regarding how to
      communicate the frame type. Any comments/suggestions?

      Thanks, -K-
    • David Fisher
      Kerry, If and when we reach some agreement about the concept of a large frame type, which is the MSTP-WG purview, then we can make additional consideration and
      Message 2 of 4 , Feb 10, 2011
      • 0 Attachment

        Kerry,

         

        If and when we reach some agreement about the concept of a large frame type,

        which is the MSTP-WG purview, then we can make additional consideration

        and discussion of how this might integrate into other layer primitives.

         

        My thinking was that the large frame type could be used by the BACnet network layer

        OR by an IP layer. As you point out, I suppose one could define additional frametypes

        just for IP and treat these as effectively LSAPs. There are issues still to be discussed

        though. For example for IP we really don't need large frame expecting reply, so it's

        really only one more frametype which would be easy to add to this proposal.

         

        David Fisher

        PolarSoft® Inc.

        914 South Aiken Ave

        Pittsburgh PA 15232-2212

        dfisher@...

        www.polarsoft.biz

        412-683-2018

        412-683-5228 fax

         


        From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of kerlyn2001
        Sent: Wednesday, February 09, 2011 8:44 PM
        To: bacnet-mstpwg@yahoogroups.com
        Subject: [bacnet-mstpwg] Question on MS/TP Service Specification

         

         

        The service primitives DL-UNITDATA.request and DL-UNITDATA.indication
        are described in clause 9.1.1 and 9.1.2, respectively. These are
        based on the ISO 8802-2 specification. The SA and DA parameters for
        both primitives are described as follows:

        "Each source and destination address consists of a logical
        concatenation of a medium access control (MAC) address and a link
        service access point (LSAP). For the case of MS/TP devices, since
        MS/TP supports only the BACnet network layer, the LSAP is omitted
        and these parameters consist only of the device MAC address."

        In clause 9.5.6.2, ReceivedDataNoReply, the BACnet spec says:

        "If ReceivedValidFrame is true... and FrameType is equal to BACnet
        Data Not Expecting Reply, Test_Response, or a proprietary type know
        to this node... then indicate successful reception to the higher
        layers..."

        My question is this - doesn't FrameType effectively communicate LSAP?
        If so, why don't the abstract service primitives account for this?
        How is FrameType generally communicated in practice to the upper
        layers?

        The basis for my question concerns how to transmit data that is NOT
        BACnet, e.g. native IP. It seems that one approach would be to use a
        proprietary frame type. We might also choose to dedicate a frame type
        from the reserved range. But I expect any proposal along those lines
        would need to contain proposed changes to the spec regarding how to
        communicate the frame type. Any comments/suggestions?

        Thanks, -K-

      • kerlyn2001
        Sorry for the delayed response. I think there are two issues (but I d like to get other opinions). The first is that Clause 9 seems to be contradictory in
        Message 3 of 4 , Feb 16, 2011
        • 0 Attachment
          Sorry for the delayed response.

          I think there are two issues (but I'd like to get other opinions).
          The first is that Clause 9 seems to be contradictory in saying that
          non-BACnet frames are both supported and not supported. This should
          probably be fixed whether we approve large frames or not. I suspect
          that any real-world implementation that handles non-BACnet frames is
          passing FrameType across the DL interface. Might as well reflect
          that in the service specification.

          The second issue concerns the mechanics of specifying IP over MS/TP.
          The way to do this is to write an "IP over Foo" RFC and get it
          approved by the IETF. In our case, it's a multiple-body problem,
          since we will be attempting to modify the MS/TP spec in parallel.
          My immediate problem is how to specify IPv6 payloads in MS/TP
          frames. The spec currently allows for non-BACnet frame types in the
          128-255 range, with a 16-bit vendor ID as the first element in the
          Data field (I guess we'd have to assign a vendor ID to the IETF).

          If we were to use FrameType 9 "Large Frame Not Expecting Reply" for
          both BACnet and IPv6 payloads, we'd need to include a separate frame
          type field in the payload to identify the "DSAP". That's why I
          propose a separate FrameType for IPv6. (We'd still have > 100 in
          reserve.)


          I'll have some other comments on large frames soon. My main concern
          has to do with the increased risk of undetected frame errors. I had
          lunch last week with one of the original Ethernet guys and he said
          their decision to go with CRC32 was based on the assumption that more
          than one undetected error in five years was unacceptable.

          Regards, -K-


          --- In bacnet-mstpwg@yahoogroups.com, "David Fisher" <dfisher@...> wrote:
          >
          > Kerry,
          >
          >
          >
          > If and when we reach some agreement about the concept of a large frame type,
          >
          > which is the MSTP-WG purview, then we can make additional consideration
          >
          > and discussion of how this might integrate into other layer primitives.
          >
          >
          >
          > My thinking was that the large frame type could be used by the BACnet
          > network layer
          >
          > OR by an IP layer. As you point out, I suppose one could define additional
          > frametypes
          >
          > just for IP and treat these as effectively LSAPs. There are issues still to
          > be discussed
          >
          > though. For example for IP we really don't need large frame expecting reply,
          > so it's
          >
          > really only one more frametype which would be easy to add to this proposal.
          >
          >
          >
          > David Fisher
          >
          > PolarSoftR Inc.
          >
          > 914 South Aiken Ave
          >
          > Pittsburgh PA 15232-2212
          >
          > <mailto:dfisher@...> dfisher@...
          >
          > www.polarsoft.biz
          >
          > 412-683-2018
          >
          > 412-683-5228 fax
          >
          >
          >
          > _____
          >
          > From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com]
          > On Behalf Of kerlyn2001
          > Sent: Wednesday, February 09, 2011 8:44 PM
          > To: bacnet-mstpwg@yahoogroups.com
          > Subject: [bacnet-mstpwg] Question on MS/TP Service Specification
          >
          >
          >
          >
          >
          > The service primitives DL-UNITDATA.request and DL-UNITDATA.indication
          > are described in clause 9.1.1 and 9.1.2, respectively. These are
          > based on the ISO 8802-2 specification. The SA and DA parameters for
          > both primitives are described as follows:
          >
          > "Each source and destination address consists of a logical
          > concatenation of a medium access control (MAC) address and a link
          > service access point (LSAP). For the case of MS/TP devices, since
          > MS/TP supports only the BACnet network layer, the LSAP is omitted
          > and these parameters consist only of the device MAC address."
          >
          > In clause 9.5.6.2, ReceivedDataNoReply, the BACnet spec says:
          >
          > "If ReceivedValidFrame is true... and FrameType is equal to BACnet
          > Data Not Expecting Reply, Test_Response, or a proprietary type know
          > to this node... then indicate successful reception to the higher
          > layers..."
          >
          > My question is this - doesn't FrameType effectively communicate LSAP?
          > If so, why don't the abstract service primitives account for this?
          > How is FrameType generally communicated in practice to the upper
          > layers?
          >
          > The basis for my question concerns how to transmit data that is NOT
          > BACnet, e.g. native IP. It seems that one approach would be to use a
          > proprietary frame type. We might also choose to dedicate a frame type
          > from the reserved range. But I expect any proposal along those lines
          > would need to contain proposed changes to the spec regarding how to
          > communicate the frame type. Any comments/suggestions?
          >
          > Thanks, -K-
          >
        • David Fisher
          Kerry, ... When I revise this doc we ll include clarifying language about that ... frames is ... I don t think that the upper layer should know or need to know
          Message 4 of 4 , Feb 17, 2011
          • 0 Attachment

            Kerry,

            >...Clause 9 seems to be contradictory in saying that

            >non-BACnet frames are both supported and not supported. This should
            >probably be fixed whether we approve large frames or not.

             

            When I revise this doc we'll include clarifying language about that

             

            > I suspect that any real-world implementation that handles non-BACnet frames is

            > passing FrameType across the DL interface. Might as well reflect
            > that in the service specification.

            I don't think that the upper layer should know or need to know about

            frametype. Only that it wants to send

            a. a regular BACnet frame

            b. a "large" BACnet frame

            c. an IPv6 frame

            d. a non-BACnet frame

             

            So I agree that this info is missing, but it should formally be its own

            enumeration independent of frametype.


            >The second issue concerns the mechanics of specifying IP over MS/TP.
            >The way to do this is to write an "IP over Foo" RFC and get it
            >approved by the IETF. In our case, it's a multiple-body problem,
            >since we will be attempting to modify the MS/TP spec in parallel.
            >My immediate problem is how to specify IPv6 payloads in MS/TP
            >frames. The spec currently allows for non-BACnet frame types in the
            >128-255 range, with a 16-bit vendor ID as the first element in the
            >Data field (I guess we'd have to assign a vendor ID to the IETF).

            I don't think we should do it this way. I'm in favor of adding the

            additional parameter we discuss above and indicating an IPv6 frame.

            This is much more straightforward and avoids dealing with

            vendor ID and having to revise all the state machine language

            to deal with non-BACnet frames that could be long etc.


            >If we were to use FrameType 9 "Large Frame Not Expecting Reply"
            for
            >both BACnet and IPv6 payloads, we'd need to include a separate frame
            >type field in the payload to identify the "DSAP". That's why I
            >propose a separate FrameType for IPv6. (We'd still have > 100 in
            >reserve.)

            Agreed, see above. I'll revise the proposal this way.


            >I'll have some other comments on large frames soon. My main concern
            >has to do with the increased risk of undetected frame errors. I had
            >lunch last week with one of the original Ethernet guys and he said
            >their decision to go with CRC32 was based on the assumption that more
            >than one undetected error in five years was unacceptable.

            This would be possible but an even bigger change to the standard.

            First we would have to rewrite Annex G to include the CRC32 algorithm

            and C sample (and decide which polynomial to use). Then we would

            need to make revisions to the Clause 9 receive frame state machine because

            now we could not share the same data state with non-large frame types.

            So there would have to be a fair amount of new language that

            shows the data vs. large frame decision, and similar but

            different "data32" and "data32_crc" states.

             

            Before we bite off that much more work, I'd like to get some consensus

            that this is necessary.

             

            David Fisher

            PolarSoft® Inc.

            914 South Aiken Ave

            Pittsburgh PA 15232-2212

            dfisher@...

            www.polarsoft.biz

            412-683-2018

            412-683-5228 fax

             


            From: bacnet-mstpwg@yahoogroups.com [mailto: bacnet-mstpwg@yahoogroups.com ] On Behalf Of kerlyn2001
            Sent: Wednesday, February 16, 2011 5:58 PM
            To: bacnet-mstpwg@yahoogroups.com
            Subject: [bacnet-mstpwg] Re: Question on MS/TP Service Specification

             

             

            Sorry for the delayed response.

            I think there are two issues (but I'd like to get other opinions).
            The first is that Clause 9 seems to be contradictory in saying that
            non-BACnet frames are both supported and not supported. This should
            probably be fixed whether we approve large frames or not. I suspect
            that any real-world implementation that handles non-BACnet frames is
            passing FrameType across the DL interface. Might as well reflect
            that in the service specification.

            The second issue concerns the mechanics of specifying IP over MS/TP.
            The way to do this is to write an "IP over Foo" RFC and get it
            approved by the IETF. In our case, it's a multiple-body problem,
            since we will be attempting to modify the MS/TP spec in parallel.
            My immediate problem is how to specify IPv6 payloads in MS/TP
            frames. The spec currently allows for non-BACnet frame types in the
            128-255 range, with a 16-bit vendor ID as the first element in the
            Data field (I guess we'd have to assign a vendor ID to the IETF).

            If we were to use FrameType 9 "Large Frame Not Expecting Reply" for
            both BACnet and IPv6 payloads, we'd need to include a separate frame
            type field in the payload to identify the "DSAP". That's why I
            propose a separate FrameType for IPv6. (We'd still have > 100 in
            reserve.)

            I'll have some other comments on large frames soon. My main concern
            has to do with the increased risk of undetected frame errors. I had
            lunch last week with one of the original Ethernet guys and he said
            their decision to go with CRC32 was based on the assumption that more
            than one undetected error in five years was unacceptable.

            Regards, -K-

            --- In bacnet-mstpwg@yahoogroups.com, "David Fisher" <dfisher@...> wrote:

            >
            > Kerry,
            >
            >
            >
            > If and when we reach some agreement about the concept of a large frame
            type,
            >
            > which is the MSTP-WG purview, then we can make additional consideration
            >
            > and discussion of how this might integrate into other layer primitives.
            >
            >
            >
            > My thinking was that the large frame type could be used by the BACnet
            > network layer
            >
            > OR by an IP layer. As you point out, I suppose one could define additional
            > frametypes
            >
            > just for IP and treat these as effectively LSAPs. There are issues still
            to
            > be discussed
            >
            > though. For example for IP we really don't need large frame expecting
            reply,
            > so it's
            >
            > really only one more frametype which would be easy to add to this
            proposal.
            >
            >
            >
            > David Fisher
            >
            > PolarSoftR Inc.
            >
            > 914 South Aiken Ave
            >
            > Pittsburgh
            w:st="on">PA 15232-2212
            >
            > <mailto:dfisher@...> dfisher@...
            >
            > www.polarsoft.biz
            >
            > 412-683-2018
            >
            > 412-683-5228 fax
            >
            >
            >
            > _____
            >
            > From: bacnet-mstpwg@yahoogroups.com
            [mailto:bacnet-mstpwg@yahoogroups.com]
            > On Behalf Of kerlyn2001
            > Sent: Wednesday, February 09, 2011 8:44 PM
            > To: bacnet-mstpwg@yahoogroups.com
            > Subject: [bacnet-mstpwg] Question on MS/TP Service Specification
            >
            >
            >
            >
            >
            > The service primitives DL-UNITDATA.request and DL-UNITDATA.indication
            > are described in clause 9.1.1 and 9.1.2, respectively. These are
            > based on the ISO 8802-2 specification. The SA and DA parameters for
            > both primitives are described as follows:
            >
            > "Each source and destination address consists of a logical
            > concatenation of a medium access control (MAC) address and a link
            > service access point (LSAP). For the case of MS/TP devices, since
            > MS/TP supports only the BACnet network layer, the LSAP is omitted
            > and these parameters consist only of the device MAC address."
            >
            > In clause 9.5.6.2, ReceivedDataNoReply, the BACnet spec says:
            >
            > "If ReceivedValidFrame is true... and FrameType is equal to BACnet
            > Data Not Expecting Reply, Test_Response, or a proprietary type know
            > to this node... then indicate successful reception to the higher
            > layers..."
            >
            > My question is this - doesn't FrameType effectively communicate LSAP?
            > If so, why don't the abstract service primitives account for this?
            > How is FrameType generally communicated in practice to the upper
            > layers?
            >
            > The basis for my question concerns how to transmit data that is NOT
            > BACnet, e.g. native IP. It seems that one approach would be to use a
            > proprietary frame type. We might also choose to dedicate a frame type
            > from the reserved range. But I expect any proposal along those lines
            > would need to contain proposed changes to the spec regarding how to
            > communicate the frame type. Any comments/suggestions?
            >
            > Thanks, -K-
            >

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