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

Re: [bacnet-mstpwg] Addendum an: LSAP, DER

Expand Messages
  • Kerry Lynn
    Hi John, I agree that the existing DL primitives must remain as-is. The solution to the union of the issues raised by you and Clif, I think, is to specify a
    Message 1 of 5 , Jun 24, 2012
    • 0 Attachment
      Hi John,

      I agree that the existing DL primitives must remain as-is.  The solution
      to the union of the issues raised by you and Clif, I think, is to specify
      a second pair of "Extended" DL primitives that interact with the current
      i/f:

            BACnet N-UNITDATA.request      IPv6 or other client
                            |                         |
                            v                         |
      existing:   DL-UNITDATA.request(..., DER)       |
                            |                         |
                    thin conversion shim              |
                            |                         |
                            +-------------------------+
                            |
                            v
      extended:   DL-UNITDATA.request(..., FT)



            BACnet N-UNITDATA.indication   IPv6 or other N-UNITDATA.indication
                            ^                         ^
                            |                         |
      existing:   DL-UNITDATA.indication(..., DER)    |
                            |                         |
                            +-------------------------+
                            |
                    thin dispatch shim
                            ^
                            |
      extended:   DL-UNITDATA.indication(..., FT)


      I don't want to get too hung up on an overly-literal interpretation of
      8802-2; I think you will agree that the current BACnet MS/TP i/f adds
      the 'data_expecting_reply' flag, which isn't in the international std.
      By the same token (excuse the pun), substituting 'frame_type' for LSAP
      seems perfectly reasonable to me.  This conforms to the original DIX
      Ethernet standard, which I can show you in the AM.  We can keep the
      same primitive names or change them to e.g. TransmitFrame() and
      ReceiveFrame() - whatever people prefer.

      Hopefully this issue won't prevent voting this work out of SSPC
      tomorrow and sharing it with a wider audience.

      Regards, -K-


      On Sun, Jun 24, 2012 at 7:14 PM, nomeekgeek <jhartman@...> wrote:
       

      135-2010 9.1.1.2 says

      "Each source and destination address consists of the 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 of only the device MAC address."

      The proposed 9.1.1.2 says

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

      Since we want to carry BOTH BACnet and IPv6 frames, we must either INCLUDE an LSAP, or the interface with IPv6 must use some mechanism other than DL-UNITDATA primitives.  The "some other mechanism" seems like a rat hole, so I propose LSAP.

      Compare clause 7.2, which defines BACnet over 8802-3 (non-IP Ethernet): "The LSAP is the single-octet value X'82' and is used to indicate that an LSDU contains BACnet data."  That is, the 8802-3 DL-UNITDATA interface contains an LSAP to do protocol demultiplexing, just as we wish to do.

      I would propose that 9.1.1.2 read something like:

      "Each source and destination address consists of the logical concatenation of a medium access control (MAC) address and a link service access point (LSAP).  If an implementation of MS/TP supports only the BACnet network layer, the LSAP may be omitted, and these parameters consist of only the device MAC address.  If the implementation also supports other network layers, such as IPv6, the LSAP is used to distinguish between BACnet and the other network layers.

      The remainder of Addendum an (and the non-modified parts of clause 9) would need to be scrutized to see where updates are required.  Basically

      ·         Wherever "DER" and data_expecting_reply appear

      ·         Wherever the text talks about passing incoming frames to higher layers.

      I will work on doing that this evening, and send such updates as I have


    • Hartman, John
      I don t see that any shim is needed. The + fork in your diagrams is a mux/demux, and that is the function of LSAP. On clause 7 or 8 BACnet, you specify an
      Message 2 of 5 , Jun 24, 2012
      • 0 Attachment

        I don’t see that any shim is needed.  The “+” fork in your diagrams is a mux/demux, and that is the function of LSAP.  On clause 7 or 8 BACnet, you specify an 8802-2 LSAP of 0x82.  If you wanted SNAP or some other 8802-2 based protocol, you would use its LSAP.  So the conceptual LSAP does the job without the need to define (or explain) a shim.

         

        Regarding the frame_type parameter to DL_UNITDATA, I didn’t see that you actually USED it anywhere except for the DL-UNITDATA sections themselves.  You had language to the effect “that is expecting a reply”, which changed back to DER.

         

         

        When a frame is received, the extended/not-extended details are dealt with by the TSMs, and the result is handled by the “upper layers”, with no details about the demultiplexing.

         

        During transmission, the type of frame to be used is IMPLIED in the extended frame definitions: “...whose DER parameter is TRUE  and whose length is greater than 501 octets.”.

         

        BUT: it appears that we (including my recent draft) missed equivalent language tweaks in the non-extended versions.  I would propose changing 135-2010’s

        9.3. 6 Frame Type 05: BACnet Data Expecting Reply

        This frame is used by master nodes to convey the data parameter of a DL_UNITDATA.request whose DER parameter is

        TRUE. The length of the data portion of a BACnet Data Expecting Reply frame may range from 0 to 501 octets.

        to

        This frame is used by master nodes to convey the data parameter of a DL_UNITDATA.request whose DER parameter is

        TRUE and whose length is between 0 and 501 octets.

         

        And change

        9.3.7 Frame Type 06: BACnet Data Not Expecting Reply

        This frame is used to convey the data parameter of a DL_UNITDATA.request whose DER parameter is FALSE. The length

        of the data portion of a BACnet Data Not Expecting Reply frame may range from 0 to 501 octets.

        to

        This frame is used to convey the data parameter of a DL_UNITDATA.request whose DER parameter is FALSE and whose length is between 0 and 501 octets.

         

        It would probably be better to state this explicitly in 9.1.1.4, which supposedly says what to do when a DL-UNITDATA.request is received.  It currently says only

        9.1.1.4 Effect on Receipt

        Receipt of this primitive causes the MS/TP entity to attempt to send the NPDU using unacknowledged connectionless-mode

        procedures.

         

        That is pretty wimpy.  How about

        Receipt of this primitive causes the MS/TP entity to attempt to send the NPDU using unacknowledged connectionless-mode

        procedures. 

         

        If the destination LSAP indicates that the ‘data’ parameter is a BACnet NPDU, then the Frame Type of the frame queued for transmission shall be

        ·         BACnet Data Not Expecting Reply, if data_expecting_reply is FALSE and the length of the data is between 0 and 501 octets.

        ·         BACnet Data Expecting Reply, if data_expecting_reply is TRUE and the length of the data is between 0 and 501 octets.

        ·         BACnet Extended Data Not Expecting Reply, if the devices supports Extended Frames, and data_expecting_reply is FALSE and the length of the data is between 502 and 1497 octets.

        ·         BACnet Extended Data Expecting Reply, if the devices supports Extended Frames, and data_expecting_reply is TRUE and the length of the data is between 502 and 1497 octets.

         

        If the destination LSAP indicates that the ‘data’ parameter is an IPv6 NPDU, then the Frame Type of the frame queued for transmission shall be IPv6 Encapsulation.

         

        The handling of DL-UNITDATA.request primitives which cannot be processed, whether because of an unknown destination LSAP, the inability of the implementation to send data of the specified length, or for any other reason is a local matter, since it is not visible on the network.  In most cases, an error should be returned to the entity that invoked the DL-UNITDATA.request.

         

        From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
        Sent: Sunday, June 24, 2012 9:41 PM
        To: bacnet-mstpwg@yahoogroups.com
        Subject: Re: [bacnet-mstpwg] Addendum an: LSAP, DER

         




        Hi John,

         

        I agree that the existing DL primitives must remain as-is.  The solution

        to the union of the issues raised by you and Clif, I think, is to specify

        a second pair of "Extended" DL primitives that interact with the current

        i/f:

         

              BACnet N-UNITDATA.request      IPv6 or other client

                              |                         |

                              v                         |

        existing:   DL-UNITDATA.request(..., DER)       |

                              |                         |

                      thin conversion shim              |

                              |                         |

                              +-------------------------+

                              |

                              v

        extended:   DL-UNITDATA.request(..., FT)

         

         

         

              BACnet N-UNITDATA.indication   IPv6 or other N-UNITDATA.indication

                              ^                         ^

                              |                         |

        existing:   DL-UNITDATA.indication(..., DER)    |

                              |                         |

                              +-------------------------+

                              |

                      thin dispatch shim

                              ^

                              |

        extended:   DL-UNITDATA.indication(..., FT)

         

         

        I don't want to get too hung up on an overly-literal interpretation of

        8802-2; I think you will agree that the current BACnet MS/TP i/f adds

        the 'data_expecting_reply' flag, which isn't in the international std.

        By the same token (excuse the pun), substituting 'frame_type' for LSAP

        seems perfectly reasonable to me.  This conforms to the original DIX

        Ethernet standard, which I can show you in the AM.  We can keep the

        same primitive names or change them to e.g. TransmitFrame() and

        ReceiveFrame() - whatever people prefer.

         

        Hopefully this issue won't prevent voting this work out of SSPC

        tomorrow and sharing it with a wider audience.

         

        Regards, -K-

         

         

        On Sun, Jun 24, 2012 at 7:14 PM, nomeekgeek <jhartman@...> wrote:

         

        135-2010 9.1.1.2 says

        "Each source and destination address consists of the 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 of only the device MAC address."

        The proposed 9.1.1.2 says

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

        Since we want to carry BOTH BACnet and IPv6 frames, we must either INCLUDE an LSAP, or the interface with IPv6 must use some mechanism other than DL-UNITDATA primitives.  The "some other mechanism" seems like a rat hole, so I propose LSAP.

        Compare clause 7.2, which defines BACnet over 8802-3 (non-IP Ethernet): "The LSAP is the single-octet value X'82' and is used to indicate that an LSDU contains BACnet data."  That is, the 8802-3 DL-UNITDATA interface contains an LSAP to do protocol demultiplexing, just as we wish to do.

        I would propose that 9.1.1.2 read something like:

        "Each source and destination address consists of the logical concatenation of a medium access control (MAC) address and a link service access point (LSAP).  If an implementation of MS/TP supports only the BACnet network layer, the LSAP may be omitted, and these parameters consist of only the device MAC address.  If the implementation also supports other network layers, such as IPv6, the LSAP is used to distinguish between BACnet and the other network layers.

        The remainder of Addendum an (and the non-modified parts of clause 9) would need to be scrutized to see where updates are required.  Basically

        ·         Wherever "DER" and data_expecting_reply appear

        ·         Wherever the text talks about passing incoming frames to higher layers.

        I will work on doing that this evening, and send such updates as I have

         







        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.
      • Kerry Lynn
        Hi John, My main point is that LSAP (and probably DL-UNITDATA) is an 8802-2 concept. IPv6 packets are not SNAP encapsulated on 8802-3, and the idea of doing
        Message 3 of 5 , Jun 24, 2012
        • 0 Attachment
          Hi John,

          My main point is that 'LSAP' (and probably DL-UNITDATA) is an 8802-2 concept.
          IPv6 packets are not SNAP encapsulated on 8802-3, and the idea of doing it over
          MS/TP makes even less sense.  How do you suggest we proceed?


          MA-UNITDATA primitives expect everything to be formatted and ready-to-fly.
          Clearly, there's a need for an i/f above this but I feel that MS/TP should
          dispatch to the existing DL-UNITDATA primitives if it's a BACnet NPDU and
          call some other indication, passing frame_type, if not.

          How have people been handling proprietary frames all these years without
          passing frame_type?

          -K-

          On Sun, Jun 24, 2012 at 10:29 PM, Hartman, John <jhartman@...> wrote:
           

          I don’t see that any shim is needed.  The “+” fork in your diagrams is a mux/demux, and that is the function of LSAP.  On clause 7 or 8 BACnet, you specify an 8802-2 LSAP of 0x82.  If you wanted SNAP or some other 8802-2 based protocol, you would use its LSAP.  So the conceptual LSAP does the job without the need to define (or explain) a shim.

           

          Regarding the frame_type parameter to DL_UNITDATA, I didn’t see that you actually USED it anywhere except for the DL-UNITDATA sections themselves.  You had language to the effect “that is expecting a reply”, which changed back to DER.

           

           

          When a frame is received, the extended/not-extended details are dealt with by the TSMs, and the result is handled by the “upper layers”, with no details about the demultiplexing.

           

          During transmission, the type of frame to be used is IMPLIED in the extended frame definitions: “...whose DER parameter is TRUE  and whose length is greater than 501 octets.”.

           

          BUT: it appears that we (including my recent draft) missed equivalent language tweaks in the non-extended versions.  I would propose changing 135-2010’s

          9.3. 6 Frame Type 05: BACnet Data Expecting Reply

          This frame is used by master nodes to convey the data parameter of a DL_UNITDATA.request whose DER parameter is

          TRUE. The length of the data portion of a BACnet Data Expecting Reply frame may range from 0 to 501 octets.

          to

          This frame is used by master nodes to convey the data parameter of a DL_UNITDATA.request whose DER parameter is

          TRUE and whose length is between 0 and 501 octets.

           

          And change

          9.3.7 Frame Type 06: BACnet Data Not Expecting Reply

          This frame is used to convey the data parameter of a DL_UNITDATA.request whose DER parameter is FALSE. The length

          of the data portion of a BACnet Data Not Expecting Reply frame may range from 0 to 501 octets.

          to

          This frame is used to convey the data parameter of a DL_UNITDATA.request whose DER parameter is FALSE and whose length is between 0 and 501 octets.

           

          It would probably be better to state this explicitly in 9.1.1.4, which supposedly says what to do when a DL-UNITDATA.request is received.  It currently says only

          9.1.1.4 Effect on Receipt

          Receipt of this primitive causes the MS/TP entity to attempt to send the NPDU using unacknowledged connectionless-mode

          procedures.

           

          That is pretty wimpy.  How about

          Receipt of this primitive causes the MS/TP entity to attempt to send the NPDU using unacknowledged connectionless-mode

          procedures. 

           

          If the destination LSAP indicates that the ‘data’ parameter is a BACnet NPDU, then the Frame Type of the frame queued for transmission shall be

          ·         BACnet Data Not Expecting Reply, if data_expecting_reply is FALSE and the length of the data is between 0 and 501 octets.

          ·         BACnet Data Expecting Reply, if data_expecting_reply is TRUE and the length of the data is between 0 and 501 octets.

          ·         BACnet Extended Data Not Expecting Reply, if the devices supports Extended Frames, and data_expecting_reply is FALSE and the length of the data is between 502 and 1497 octets.

          ·         BACnet Extended Data Expecting Reply, if the devices supports Extended Frames, and data_expecting_reply is TRUE and the length of the data is between 502 and 1497 octets.

           

          If the destination LSAP indicates that the ‘data’ parameter is an IPv6 NPDU, then the Frame Type of the frame queued for transmission shall be IPv6 Encapsulation.

           

          The handling of DL-UNITDATA.request primitives which cannot be processed, whether because of an unknown destination LSAP, the inability of the implementation to send data of the specified length, or for any other reason is a local matter, since it is not visible on the network.  In most cases, an error should be returned to the entity that invoked the DL-UNITDATA.request.

           

          From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
          Sent: Sunday, June 24, 2012 9:41 PM
          To: bacnet-mstpwg@yahoogroups.com
          Subject: Re: [bacnet-mstpwg] Addendum an: LSAP, DER

           




          Hi John,

           

          I agree that the existing DL primitives must remain as-is.  The solution

          to the union of the issues raised by you and Clif, I think, is to specify

          a second pair of "Extended" DL primitives that interact with the current

          i/f:

           

                BACnet N-UNITDATA.request      IPv6 or other client

                                |                         |

                                v                         |

          existing:   DL-UNITDATA.request(..., DER)       |

                                |                         |

                        thin conversion shim              |

                                |                         |

                                +-------------------------+

                                |

                                v

          extended:   DL-UNITDATA.request(..., FT)

           

           

           

                BACnet N-UNITDATA.indication   IPv6 or other N-UNITDATA.indication

                                ^                         ^

                                |                         |

          existing:   DL-UNITDATA.indication(..., DER)    |

                                |                         |

                                +-------------------------+

                                |

                        thin dispatch shim

                                ^

                                |

          extended:   DL-UNITDATA.indication(..., FT)

           

           

          I don't want to get too hung up on an overly-literal interpretation of

          8802-2; I think you will agree that the current BACnet MS/TP i/f adds

          the 'data_expecting_reply' flag, which isn't in the international std.

          By the same token (excuse the pun), substituting 'frame_type' for LSAP

          seems perfectly reasonable to me.  This conforms to the original DIX

          Ethernet standard, which I can show you in the AM.  We can keep the

          same primitive names or change them to e.g. TransmitFrame() and

          ReceiveFrame() - whatever people prefer.

           

          Hopefully this issue won't prevent voting this work out of SSPC

          tomorrow and sharing it with a wider audience.

           

          Regards, -K-

           

           

          On Sun, Jun 24, 2012 at 7:14 PM, nomeekgeek <jhartman@...> wrote:

           

          135-2010 9.1.1.2 says

          "Each source and destination address consists of the 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 of only the device MAC address."

          The proposed 9.1.1.2 says

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

          Since we want to carry BOTH BACnet and IPv6 frames, we must either INCLUDE an LSAP, or the interface with IPv6 must use some mechanism other than DL-UNITDATA primitives.  The "some other mechanism" seems like a rat hole, so I propose LSAP.

          Compare clause 7.2, which defines BACnet over 8802-3 (non-IP Ethernet): "The LSAP is the single-octet value X'82' and is used to indicate that an LSDU contains BACnet data."  That is, the 8802-3 DL-UNITDATA interface contains an LSAP to do protocol demultiplexing, just as we wish to do.

          I would propose that 9.1.1.2 read something like:

          "Each source and destination address consists of the logical concatenation of a medium access control (MAC) address and a link service access point (LSAP).  If an implementation of MS/TP supports only the BACnet network layer, the LSAP may be omitted, and these parameters consist of only the device MAC address.  If the implementation also supports other network layers, such as IPv6, the LSAP is used to distinguish between BACnet and the other network layers.

          The remainder of Addendum an (and the non-modified parts of clause 9) would need to be scrutized to see where updates are required.  Basically

          ·         Wherever "DER" and data_expecting_reply appear

          ·         Wherever the text talks about passing incoming frames to higher layers.

          I will work on doing that this evening, and send such updates as I have

           







          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.


        • Hartman, John
          Clearly, my message was not received as I intended it. It seems that I used an unacknowledged-communicationless data transfer service.... I DID NOT suggest
          Message 4 of 5 , Jun 25, 2012
          • 0 Attachment

            Clearly, my message was not received as I intended it.  It seems that I used an unacknowledged-communicationless data transfer service....

             

            I DID NOT suggest that we use SNAP: it was the only other 8802-2 LSAP that I could think of, and it wasn’t worth the Google search to find another.

             

            I DID NOT suggest that we implement 8802-2 on MS/TP.  The first sentence in 135-2010 clause 9 reads

             

            This clause describes a Master-Slave/Token-Passing (MS/TP) data link protocol, which provides the same services to the network layer as ISO 8802-2 Logical Link Control.

             

            When the standard was written, few of us had ever seen in IP network.  We used the semantics of 8802-2’s UNIDATA as a convenient way to describe an interface, largely because the 8802 standards were held to be examples of the holy and beautiful 7-layer ISO/OSI model.  On ARCNET and Ethernet, it mapped directly to “real” 8802-2.  On the other datalinks we just used the interface.  (Disagreement with my recollections will be entertained only if accompanied by beer)

             

            My point was that “frame_type” is a bad fit for the datalink interface, while LSAP is a standard PART of the interface. 

             

            Everyone involved with writing clause 9 was aware that data_expecting_reply was an embarrassment.  But it is also necessary for immediate reply, and immediate reply can give BIG speedup on a typical MS/TP network, even if there are no slaves.  So data_expecting reply was added to the network header, so that no (or at least fewer) immoral layer violations would be needed.  We COULD have added data_expecting_reply to our version of UNITDATA in clause 7 and 8, but we didn’t.

             

            People have been “handing proprietary frames all these years” in proprietary ways that may or may not involve passing frame type.  The point of my proposal is that the semi-conceptual LSAP is a clean and standard way of passing the “which network layer” info across the interface.

             

            If you pass in frame type, then the network layer needs to determine the frame type, or a shim is required as you propose.  If we use and LSAP, it will have a few values: BACnet, IPv6, maybe Proprietary if I use that.  A simple, clean description that exposes as little as possible of the guts of MS/TP.

             

            Where do we go from here?  Well, we could incorporate some or all of the language that I propose.  Or we could incorporage some or all of what you propose.  When we think we have good language, we vote it out for review.  And then we and the larger community takes a long hard look at it.

             

             

            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
            Sent: Sunday, June 24, 2012 10:53 PM
            To: bacnet-mstpwg@yahoogroups.com
            Subject: Re: [bacnet-mstpwg] Addendum an: LSAP, DER

             



            Hi John,

             

            My main point is that 'LSAP' (and probably DL-UNITDATA) is an 8802-2 concept.

            IPv6 packets are not SNAP encapsulated on 8802-3, and the idea of doing it over

            MS/TP makes even less sense.  How do you suggest we proceed?

             

             

            MA-UNITDATA primitives expect everything to be formatted and ready-to-fly.

            Clearly, there's a need for an i/f above this but I feel that MS/TP should

            dispatch to the existing DL-UNITDATA primitives if it's a BACnet NPDU and

            call some other indication, passing frame_type, if not.

             

            How have people been handling proprietary frames all these years without

            passing frame_type?

             

            -K-

             

            On Sun, Jun 24, 2012 at 10:29 PM, Hartman, John <jhartman@...> wrote:

             

            I don’t see that any shim is needed.  The “+” fork in your diagrams is a mux/demux, and that is the function of LSAP.  On clause 7 or 8 BACnet, you specify an 8802-2 LSAP of 0x82.  If you wanted SNAP or some other 8802-2 based protocol, you would use its LSAP.  So the conceptual LSAP does the job without the need to define (or explain) a shim.

             

            Regarding the frame_type parameter to DL_UNITDATA, I didn’t see that you actually USED it anywhere except for the DL-UNITDATA sections themselves.  You had language to the effect “that is expecting a reply”, which changed back to DER.

             

             

            When a frame is received, the extended/not-extended details are dealt with by the TSMs, and the result is handled by the “upper layers”, with no details about the demultiplexing.

             

            During transmission, the type of frame to be used is IMPLIED in the extended frame definitions: “...whose DER parameter is TRUE  and whose length is greater than 501 octets.”.

             

            BUT: it appears that we (including my recent draft) missed equivalent language tweaks in the non-extended versions.  I would propose changing 135-2010’s

            9.3. 6 Frame Type 05: BACnet Data Expecting Reply

            This frame is used by master nodes to convey the data parameter of a DL_UNITDATA.request whose DER parameter is

            TRUE. The length of the data portion of a BACnet Data Expecting Reply frame may range from 0 to 501 octets.

            to

            This frame is used by master nodes to convey the data parameter of a DL_UNITDATA.request whose DER parameter is

            TRUE and whose length is between 0 and 501 octets.

             

            And change

            9.3.7 Frame Type 06: BACnet Data Not Expecting Reply

            This frame is used to convey the data parameter of a DL_UNITDATA.request whose DER parameter is FALSE. The length

            of the data portion of a BACnet Data Not Expecting Reply frame may range from 0 to 501 octets.

            to

            This frame is used to convey the data parameter of a DL_UNITDATA.request whose DER parameter is FALSE and whose length is between 0 and 501 octets.

             

            It would probably be better to state this explicitly in 9.1.1.4, which supposedly says what to do when a DL-UNITDATA.request is received.  It currently says only

            9.1.1.4 Effect on Receipt

            Receipt of this primitive causes the MS/TP entity to attempt to send the NPDU using unacknowledged connectionless-mode

            procedures.

             

            That is pretty wimpy.  How about

            Receipt of this primitive causes the MS/TP entity to attempt to send the NPDU using unacknowledged connectionless-mode

            procedures. 

             

            If the destination LSAP indicates that the ‘data’ parameter is a BACnet NPDU, then the Frame Type of the frame queued for transmission shall be

            ·         BACnet Data Not Expecting Reply, if data_expecting_reply is FALSE and the length of the data is between 0 and 501 octets.

            ·         BACnet Data Expecting Reply, if data_expecting_reply is TRUE and the length of the data is between 0 and 501 octets.

            ·         BACnet Extended Data Not Expecting Reply, if the devices supports Extended Frames, and data_expecting_reply is FALSE and the length of the data is between 502 and 1497 octets.

            ·         BACnet Extended Data Expecting Reply, if the devices supports Extended Frames, and data_expecting_reply is TRUE and the length of the data is between 502 and 1497 octets.

             

            If the destination LSAP indicates that the ‘data’ parameter is an IPv6 NPDU, then the Frame Type of the frame queued for transmission shall be IPv6 Encapsulation.

             

            The handling of DL-UNITDATA.request primitives which cannot be processed, whether because of an unknown destination LSAP, the inability of the implementation to send data of the specified length, or for any other reason is a local matter, since it is not visible on the network.  In most cases, an error should be returned to the entity that invoked the DL-UNITDATA.request.

             

            From: bacnet-mstpwg@yahoogroups.com [mailto:bacnet-mstpwg@yahoogroups.com] On Behalf Of Kerry Lynn
            Sent: Sunday, June 24, 2012 9:41 PM
            To: bacnet-mstpwg@yahoogroups.com
            Subject: Re: [bacnet-mstpwg] Addendum an: LSAP, DER

             



            Hi John,

             

            I agree that the existing DL primitives must remain as-is.  The solution

            to the union of the issues raised by you and Clif, I think, is to specify

            a second pair of "Extended" DL primitives that interact with the current

            i/f:

             

                  BACnet N-UNITDATA.request      IPv6 or other client

                                  |                         |

                                  v                         |

            existing:   DL-UNITDATA.request(..., DER)       |

                                  |                         |

                          thin conversion shim              |

                                  |                         |

                                  +-------------------------+

                                  |

                                  v

            extended:   DL-UNITDATA.request(..., FT)

             

             

             

                  BACnet N-UNITDATA.indication   IPv6 or other N-UNITDATA.indication

                                  ^                         ^

                                  |                         |

            existing:   DL-UNITDATA.indication(..., DER)    |

                                  |                         |

                                  +-------------------------+

                                  |

                          thin dispatch shim

                                  ^

                                  |

            extended:   DL-UNITDATA.indication(..., FT)

             

             

            I don't want to get too hung up on an overly-literal interpretation of

            8802-2; I think you will agree that the current BACnet MS/TP i/f adds

            the 'data_expecting_reply' flag, which isn't in the international std.

            By the same token (excuse the pun), substituting 'frame_type' for LSAP

            seems perfectly reasonable to me.  This conforms to the original DIX

            Ethernet standard, which I can show you in the AM.  We can keep the

            same primitive names or change them to e.g. TransmitFrame() and

            ReceiveFrame() - whatever people prefer.

             

            Hopefully this issue won't prevent voting this work out of SSPC

            tomorrow and sharing it with a wider audience.

             

            Regards, -K-

             

             

            On Sun, Jun 24, 2012 at 7:14 PM, nomeekgeek <jhartman@...> wrote:

             

            135-2010 9.1.1.2 says

            "Each source and destination address consists of the 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 of only the device MAC address."

            The proposed 9.1.1.2 says

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

            Since we want to carry BOTH BACnet and IPv6 frames, we must either INCLUDE an LSAP, or the interface with IPv6 must use some mechanism other than DL-UNITDATA primitives.  The "some other mechanism" seems like a rat hole, so I propose LSAP.

            Compare clause 7.2, which defines BACnet over 8802-3 (non-IP Ethernet): "The LSAP is the single-octet value X'82' and is used to indicate that an LSDU contains BACnet data."  That is, the 8802-3 DL-UNITDATA interface contains an LSAP to do protocol demultiplexing, just as we wish to do.

            I would propose that 9.1.1.2 read something like:

            "Each source and destination address consists of the logical concatenation of a medium access control (MAC) address and a link service access point (LSAP).  If an implementation of MS/TP supports only the BACnet network layer, the LSAP may be omitted, and these parameters consist of only the device MAC address.  If the implementation also supports other network layers, such as IPv6, the LSAP is used to distinguish between BACnet and the other network layers.

            The remainder of Addendum an (and the non-modified parts of clause 9) would need to be scrutized to see where updates are required.  Basically

            ·         Wherever "DER" and data_expecting_reply appear

            ·         Wherever the text talks about passing incoming frames to higher layers.

            I will work on doing that this evening, and send such updates as I have

             



             



            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.

             







            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.