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

Source IPv6 address in forwarded messages et al.

Expand Messages
  • Isler, Bernhard
    Hi all, We have encountered an issue with Forwarded Messages that I think is not covered yet in any of the APR2 comments or discussions held. I refer to
    Message 1 of 4 , May 24, 2012

      Hi all,

       

      We have encountered an issue with Forwarded Messages that I think is not covered yet in any of the APR2 comments or discussions held. I refer to Add-135-2010aj-APR3-Draft-2.doc:

       

      In Clause X.4, first paragraph, last sentence, it says:

       

      “Multicasts to devices outside the address scope, or are otherwise unreachable by the multicast, shall be distributed by BBMDs in BVLL Forwarded-NPDUs.”

       

      The problem may occur when a device multicasts an Address-Resolution message. That is picked up by the BBMD and a Forwarded-Address-Resolution message is sent to the other BBMDs and the locally registered FDs.

      The message contains the source IPv6 address of the originating device, whose scope may be limited to the network/link, and may not be a global address. Actually that’s the very reason why BBMDs are required (underlined text above).

       

      Now the devices on the other network/link, if it tries to answer to the Forwarded-Address-Resolution message by returning a unicast Address-Resolution-Ack, it will use the original source IPv6 address. Thus, it may not reach the originating device because the address may not be valid in the network of the responding device.

       

      It appears necessary that a requirement is formulated that the original source IPv6 address in forwarded messages is required to be a global address, or at least the address with the largest scope. The original source device shall send its UDP package with the source address with broadest scope it has, since the device cannot know how far a BACnet broadcast is progressing in the Internet. Note that this may conflict with standard policies implemented in stacks for selection of the source address.

       

      Other points found in the draft (currently unclear on how far these are covered by APR2 comments or there were discussions on it):

      -          Distribute-Broadcast-To-Network is missing for both the Address-Resolution and the NPDUs to be broadcasted by FDs.

      -          It remains unclear why the Virtual-Address-Resolution and -Ack messages convey a parameter “Destination B/IPv6 Address”. This address is used at UDP layer and should therefore not be a BVLC message parameter.

       

      Best,

      Bernhard

       

       

      Bernhard Isler
      Siemens Switzerland Ltd
      Building Technologies Division
      IC BT CPS GDT AS
      Gubelstrasse 22
      CH-6301 Zug, Switzerland

      Tel: +41 (41) 724 33 87
      Mob: +41 (79) 561 77 23
      Fax: +41 (41) 723 48 94

      mailto:bernhard.isler@...
      http://www.siemens.com/buildingtechnologies

      Note: This e-mail may contain confidential information. If you have received this e-mail without being the proper recipient, you are hereby notified that any review, copying or distribution is strictly prohibited. Please inform us immediately and destroy the original transmittal. Any views or opinions presented are solely those of the author of this e-mail and do not necessarily represent those of Siemens Switzerland Ltd, unless otherwise specifically stated.

    • Hartman, John
      During yesterday s teleconference, I volunteered to draft some language about the return of the Command property to IDLE after each command completes. In doing
      Message 2 of 4 , May 24, 2012

        During yesterday’s teleconference, I volunteered to draft some language about the return of the Command property to IDLE after each command completes. 

         

        In doing so, I have encountered some possibly ambiguous cases.  For example:

         

        ROLLBACK

        If rolling back of changes is supported, this object shall attempt to revert to the set of property values that were contained in this object when Changes_Pending was first set to TRUE.  

         

        If rolling back of changes is not supported, writing this value shall result in an error response with ‘Error Class’ of PROPERTY and an ‘Error Code’ of OPTIONAL_FUNCTIONALITY_NOT_SUPPORTED.

         

        Any failure to roll back the values shall result in the value of the Reliability property being set to ROLLBACK_FAILURE and the value of this property being set to IDLE.

         

        (I have split the text into three paragraphs for clarity.  I think that this should be done in the draft)

         

        If the functionality is not supported and a device returns an error per paragraphs 2, should it also set Reliability to ROLLBACK_FAILURE per paragraph 3?  I would contend that it SHOULD NOT: the client attempted an action.  It was declined, but the object has not changed state.  Changes_Pending should remain true, and Reliability should be unchanged.

         

        Does anyone disagree?

         

        Similar cases exist for a RENEW_FD_REGISTRATION, RESTART_SLAVE_DISCOVERY, RENEW_DHCP, etc.

         

        I would propose that a device

        1.       Validate whether it can attempt an action: proper datalink type, proper options, etc.  If not, return an error and set  Command to IDLE, leaving Reliability and Changes_Pending unchanged

        2.       Attempt the action.

        3.       If the action fails, set Reliability to NO_FAULT_DELECTED, and Command to IDLE

        4.       If the action fails, set Reliability to SAD_XXX, and Command to IDLE

         





        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.
      • Carl Neilson
        John, For the 4 parts at the end of the proposal: Part 3 should read if the action fails succeeds... Part 4, I assume that SAD_XXX means whatever value is
        Message 3 of 4 , May 24, 2012

          John,

           

          For the 4 parts at the end of the proposal:

           

          Part 3 should read "if the action fails succeeds..."

           

          Part 4, I assume that SAD_XXX means "whatever value is appropriate for the failed action, or the failure's root cause".

           

          If this is the case, then I agree with your proposal.

           

          Carl

           

          From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com] On Behalf Of Hartman, John
          Sent: Thursday, May 24, 2012 9:02 AM
          To: bacnet-ip-wg@yahoogroups.com
          Cc: cbrumley@...
          Subject: [bacnet-ip-wg] Clarification of some Command actions in the Network Port object

           

           

          During yesterday’s teleconference, I volunteered to draft some language about the return of the Command property to IDLE after each command completes. 

           

          In doing so, I have encountered some possibly ambiguous cases.  For example:

           

          ROLLBACK

          If rolling back of changes is supported, this object shall attempt to revert to the set of property values that were contained in this object when Changes_Pending was first set to TRUE.  

           

          If rolling back of changes is not supported, writing this value shall result in an error response with ‘Error Class’ of PROPERTY and an ‘Error Code’ of OPTIONAL_FUNCTIONALITY_NOT_SUPPORTED.

           

          Any failure to roll back the values shall result in the value of the Reliability property being set to ROLLBACK_FAILURE and the value of this property being set to IDLE.

           

          (I have split the text into three paragraphs for clarity.  I think that this should be done in the draft)

           

          If the functionality is not supported and a device returns an error per paragraphs 2, should it also set Reliability to ROLLBACK_FAILURE per paragraph 3?  I would contend that it SHOULD NOT: the client attempted an action.  It was declined, but the object has not changed state.  Changes_Pending should remain true, and Reliability should be unchanged.

           

          Does anyone disagree?

           

          Similar cases exist for a RENEW_FD_REGISTRATION, RESTART_SLAVE_DISCOVERY, RENEW_DHCP, etc.

           

          I would propose that a device

          1.       Validate whether it can attempt an action: proper datalink type, proper options, etc.  If not, return an error and set  Command to IDLE, leaving Reliability and Changes_Pending unchanged

          2.       Attempt the action.

          3.       If the action fails, set Reliability to NO_FAULT_DELECTED, and Command to IDLE

          4.       If the action fails, set Reliability to SAD_XXX, and Command to IDLE

           


           



          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.

        • nomeekgeek
          I have just uploaded proposed text for 12.X.12 Command as JLH-Add-135-2010ai-PPR3-COMMAND-1.docx This got way more complicated than I expected. I signed up to
          Message 4 of 4 , May 29, 2012
            I have just uploaded proposed text for 12.X.12 Command as
            JLH-Add-135-2010ai-PPR3-COMMAND-1.docx

            This got way more complicated than I expected. I signed up to draft some introductory language about return to IDLE, but in so doing I found what appear to be a number of inconsistencies and ambiguities. The document is my attempt to clarify the sub-clause. Here is what I did:

            1. My belief is that if an Error (Result(-)) is returned, then NO CHANGE should be made to any properties of the object. I have updated the text to reflect this. For example, if you write ROLLBACK, and the device doesn't support ROLLBACK, you will get an Error, but the object will remain unchanged (Changes_Pending set, Reliability unaffected, and the object using whatever values it was using when Changes_Pending first got set.) Previous language called for Reliability to change. If you DO support rollback, but CAN'T for some reason, then Reliability would change.

            2. I have broken the descriptions into paragraphs in an attempt to enhance readability. This was done in 135-2010 clauses 12.26.4 and 12.31.14. (12.26.4 also doesn't indent the descriptive text to the right of the longest value names. This allows more text on a line, and may also enhance readability. The clause uses a paragraph with hanging first line rather than a table. I have an example of how this might be done at the end of the document).

            3. I moved most of the applies-to-all text from AFTER the value-specific text to the BEGINNING of the subclause, following the example of clause 12 etc. The idea is that the initial text gives the general rules, and the value-specific text gives details that apply only to each value

            4. The draft uses "error response" various places in 12.X.7, 12.X.9 and 12.X.12. I believe that these should all be "Result(-)" following the usages elsewhere. In clause 12 (12.10, 12.12.8, 12.15.13, etc). I have updated the text that follows to use Result(-).

            There are also a number of JLH comments where I am unsure about direction
          Your message has been successfully submitted and would be delivered to recipients shortly.