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

NAT after Germantown

Expand Messages
  • Donaldson, Stuart (WA26)
    So in going through my notes from Germantown, the direction on the NAT was to incorporate a BVLL into the RL-002 proposal because there were situations from a
    Message 1 of 3 , May 9, 2006
    View Source
    • 0 Attachment

      So in going through my notes from Germantown , the direction on the NAT was to incorporate a BVLL into the RL-002 proposal because there were situations from a standards compatibility basis with NAT that would not work. However the group wanted to do this without breaking existing solutions.

       

      Would this look like a per-entry flag to indicate whether messages to that BBMD should use the new BVLL with routing info? 

           i)  If so, should we worry about not being able to set this with the existing messages to write a BDT?  

           ii) Should we leave it up to a future Network Port object to handle configuration?

           iii) Should it be done through a global configuration that says the devices listed in the public BDT optionally use the new BVLL?

       

      Also, this still leaves the issue of foreign device registration, and how it should work through NAT.   I recall some support for a new register foreign device command that would cause the routing to be handled correctly through the router as well.

       

      Another idea came up here, would it make sense to try and handle NAT foreign device registration through a new Register Foreign Device service over a TCP connection rather than UDP?

       

      Stuart Donaldson
      Software Engineering Lead

      Honeywell / Alerton

      6670 185th Ave NE

      Redmond, WA 98052

      Office:    +1 425 869 8400

       

    • Roland Laird
      Message 2 of 3 , May 26, 2006
      View Source
      • 0 Attachment
        NAT after Germantown

        Stuart and B/IPers,

        These are hard questions. I don't like the situation of having multiple methods to configure the BDT. My current bias is to take the easy way out and leave it as a "local matter".

        In adding the NAT-Unicast to BBMD Devices, FDs will have to support it as well. It also makes sense to provide a new Register-Foreign-Device-NAT BVLLl. This not only provides a guaranteed B/IP that the FD can be accessed with, it also provides a mechanism whereby the BBMD knows whether or not the FD supports NAT-Unicast.

        I don't support the idea of making a Register-Foreign-Device over TCP (though it would keep the session open) because B/IP is totally based on UDP, and making this exception would involve a whole new set of compilcations.

        In order to add in the concept of a NAT-Unicast BVLL I think the following needs to be done to RL-002:
        1. Define Original-NAT-Unicast-NPDU BVLL in J.2
        2. Define  Register-NAT-Foreign-Device BVLL in J.2
        3. Add to J.3 "BACnet/IP Directed Messages", an explanation of of when to use the NAT-Unicast.
                a) When Nat enabled
                        - on unicast messages from a BBMD Device/Router  to B/IP addresses that are flagged in the BDT as supporting Unicast-NAT

                        - on unicast messages to FD's registered with Register-NAT
                b) By FDs when they have been able to successfully register with Register-NAT…
        4. Add to J.5.2 "Foreign Device Table" the explanation of the new Register-NAT-FD BVLL
                - specify that FD's fall back to the regular Register-FD if a success Result is not returned.
        5. Annex A Conformance option added.

        Have I got something wrong or am  I missing something?

        I don't think the group reach a consensus that these changes are nessesary, but I will add them so we can see what it looks like.

        Roland

        From Stuart:
        So in going through my notes from Germantown, the direction on the NAT was to incorporate a BVLL into the RL-002 proposal because there were situations from a standards compatibility basis with NAT that would not work. However the group wanted to do this without breaking existing solutions.

        Would this look like a per-entry flag to indicate whether messages to that BBMD should use the new BVLL with routing info?

        i) If so, should we worry about not being able to set this with the existing messages to write a BDT?
        ii) Should we leave it up to a future Network Port object to handle configuration?
        iii) Should it be done through a global configuration that says the devices listed in the public BDT optionally use the new BVLL?

        Also, this still leaves the issue of foreign device registration, and how it should work through NAT. I recall some support for a new register foreign device command that would cause the routing to be handled correctly through the router as well.

        Another idea came up here, would it make sense to try and handle NAT foreign device registration through a new Register Foreign Device service over a TCP connection rather than UDP?

        Stuart Donaldson
        Software Engineering Lead
        Honeywell / Alerton
        6670 185th Ave NE
        Redmond, WA 98052
        Office: +1 425 869 8400

      • Matsen, Dean (WA26)
        Roland wrote Register-Foreign-Device-NAT BVLLl. This not only provides a guaranteed B/IP that the FD can be accessed with, it also provides a mechanism
        Message 3 of 3 , Jun 6, 2006
        View Source
        • 0 Attachment
          NAT after Germantown

          Roland wrote

           

          " Register-Foreign-Device-NAT BVLLl. This not only provides a guaranteed B/IP that the FD can be accessed with, it also provides a mechanism whereby the BBMD knows whether or not the FD supports NAT-Unicast."

           

          I tried this when I was experimenting with work-arounds to the various NAT problems, and I found out the hard way that other devices besides the BBMD wind up talking to FDs (ie: other BBMDs that are peers of the BBMD with which the device is registered).  Those BBMDs do not "know" how the FD registered, so the other BBMDs wind up sending the NAT-Unicast message.  

           

          This is the main reason for suggesting the TCP/IP solution – it would get around that problem by mandating that all traffic go through the correct BBMD.  It may be possible to avoid this issue by limiting the routing scenarios.

           

          Also, according to Stuart, the concept was not specifically a "NAT-Unicast BVLL" per se, but rather to have a BVLL wrapper with a source B/IP address in it, and which contains another BVLL inside it.  It was my understanding that there was some agreement on this, because all BVLLs are subject to the same set of problems, including "Read BDT", "Read FDT", etc...  Having a general wrapper message would allow a requestor to embed the return information in any existing message.

           

          Regards,

          Dean

          I

           


          From: bacnet-ip-wg@yahoogroups.com [mailto: bacnet-ip-wg@yahoogroups.com ] On Behalf Of Roland Laird
          Sent: Friday, May 26, 2006 8:01 AM
          To: BACnet-IP-WG@yahoogroups.com
          Subject: [bacnet-ip-wg] NAT after Germantown

           

           

          Stuart and B/IPers,

          These are hard questions. I don't like the situation of having multiple methods to configure the BDT. My current bias is to take the easy way out and leave it as a "local matter".

          In adding the NAT-Unicast to BBMD Devices, FDs will have to support it as well. It also makes sense to provide a new Register-Foreign-Device-NAT BVLLl. This not only provides a guaranteed B/IP that the FD can be accessed with, it also provides a mechanism whereby the BBMD knows whether or not the FD supports NAT-Unicast.

          I don't support the idea of making a Register-Foreign-Device over TCP (though it would keep the session open) because B/IP is totally based on UDP, and making this exception would involve a whole new set of compilcations.

          In order to add in the concept of a NAT-Unicast BVLL I think the following needs to be done to RL-002:
          1. Define Original-NAT-Unicast-NPDU BVLL in J.2
          2. Define  Register-NAT-Foreign-Device BVLL in J.2
          3. Add to J.3 "BACnet/IP Directed Messages", an explanation of of when to use the NAT-Unicast.
                  a) When Nat enabled
                          - on unicast messages from a BBMD Device/Router  to B/IP addresses that are flagged in the BDT as supporting Unicast-NAT

                          - on unicast messages to FD's registered with Register-NAT
                  b) By FDs when they have been able to successfully register with Register-NAT…
          4. Add to J.5.2 "Foreign Device Table" the explanation of the new Register-NAT-FD BVLL
                  - specify that FD's fall back to the regular Register-FD if a success Result is not returned.
          5. Annex A Conformance option added.

          Have I got something wrong or am  I missing something?

          I don't think the group reach a consensus that these changes are nessesary, but I will add them so we can see what it looks like.

          Roland

          From Stuart:
          So in going through my notes from Germantown , the direction on the NAT was to incorporate a BVLL into the RL-002 proposal because there were situations from a standards compatibility basis with NAT that would not work. However the group wanted to do this without breaking existing solutions.

          Would this look like a per-entry flag to indicate whether messages to that BBMD should use the new BVLL with routing info?

          i) If so, should we worry about not being able to set this with the existing messages to write a BDT?
          ii) Should we leave it up to a future Network Port object to handle configuration?
          iii) Should it be done through a global configuration that says the devices listed in the public BDT optionally use the new BVLL?

          Also, this still leaves the issue of foreign device registration, and how it should work through NAT. I recall some support for a new register foreign device command that would cause the routing to be handled correctly through the router as well.

          Another idea came up here, would it make sense to try and handle NAT foreign device registration through a new Register Foreign Device service over a TCP connection rather than UDP?

          Stuart Donaldson
          Software Engineering Lead
          Honeywell / Alerton
          6670 185th Ave NE
          Redmond, WA 98052
          Office: +1 425 869 8400

           

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