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

Proposed tweaks to Addendum an

Expand Messages
  • Hartman, John
    I searched 135-2010 for DER and data_expecting_reply . They are used synonymously in enough places that it probably doesn t make sense to change them (see
    Message 1 of 1 , Jun 24, 2012

    I searched 135-2010 for “DER” and “data_expecting_reply”.  They are used synonymously in enough places that it probably doesn’t make sense to change them (see below if you care).


    The attached markup of Annex an is based on Kerry’s rc6.


    It brings back LSAP to make explicit how IPv6 and BACnet are demultiplexed at the DL-UNITDATA interface.  This seems consistent with the usage elsewhere in BACnet, and with the description in 8802-2.


    It removes frame-type as a DL_UNITDATA parameter: as far as I could tell, it was never referenced anywhere anyway.  Kerry (or anyone else): did I miss such a usage?  We are aided by the use of the phrase “pass to the higher layers”, such that the demultiplexing on reception is kept vague...


    I changed the “if you support extended frames you have to do this” to “if you don’t support extended frames you don’t have to do X”.  The need to implement the extended frame stuff seems obvious.  My aim is to reassure the timid folks who just want a simple non-extended implementation.


    There aren’t many other changes.  Most have an explanatory comment.


    The draft USUALLY uses Frame Type (capitalized) when referring to the byte in the message header.  It often uses “frame types” to refer to conceptual things like “frame types in the extended range...”.  But there are exceptions to both usages.  Personally, I would be pretty strict on this, but I realize that not everyone shares my anal-retentiveness.







    •             Defined in clause 3 as “data expecting reply”

    •             Used in Clause 5 as a parenthetical synonym for “data_expecting_reply”

    •             Shown in table 5-1 as a parameter to abstract service primitives

    •             Referenced in 6.8 Init routing table)

    •             Referenced in 9.3.6,  Data-expecting-reply frame, and 9.3.7, Data-no-expecting-reply frame, as a parameter of DL-UNITDATA.request



    •             Used (without underbars) in clause 3 definition of DER

    •             Used in Clause 5 definition of service-request parameters

    •             Used in 5.4.3 FillWindow and in the clause 5 state machines as a parameter to N-UNITDATA.request

    •             6.1 parameter of N-UNITDATA.request and N-UNITDATA.indication

    •             6.2 references the parameter of N-UNITDATA.request to define the state of the DERF bit in the NPCI octet

    •    parameter of DL-UNITDATA.request

    •    parameter of DL-UNITDATA.indication

    •             9.7.1 and 9.7.2 as parameter of the NPDU used for routing

    •             Various clause 24 messages tell how to set data_expecting_reply in the NPCI


    John Hartman

    Software Engineer

    Trane, an Ingersoll Rand Company

    Phone: 651-407-4162


    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.