This was discussed in developing error condition tests for B/IP
in the TIWG (RL-004. It was argued that it is a valid use-case to have one-way
distribution of broadcasts, therefore we could not disallow forwarding from
BBMDs not configured in one’s BDT.

We (at
Cimetrics) have been having a discussion about how to prevent broadcast storms,
and how Addendum o changes the problem of preventing broadcast storms.

In BBMDs
implemented to a version of the standard prior to Addendum o, broadcast
storms can occur if two (or more) BBMDs are installed on the same IP subnet and
those BBMDs are using the same UDP port for BACnet. Obviously this
situation was not permitted by the standard, but it does occasionally happen in
the field by accident; our developers have added some defensive code to our
stack to prevent really bad things from happening when this situation occurs.

In Addendum
o, clause J.4.3 has been changed as follows:

BDTs are not required to be identical in all BBMDs
in a single BACnet/IP network

There may be two or more BBMDs on the same IP
subnet, although the BBMDs on the same subnet cannot have any common entries
in their BDTs.

Some of
our developers believe that there is still a potential problem with broadcast
storms if there are two or more BBMDs on the same IP subnet. I pointed
out to them that J.4.5 uses the term “peer BBMD” (not defined in
the standard) when describing how a BBMD processes BVLL Forwarded-NPDU
messages, but they did not accept my restrictive definition of “peer
BBMD”. They argued that a BBMD should process a BVLL Forwarded-NPDU
message received from another BBMD whether or not the receiving BBMD has a BDT
entry for the sending BBMD, because it is now legal for BBMDs to be configured
such that all broadcasts from one IP subnet will be forwarded to another IP
subnet but not in the opposite direction!

How do you
think that “peer BBMD” should be defined? Should a BBMD only
process BVLL Forward-NPDU messages that are received from a “peer
BBMD”?

Thanks,

- Jim
Butler

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************

James F. Butler

Thanks, Roland, for the information. Since the BACnet committee wants to allow BDTs to be configured to support the one-way broadcast scenario, a BBMD is

Message 2 of 8
, Feb 12, 2010

0 Attachment

Thanks, Roland, for the information.
Since the BACnet committee wants to allow BDTs to be configured to support the
one-way broadcast scenario, a BBMD is required to process a BVLL Forwarded-NPDU message received from any BBMD, right?

In light of that, let’s look at the
situation in which two or more BBMDs are connected to the same IP subnet, as
permitted by Addendum o. Let’s assume that all of the BBMDs are
configured for 2-hop forwarding. Addendum o says: “If there are two
or more BBMDs on a single subnet, their BDTs shall not contain any common
entries in order to avoid a broadcast forwarding loop.” We do not believe
that the lack of common entries would prevent a broadcast forwarding loop from
occurring.

- BBMD2a’s BDT contains an entry for
BBMD1 (2-hop forwarding) and for BBMD2a (2-hop forwarding). It does not
contain an entry for BBMD2b.

- BBMD2b’s BDT does not contain an
entry for BBMD1 or for BBMD2a, but it does contain an entry for BBMD2b (2-hop
forwarding).

Let’s also assume that the BBMDs use
their own entry in their BDTs to determine whether a received BVLL
Forwarded-NPDU was received via a unicast or via a broadcast, as suggested by
J.4.5: “A BBMD may ascertain the method by which Forwarded-NPDU messages
will arrive by inspecting the broadcast distribution mask field in its own BDT
entry since masks referring to the same subnet are required to be identical in
all BBMDs.”

This scenario gets much
worse if there are any BACnet/IP devices on subnet #2 that respond to the
Who-Is messages with broadcasts of their own.

We believe that it should
be possible to prevent this from happening by adding a statement such as the
following to J.4.5: “If a BVLL Forwarded-NPDU message was received from a
device located on the same IP subnet, which could occur if two or more BBMDs
are installed on the same subnet, then the receiving BBMD shall merely
retransmit the message directly to each foreign device currently in the BBMD's
FDT.”

This
was discussed in developing error condition tests for B/IP in the TIWG (RL-004.
It was argued that it is a valid use-case to have one-way distribution of
broadcasts, therefore we could not disallow forwarding from BBMDs not
configured in one’s BDT.

We (at Cimetrics) have been having a discussion
about how to prevent broadcast storms, and how Addendum o changes the problem
of preventing broadcast storms.

In BBMDs implemented to a version of the standard
prior to Addendum o, broadcast storms can occur if two (or more) BBMDs
are installed on the same IP subnet and those BBMDs are using the same UDP port
for BACnet. Obviously this situation was not permitted by the standard,
but it does occasionally happen in the field by accident; our developers have
added some defensive code to our stack to prevent really bad things from happening
when this situation occurs.

In Addendum o, clause J.4.3 has been changed as
follows:

BDTs are not
required to be identical in all BBMDs in a single BACnet/IP network

There may be two or
more BBMDs on the same IP subnet, although the BBMDs on the same subnet
cannot have any common entries in their BDTs.

Some of our developers believe that there is
still a potential problem with broadcast storms if there are two or more BBMDs
on the same IP subnet. I pointed out to them that J.4.5 uses the term
“peer BBMD” (not defined in the standard) when describing how a
BBMD processes BVLL Forwarded-NPDU messages, but they did not accept my
restrictive definition of “peer BBMD”. They argued that a
BBMD should process a BVLL Forwarded-NPDU message received from another BBMD
whether or not the receiving BBMD has a BDT entry for the sending BBMD, because
it is now legal for BBMDs to be configured such that all broadcasts from one IP
subnet will be forwarded to another IP subnet but not in the opposite direction!

How do you think that “peer BBMD”
should be defined? Should a BBMD only process BVLL Forward-NPDU messages
that are received from a “peer BBMD”?

Thanks,

- Jim Butler

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************

Carl Neilson

Jim, I believe that the example you give would not occur given the langauge of J.4.5: If the message arrived via directed broadcast, it was also received by

Message 3 of 8
, Feb 12, 2010

0 Attachment

Jim,

I believe that the example you give would not occur given
the langauge of J.4.5:

If the message
arrived via directed broadcast, it was also received by the other devices on the
BBMD's subnet. In this case the BBMD merely retransmits the message directly to
each foreign device currently in the BBMD's FDT. If the message arrived via a
unicast transmission, it has not yet been received by the other devices on the
BBMD's subnet. In this case, the message is sent to the devices on the BBMD's
subnet using the B/IP broadcast address as well as to each foreign device
currently in the BBMD's FDT.

But this would also remove the real benefit of having
multiple BBMDs on a single subnet (to reduce the load a single BBMD would have
in distributing broadcasts).

In my mental model there are 2 disjoint groups of BBMDs,
where each BDT has an entry for each member of its group. For the sake of
discussion the groups are (B1, B2, B3) and (B4, B5, B6) with B3 and B4 residing
on the same IP subnet. The two groups are B3 and B4 over the shared IP
subnet. There are no other IP subnets with multple BBMDs on
them.

In this case, when B1 receives an original-broadcast, it
forwards it to its B2 and B3. And each place the forwarded packet on their
respective subnets. B4 will receive the forwarded packet.

If B4 is not allowed to forward the packet, then the
subnets covered by B5 and B6 will not receive the packet.

I beleive that what we do not want B4 to do, is to
rebroadcast the forwarded packet on the network it received it from.

If I am properly understanding the problem, then I believe
that the solution requires:

- disallow 1-hop mode when using multiple BBMDs on a single
IP subnet

- when in 2-hop mode, forwarded-broadcasts that originate
on the IP of the BBMD shall be sent to each peer BBMD, and each register foreign
device but not distributed to the local network.

Thanks, Roland, for the
information. Since the BACnet committee wants to allow BDTs to be
configured to support the one-way broadcast scenario, a BBMD is required to
process a BVLL Forwarded-NPDU
message received from any BBMD,
right?

In light of that, let’s
look at the situation in which two or more BBMDs are connected to the same IP
subnet, as permitted by Addendum o. Let’s assume that all of the BBMDs are
configured for 2-hop forwarding. Addendum o says: “If there are two or
more BBMDs on a single subnet, their BDTs shall not contain any common entries
in order to avoid a broadcast forwarding loop.” We do not believe that the
lack of common entries would prevent a broadcast forwarding loop from
occurring.

- BBMD2a’s BDT contains
an entry for BBMD1 (2-hop forwarding) and for BBMD2a (2-hop forwarding).
It does not contain an entry for BBMD2b.

- BBMD2b’s BDT does not
contain an entry for BBMD1 or for BBMD2a, but it does contain an entry for
BBMD2b (2-hop forwarding).

Let’s also assume that
the BBMDs use their own entry in their BDTs to determine whether a received BVLL
Forwarded-NPDU was received via a unicast or via a broadcast, as suggested by
J.4.5: “A BBMD may ascertain the method by which Forwarded-NPDU messages will
arrive by inspecting the broadcast distribution mask field in its own BDT entry
since masks referring to the same subnet are required to be identical in all
BBMDs.”

This scenario gets much
worse if there are any BACnet/IP devices on subnet #2 that respond to the Who-Is
messages with broadcasts of their own.

We believe that it
should be possible to prevent this from happening by adding a statement such as
the following to J.4.5: “If a BVLL Forwarded-NPDU message was received from a
device located on the same IP subnet, which could occur if two or more BBMDs are
installed on the same subnet, then the receiving BBMD shall merely retransmit
the message directly to each foreign device currently in the BBMD's
FDT.”

This
was discussed in developing error condition tests for B/IP in the TIWG (RL-004.
It was argued that it is a valid use-case to have one-way distribution of
broadcasts, therefore we could not disallow forwarding from BBMDs not configured
in one’s BDT.

We (at Cimetrics) have
been having a discussion about how to prevent broadcast storms, and how Addendum
o changes the problem of preventing broadcast storms.

In BBMDs implemented to
a version of the standard prior to Addendum o, broadcast storms can occur
if two (or more) BBMDs are installed on the same IP subnet and those BBMDs are
using the same UDP port for BACnet. Obviously this situation was not
permitted by the standard, but it does occasionally happen in the field by
accident; our developers have added some defensive code to our stack to prevent
really bad things from happening when this situation occurs.

In Addendum o, clause
J.4.3 has been changed as follows:

BDTs are
not required to be identical in all BBMDs in a single BACnet/IP
network

There may
be two or more BBMDs on the same IP subnet, although the BBMDs on the same
subnet cannot have any common entries in their BDTs.

Some of our developers
believe that there is still a potential problem with broadcast storms if there
are two or more BBMDs on the same IP subnet. I pointed out to them that
J.4.5 uses the term “peer BBMD” (not defined in the standard) when describing
how a BBMD processes BVLL Forwarded-NPDU messages, but they did not accept my
restrictive definition of “peer BBMD”. They argued that a BBMD should
process a BVLL Forwarded-NPDU message received from another BBMD whether or not
the receiving BBMD has a BDT entry for the sending BBMD, because it is now legal
for BBMDs to be configured such that all broadcasts from one IP subnet will be
forwarded to another IP subnet but not in the opposite
direction!

How do you think that
“peer BBMD” should be defined? Should a BBMD only process BVLL
Forward-NPDU messages that are received from a “peer BBMD”?

Carl, Thanks for your comments. I think that we understand the requirements of J.4.5 that you quoted in your message. However our developers pointed out that

Message 4 of 8
, Feb 12, 2010

0 Attachment

Carl,

Thanks for your comments.

I think that we understand the
requirements of J.4.5 that you quoted in your message. However our
developers pointed out that in practice it may not be possible to
determine whether a received message arrived via broadcast or via unicast
because of the limitations of the commonly used sockets API. In that case
a BBMD should look at its own entry in its BDT for a clue as to how the
Forwarded-NPDU message arrived, as suggested in J.4.5: “A BBMD may
ascertain the method by which Forwarded-NPDU messages will arrive by inspecting
the broadcast distribution mask field in its own BDT entry...” If
that entry says that two-hop forwarding is being used, then the BBMD will
assume that the message arrived via unicast, in which case the BBMD must
broadcast (on its own subnet) any Forwarded-NPDU message that it
receives. That was the premise for the scenario in my message.

In your example, we want to prohibit B4
from rebroadcasting the message on its local subnet as you said. So how
is B4 to know that it should not rebroadcast the message on its local
subnet? Our developers believe that, in the two-hop case, the simplest
method is for B4 to determine whether the Forwarded-NPDU came from another BBMD
on the same subnet; if the Forwarded-NPDU came from B3 then B4 would not
rebroadcast the message on its local subnet, but if the Forwarded-NPDU came
from any other BBMD then B4 would rebroadcast the message on its local subnet.

Let’s look at the one-hop forwarding
case. I think that one-hop can work if both B3 and B4 (in your example)
are configured for one-hop forwarding; in that case if B1 sends a directed
broadcast that is received by both B3 and B4 then neither of them will
rebroadcast it locally. However, if B3 is configured for one-hop
forwarding and B4 is configured for two-hop forwarding then B4 might
erroneously conclude that it must locally rebroadcast the message that it
received from B1.

I believe that the example you give would
not occur given the langauge of J.4.5:

If the message arrived via directed
broadcast, it was also received by the other devices on the BBMD's subnet. In
this case the BBMD merely retransmits the message directly to each foreign device
currently in the BBMD's FDT. If the message arrived via a unicast transmission,
it has not yet been received by the other devices on the BBMD's subnet. In this
case, the message is sent to the devices on the BBMD's subnet using the B/IP
broadcast address as well as to each foreign device currently in the BBMD's
FDT.

But this would also remove the real
benefit of having multiple BBMDs on a single subnet (to reduce the load a
single BBMD would have in distributing broadcasts).

In my mental model there are 2 disjoint
groups of BBMDs, where each BDT has an entry for each member of its group. For
the sake of discussion the groups are (B1, B2, B3) and (B4, B5, B6) with B3 and
B4 residing on the same IP subnet. The two groups are B3 and B4 over the shared
IP subnet. There are no other IP subnets with multple BBMDs on them.

In this case, when B1 receives an
original-broadcast, it forwards it to its B2 and B3. And each place the
forwarded packet on their respective subnets. B4 will receive the forwarded packet.

If B4 is not allowed to forward the
packet, then the subnets covered by B5 and B6 will not receive the packet.

I beleive that what we do not want B4 to
do, is to rebroadcast the forwarded packet on the network it received it from.

If I am properly understanding the
problem, then I believe that the solution requires:

- disallow 1-hop mode when using multiple
BBMDs on a single IP subnet

- when in 2-hop mode, forwarded-broadcasts
that originate on the IP of the BBMD shall be sent to each peer BBMD, and each
register foreign device but not distributed to the local network.

Thanks, Roland, for the information. Since the BACnet
committee wants to allow BDTs to be configured to support the one-way broadcast
scenario, a BBMD is required to process a BVLL Forwarded-NPDU message received from any BBMD, right?

In light of that, let’s look at the situation in which
two or more BBMDs are connected to the same IP subnet, as permitted by Addendum
o. Let’s assume that all of the BBMDs are configured for 2-hop
forwarding. Addendum o says: “If there are two or more BBMDs on a
single subnet, their BDTs shall not contain any common entries in order to
avoid a broadcast forwarding loop.” We do not believe that the lack
of common entries would prevent a broadcast forwarding loop from occurring.

- BBMD2a’s BDT contains an entry for BBMD1 (2-hop forwarding)
and for BBMD2a (2-hop forwarding). It does not contain an entry for
BBMD2b.

- BBMD2b’s BDT does not contain an entry for BBMD1 or for
BBMD2a, but it does contain an entry for BBMD2b (2-hop forwarding).

Let’s also assume that the BBMDs use their own entry
in their BDTs to determine whether a received BVLL Forwarded-NPDU was received
via a unicast or via a broadcast, as suggested by J.4.5: “A BBMD may
ascertain the method by which Forwarded-NPDU messages will arrive by inspecting
the broadcast distribution mask field in its own BDT entry since masks
referring to the same subnet are required to be identical in all BBMDs.”

This scenario gets much worse if there are
any BACnet/IP devices on subnet #2 that respond to the Who-Is messages with
broadcasts of their own.

We believe that it should be possible to
prevent this from happening by adding a statement such as the following to
J.4.5: “If a BVLL Forwarded-NPDU message was received from a device
located on the same IP subnet, which could occur if two or more BBMDs are
installed on the same subnet, then the receiving BBMD shall merely retransmit
the message directly to each foreign device currently in the BBMD's FDT.”

This
was discussed in developing error condition tests for B/IP in the TIWG (RL-004.
It was argued that it is a valid use-case to have one-way distribution of broadcasts,
therefore we could not disallow forwarding from BBMDs not configured in
one’s BDT.

We (at Cimetrics) have been having a
discussion about how to prevent broadcast storms, and how Addendum o changes
the problem of preventing broadcast storms.

In BBMDs implemented to a version of the
standard prior to Addendum o, broadcast storms can occur if two (or
more) BBMDs are installed on the same IP subnet and those BBMDs are using the
same UDP port for BACnet. Obviously this situation was not permitted by
the standard, but it does occasionally happen in the field by accident; our
developers have added some defensive code to our stack to prevent really bad
things from happening when this situation occurs.

In Addendum o, clause J.4.3 has been
changed as follows:

BDTs are not
required to be identical in all BBMDs in a single BACnet/IP network

There may be two or
more BBMDs on the same IP subnet, although the BBMDs on the same subnet
cannot have any common entries in their BDTs.

Some of our developers believe that there
is still a potential problem with broadcast storms if there are two or more
BBMDs on the same IP subnet. I pointed out to them that J.4.5 uses the
term “peer BBMD” (not defined in the standard) when describing how
a BBMD processes BVLL Forwarded-NPDU messages, but they did not accept my
restrictive definition of “peer BBMD”. They argued that a
BBMD should process a BVLL Forwarded-NPDU message received from another BBMD
whether or not the receiving BBMD has a BDT entry for the sending BBMD, because
it is now legal for BBMDs to be configured such that all broadcasts from one IP
subnet will be forwarded to another IP subnet but not in the opposite
direction!

How do you think that “peer
BBMD” should be defined? Should a BBMD only process BVLL
Forward-NPDU messages that are received from a “peer BBMD”?

I agree with your assessment and would support the addition of a sentence to the effect of: If a BVLL Forwarded-NPDU message is received from a device located

Message 5 of 8
, Feb 12, 2010

0 Attachment

I agree with your assessment and would support the addition
of a sentence to the effect of:

“If a BVLL Forwarded-NPDU message
is received from a device located on the same IP subnet, which can occur if two
or more BBMDs are installed on the same IP subnet, then the receiving BBMD shall
shall retransmit it to all other destinations as per the BBMD's FDT and BDT,
except the local IP subnet.”

I think that we
understand the requirements of J.4.5 that you quoted in your message.
However our developers pointed out that in practice it may not be
possible to determine whether a received message arrived via broadcast or via
unicast because of the limitations of the commonly used sockets API. In
that case a BBMD should look at its own entry in its BDT for a clue as to how
the Forwarded-NPDU message arrived, as suggested in J.4.5: “A BBMD may ascertain
the method by which Forwarded-NPDU messages will arrive by inspecting the
broadcast distribution mask field in its own BDT entry...” If that entry
says that two-hop forwarding is being used, then the BBMD will assume that the
message arrived via unicast, in which case the BBMD must broadcast (on its own
subnet) any Forwarded-NPDU message that it receives. That was the premise
for the scenario in my message.

In your example, we
want to prohibit B4 from rebroadcasting the message on its local subnet as you
said. So how is B4 to know that it should not rebroadcast the message on
its local subnet? Our developers believe that, in the two-hop case, the
simplest method is for B4 to determine whether the Forwarded-NPDU came from
another BBMD on the same subnet; if the Forwarded-NPDU came from B3 then B4
would not rebroadcast the message on its local subnet, but if the Forwarded-NPDU
came from any other BBMD then B4 would rebroadcast the message on its local
subnet.

Let’s look at the
one-hop forwarding case. I think that one-hop can work if both B3 and B4
(in your example) are configured for one-hop forwarding; in that case if B1
sends a directed broadcast that is received by both B3 and B4 then neither of
them will rebroadcast it locally. However, if B3 is configured for one-hop
forwarding and B4 is configured for two-hop forwarding then B4 might erroneously
conclude that it must locally rebroadcast the message that it received from
B1.

I believe that the
example you give would not occur given the langauge of
J.4.5:

If the message arrived
via directed broadcast, it was also received by the other devices on the BBMD's
subnet. In this case the BBMD merely retransmits the message directly to each
foreign device currently in the BBMD's FDT. If the message arrived via a unicast
transmission, it has not yet been received by the other devices on the BBMD's
subnet. In this case, the message is sent to the devices on the BBMD's subnet
using the B/IP broadcast address as well as to each foreign device currently in
the BBMD's FDT.

But this would also
remove the real benefit of having multiple BBMDs on a single subnet (to reduce
the load a single BBMD would have in distributing
broadcasts).

In my mental model
there are 2 disjoint groups of BBMDs, where each BDT has an entry for each
member of its group. For the sake of discussion the groups are (B1, B2, B3) and
(B4, B5, B6) with B3 and B4 residing on the same IP subnet. The two groups are
B3 and B4 over the shared IP subnet. There are no other IP subnets with multple
BBMDs on them.

In this case, when B1
receives an original-broadcast, it forwards it to its B2 and B3. And each
place the forwarded packet on their respective subnets. B4 will receive the
forwarded packet.

If B4 is not allowed to
forward the packet, then the subnets covered by B5 and B6 will not receive the
packet.

I beleive that what we
do not want B4 to do, is to rebroadcast the forwarded packet on the network it
received it from.

If I am properly
understanding the problem, then I believe that the solution
requires:

- disallow 1-hop mode
when using multiple BBMDs on a single IP subnet

- when in 2-hop mode,
forwarded-broadcast s that originate on the IP of the BBMD shall be sent to
each peer BBMD, and each register foreign device but not distributed to the
local network.

Thanks, Roland, for the
information. Since the BACnet committee wants to allow BDTs to be
configured to support the one-way broadcast scenario, a BBMD is required to
process a BVLL Forwarded-NPDU
message received from any BBMD,
right?

In light of
that, let’s look at the situation in which two or more BBMDs are connected to
the same IP subnet, as permitted by Addendum o. Let’s assume that all of
the BBMDs are configured for 2-hop forwarding. Addendum o says: “If there
are two or more BBMDs on a single subnet, their BDTs shall not contain any
common entries in order to avoid a broadcast forwarding loop.” We do not
believe that the lack of common entries would prevent a broadcast forwarding
loop from occurring.

- BBMD2a’s BDT contains
an entry for BBMD1 (2-hop forwarding) and for BBMD2a (2-hop forwarding).
It does not contain an entry for BBMD2b.

- BBMD2b’s BDT does not
contain an entry for BBMD1 or for BBMD2a, but it does contain an entry for
BBMD2b (2-hop forwarding).

Let’s also
assume that the BBMDs use their own entry in their BDTs to determine whether a
received BVLL Forwarded-NPDU was received via a unicast or via a broadcast, as
suggested by J.4.5: “A BBMD may ascertain the method by which Forwarded-NPDU
messages will arrive by inspecting the broadcast distribution mask field in its
own BDT entry since masks referring to the same subnet are required to be
identical in all BBMDs.”

This scenario
gets much worse if there are any BACnet/IP devices on subnet #2 that respond to
the Who-Is messages with broadcasts of their
own.

We believe that
it should be possible to prevent this from happening by adding a statement such
as the following to J.4.5: “If a BVLL Forwarded-NPDU message was received from a
device located on the same IP subnet, which could occur if two or more BBMDs are
installed on the same subnet, then the receiving BBMD shall merely retransmit
the message directly to each foreign device currently in the BBMD's
FDT.”

This
was discussed in developing error condition tests for B/IP in the TIWG (RL-004.
It was argued that it is a valid use-case to have one-way distribution of
broadcasts, therefore we could not disallow forwarding from BBMDs not configured
in one’s BDT.

We (at
Cimetrics) have been having a discussion about how to prevent broadcast storms,
and how Addendum o changes the problem of preventing broadcast
storms.

In BBMDs
implemented to a version of the standard prior to Addendum o, broadcast
storms can occur if two (or more) BBMDs are installed on the same IP subnet and
those BBMDs are using the same UDP port for BACnet. Obviously this
situation was not permitted by the standard, but it does occasionally happen in
the field by accident; our developers have added some defensive code to our
stack to prevent really bad things from happening when this situation
occurs.

In Addendum o,
clause J.4.3 has been changed as follows:

BDTs are not required to be
identical in all BBMDs in a single BACnet/IP network

There may
be two or more BBMDs on the same IP subnet, although the BBMDs on the same
subnet cannot have any common entries in their BDTs.

Some of our
developers believe that there is still a potential problem with broadcast storms
if there are two or more BBMDs on the same IP subnet. I pointed out to
them that J.4.5 uses the term “peer BBMD” (not defined in the standard) when
describing how a BBMD processes BVLL Forwarded-NPDU messages, but they did not
accept my restrictive definition of “peer BBMD”. They argued that a BBMD
should process a BVLL Forwarded-NPDU message received from another BBMD whether
or not the receiving BBMD has a BDT entry for the sending BBMD, because it is
now legal for BBMDs to be configured such that all broadcasts from one IP subnet
will be forwarded to another IP subnet but not in the opposite
direction!

How do you think
that “peer BBMD” should be defined? Should a BBMD only process BVLL
Forward-NPDU messages that are received from a “peer
BBMD”?

Jim, However our developers pointed out that in practice it may not be possible to determine whether a received message arrived via broadcast or via unicast

Message 6 of 8
, Feb 12, 2010

0 Attachment

Jim,

"However our developers pointed out that in practice it may
not be possible to determine whether a received message arrived via broadcast
or via unicast because of the limitations of the commonly used sockets API."

Your developers are quite correct. Unfortunately, this is
a common limitation of most socket APIs.

It's much easier, programmatically, to determine where the frame
came from as opposed to who the frame was intended for.

If it's OK with you, I'll take on the task of adding your
proposed language to Annex J. I'll record these emails as part of the
proposal so we don't lose context as we so often do. :-)

I think
that we understand the requirements of J.4.5 that you quoted in your
message. However our developers pointed out that in practice it
may not be possible to determine whether a received message arrived via
broadcast or via unicast because of the limitations of the commonly used
sockets API. In that case a BBMD should look at its own entry in its BDT
for a clue as to how the Forwarded-NPDU message arrived, as suggested in J.4.5:
“A BBMD may ascertain the method by which Forwarded-NPDU messages will
arrive by inspecting the broadcast distribution mask field in its own BDT
entry...” If that entry says that two-hop forwarding is being used,
then the BBMD will assume that the message arrived via unicast, in which case
the BBMD must broadcast (on its own subnet) any Forwarded-NPDU message that it
receives. That was the premise for the scenario in my message.

In your
example, we want to prohibit B4 from rebroadcasting the message on its local
subnet as you said. So how is B4 to know that it should not rebroadcast
the message on its local subnet? Our developers believe that, in the
two-hop case, the simplest method is for B4 to determine whether the
Forwarded-NPDU came from another BBMD on the same subnet; if the Forwarded-NPDU
came from B3 then B4 would not rebroadcast the message on its local subnet, but
if the Forwarded-NPDU came from any other BBMD then B4 would rebroadcast the
message on its local subnet.

Let’s
look at the one-hop forwarding case. I think that one-hop can work if
both B3 and B4 (in your example) are configured for one-hop forwarding; in that
case if B1 sends a directed broadcast that is received by both B3 and B4 then
neither of them will rebroadcast it locally. However, if B3 is configured
for one-hop forwarding and B4 is configured for two-hop forwarding then B4
might erroneously conclude that it must locally rebroadcast the message that it
received from B1.

I believe
that the example you give would not occur given the langauge of J.4.5:

If the message
arrived via directed broadcast, it was also received by the other devices on
the BBMD's subnet. In this case the BBMD merely retransmits the message
directly to each foreign device currently in the BBMD's FDT. If the message
arrived via a unicast transmission, it has not yet been received by the other
devices on the BBMD's subnet. In this case, the message is sent to the devices
on the BBMD's subnet using the B/IP broadcast address as well as to each foreign
device currently in the BBMD's FDT.

But this
would also remove the real benefit of having multiple BBMDs on a single subnet
(to reduce the load a single BBMD would have in distributing broadcasts).

In my
mental model there are 2 disjoint groups of BBMDs, where each BDT has an entry
for each member of its group. For the sake of discussion the groups are (B1,
B2, B3) and (B4, B5, B6) with B3 and B4 residing on the same IP subnet. The two
groups are B3 and B4 over the shared IP subnet. There are no other IP subnets
with multple BBMDs on them.

In this
case, when B1 receives an original-broadcast, it forwards it to its B2 and
B3. And each place the forwarded packet on their respective subnets. B4 will
receive the forwarded packet.

If B4 is
not allowed to forward the packet, then the subnets covered by B5 and B6 will
not receive the packet.

I beleive
that what we do not want B4 to do, is to rebroadcast the forwarded packet on
the network it received it from.

If I am
properly understanding the problem, then I believe that the solution requires:

- disallow
1-hop mode when using multiple BBMDs on a single IP subnet

- when in
2-hop mode, forwarded-broadcasts that originate on the IP of the BBMD shall be
sent to each peer BBMD, and each register foreign device but not distributed to
the local network.

Thanks,
Roland, for the information. Since the BACnet committee wants to allow
BDTs to be configured to support the one-way broadcast scenario, a BBMD is
required to process a BVLL Forwarded-NPDU message
received from any BBMD, right?

In light
of that, let’s look at the situation in which two or more BBMDs are
connected to the same IP subnet, as permitted by Addendum o. Let’s
assume that all of the BBMDs are configured for 2-hop forwarding.
Addendum o says: “If there are two or more BBMDs on a single subnet,
their BDTs shall not contain any common entries in order to avoid a broadcast
forwarding loop.” We do not believe that the lack of common entries
would prevent a broadcast forwarding loop from occurring.

-
BBMD2a’s BDT contains an entry for BBMD1 (2-hop forwarding) and for
BBMD2a (2-hop forwarding). It does not contain an entry for BBMD2b.

-
BBMD2b’s BDT does not contain an entry for BBMD1 or for BBMD2a, but it
does contain an entry for BBMD2b (2-hop forwarding).

Let’s
also assume that the BBMDs use their own entry in their BDTs to determine
whether a received BVLL Forwarded-NPDU was received via a unicast or via a
broadcast, as suggested by J.4.5: “A BBMD may ascertain the method by
which Forwarded-NPDU messages will arrive by inspecting the broadcast
distribution mask field in its own BDT entry since masks referring to the same
subnet are required to be identical in all BBMDs.”

This
scenario gets much worse if there are any BACnet/IP devices on subnet #2 that
respond to the Who-Is messages with broadcasts of their own.

We
believe that it should be possible to prevent this from happening by adding a
statement such as the following to J.4.5: “If a BVLL Forwarded-NPDU
message was received from a device located on the same IP subnet, which could
occur if two or more BBMDs are installed on the same subnet, then the receiving
BBMD shall merely retransmit the message directly to each foreign device
currently in the BBMD's FDT.”

This was discussed in developing error condition tests for B/IP
in the TIWG (RL-004. It was argued that it is a valid use-case to have one-way
distribution of broadcasts, therefore we could not disallow forwarding from
BBMDs not configured in one’s BDT.

We
(at Cimetrics) have been having a discussion about how to prevent broadcast
storms, and how Addendum o changes the problem of preventing broadcast storms.

In
BBMDs implemented to a version of the standard prior to Addendum o,
broadcast storms can occur if two (or more) BBMDs are installed on the same IP
subnet and those BBMDs are using the same UDP port for BACnet. Obviously
this situation was not permitted by the standard, but it does occasionally
happen in the field by accident; our developers have added some defensive code
to our stack to prevent really bad things from happening when this situation
occurs.

In
Addendum o, clause J.4.3 has been changed as follows:

BDTs are not required to be identical in
all BBMDs in a single BACnet/IP network

There may be two or more BBMDs on the
same IP subnet, although the BBMDs on the same subnet cannot have any
common entries in their BDTs.

Some
of our developers believe that there is still a potential problem with
broadcast storms if there are two or more BBMDs on the same IP subnet. I
pointed out to them that J.4.5 uses the term “peer BBMD” (not
defined in the standard) when describing how a BBMD processes BVLL
Forwarded-NPDU messages, but they did not accept my restrictive definition of
“peer BBMD”. They argued that a BBMD should process a BVLL
Forwarded-NPDU message received from another BBMD whether or not the receiving
BBMD has a BDT entry for the sending BBMD, because it is now legal for BBMDs to
be configured such that all broadcasts from one IP subnet will be forwarded to
another IP subnet but not in the opposite direction!

How
do you think that “peer BBMD” should be defined? Should a
BBMD only process BVLL Forward-NPDU messages that are received from a
“peer BBMD”?

Thanks,

-
Jim Butler

************************************************************************************
This footnote confirms that this email message has been scanned by
PineApp Mail-SeCure for the presence of malicious code, vandals & computer
viruses.
************************************************************************************

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