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

RE: [bacnet-mstpwg] Re: Question on MS/TP Service Specification

Expand Messages
  • 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 1 of 4 , Feb 17, 2011

      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.