Hello,

These are the minutes from the meeting. Please review for accuracy. They have also been uploaded to files.

Thanks,

<<Minutes IP-WG Chicago 2009.doc>>

Roland Laird

Reliable Controls Corporation   www.reliablecontrols.com

120 Hallowell Road              T. Free:        (877) 475-9301

Victoria, British Columbia      Tel:    (250) 475-2036

Canada V9A 7K2          Fax:    (250) 475-2096

Hi,

The IP-WG will be meeting at the ASHRAE summer meeting in Louisville. We will be
looking at B/IP error conditions and NAT tests. If you are interested in
writting  proposals for either of these two subjects please reply to the group.

Some negitive conditions that have been identified:

1. Process Distribute-Broadcast-To-Network from a device, which is not
registered as FD. What to do?
-- proceed as usual
-- send NAK
-- drop
Probably, sending NAK is the best.

2. Process Forwarded-NPDU from a device which is not listed in BBMD's BDT. What
to do?
-- proceed as usual
-- drop
Probably drop is the safest choice, otherwise two misconfigured BBMDs
can flood the network.

3. Process Forwarded-NPDU from a peer BBMD, but received as directed broadcast,
while local network is configured as two-hop only, or received as unicast, when
local network is configured for One-Hop forwarding. What to do?
-- proceed as usual
-- drop
Again, it is better to drop such packets.

Thanks,
Roland Laird

PS. We will also be looking at an updated IPv6 proposal with diagrams.

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-ip-wg
group.

   File        : /LJT-004-1 BBMD Requirements.doc
   Uploaded by : rolandlus <rlaird@...>
   Description : BBMD Requirements

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-ip-wg/files/LJT-004-1%20BBMD%20Requirements\
.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

rolandlus <rlaird@...>

Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-ip-wg
group.

   File        : /RL-006-1 BIP Error Conditions.doc
   Uploaded by : rolandlus <rlaird@...>
   Description : B/IP Error conditions and tests

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-ip-wg/files/RL-006-1%20BIP%20Error%20Condit\
ions.doc

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles

Regards,

rolandlus <rlaird@...>

> What is the justification for requiring a BBMD to support a FDT? It
> seems reasonable to not want to support a FDT.

It's not so hard to have a FDT that's not very big, say, zero entries
long, then reject registration requests.  Or it you're interested in not
announcing that you are a BBMD (making you somewhat more susceptible to
other attacks) or you have that capability, just don't bother sending a
NACK back.


Joel

It improves the probability that adding a new IP device to an existing network
where a BBMD exists, without the need to add more BBMDs. In general, adding a
single device

If the new device is added on a subnet that has a BBMD, it can be added and all
is well.

If it is a lone IP device on its subnet, then it can be setup to register
foreign to an existing BBMD.

Of course, there will always be the chance that all existing BBMDs' FDTs are
full.

Carl Neilson

________________________________

From: bacnet-ip-wg@yahoogroups.com on behalf of Buddy Lott
Sent: Wed 6/17/2009 1:30 PM
To: bacnet-ip-wg@yahoogroups.com
Subject: RE: [bacnet-ip-wg] New file uploaded to bacnet-ip-wg





What is the justification for requiring a BBMD to support a FDT? It seems
reasonable to not wamt to support a FDT.







*******************************************************************

Buddy Lott
Firmware Design Engineer
19476 Industrial Dr.
New Paris, IN 46553
574.831.5250 x 8197
blott@... <mailto:blott@...>



*******************************************************************

________________________________

From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
Sent: Tuesday, June 16, 2009 4:42 PM
To: bacnet-ip-wg@yahoogroups.com
Subject: [bacnet-ip-wg] New file uploaded to bacnet-ip-wg









Hello,

This email message is a notification to let you know that
a file has been uploaded to the Files area of the bacnet-ip-wg
group.

File : /LJT-004-1 BBMD Requirements.doc
Uploaded by : rolandlus <rlaird@...
<mailto:rlaird%40reliablecontrols.com> >
Description : BBMD Requirements

You can access this file at the URL:
http://groups.yahoo.com/group/bacnet-ip-wg/files/LJT-004-1%20BBMD%20Requirements\
.doc
<http://groups.yahoo.com/group/bacnet-ip-wg/files/LJT-004-1%20BBMD%20Requirement\
s.doc>

To learn more about file sharing for your group, please visit:
http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles
<http://help.yahoo.com/l/us/yahoo/groups/original/members/web/index.htmlfiles>

Regards,

rolandlus <rlaird@... <mailto:rlaird%40reliablecontrols.com> >

The BACnet IT-WG is a new working group within the BACnet committee (ASHRAE SSPC 135).  The working group will be officially launched within the next couple of weeks.  Here is the initial charter of the working group:

Since the design of BACnet began in 1987, much has changed in the world of computers, networking technology, and building automation systems.  BACnet has been sufficiently flexible to handle many of these changes, but more changes are coming that may further challenge BACnet’s architecture.  Here are some of the changes that could affect the requirements for building automation systems:

1.         The trend toward convergence of IT and building automation

2.         Network security policies and standards

3.         The increasing use of battery-powered and wireless networked devices

4.         “Smart Grid” applications that involve building automation systems

The BACnet IT working group’s primary task will be to enumerate the general communication requirements of building automation systems that will be deployed over the next several years and evaluate BACnet against those requirements.  To the extent that BACnet does not meet those requirements, the working group will discuss, at a high level, how BACnet could be modified or redesigned in order to better meet those requirements.  Based on the outcome of those discussions, the working group members might initiate projects to investigate various design options.

I have set up a Yahoo Group that we will use for e-mail exchange.  If you are interested in participating in the BACnet IT working group, you should join that Yahoo Group:  http://tech.groups.yahoo.com/group/bacnet-it-wg/

It is my intention that the working group will use collaboration tools that have not been used by other BACnet committee working groups.  I believe that those tools can help us to do a better job of documenting issues (and related documents) that we discuss.  An announcement about this will be made in the near future.

The working group’s first face-to-face meeting will be held on Tuesday November 10, 2009 from 1:00 to 3:00 p.m. at Georgia Tech.

Regards,

- Jim Butler

 

Please find attached the agenda and two proposals that are ready for review at our Nov 6^th meeting in Atlanta. Coleman informed me he will not be able to attend so we will not be reviewing IPv6.  Any new business is welcome.

 

Roland

 

 

No virus found in this incoming message.
Checked by AVG - www.avg.com Version: 8.5.423 / Virus Database: 270.14.36/2465 - Release Date: 10/28/09 09:34:00

This is a list of the main IPv6 RFC documents that describe the core components
of IPv6. It was requested that the IP-WG familiarize themselves with IPv6 so
that we are equipped to review the next proposal. Coleman Brumbley will be
providing an update to the current RL-003-10. RL-003-10 is in the Files section
of this Yahoo Group.

http://www.ietf.org/rfc.html

RFC  2460:  Internet Protocol, Version 6 (IPv6)
RFC  4294 : IPv6 Node Requirements
RFC 4291: IP Version 6 Addressing Architecture
RFC 4193: Unique Local IPv6 Unicast Addresses
RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses
RFC 3307: Allocation Guidelines for IPv6 Multicast Addresses

We will be allocated at least two hours in Orlando critically review the
BACnet/IPv6 proposal. As the Smart Grid is looking to IPv6, it is important that
we move this proposal out to public review ASAP. Please take time before Orlando
to study the RFCs and RL-003-10.

Thanks Roland

Introduction of routing support for IPv6 as described in RL-003-10, specifies
using Virtual MAC Addressing (Annex H.X)

It then goes on to specify functions in concept identical to the BACnet/IP
network type (Annex J) with respect to the inclusion of the BACnet Virtual Link
Layer (BVLL) described in Annex J.2. BACnet broadcasts are replaced by the
appropriate scope IPv6 multicasts.

When Annex H and Virtual MAC Addressing for Zigbee was being introduced, I
foresaw this being the advent of BACnet data-link layers which did not use
broadcast for device address binding, relegating that device address binding
step to the routers by maintaining a map from BACnet Device ID to address in the
local network data-link layer technology, as Zigbee does in Annex H.

IPv6 could go that route as well. I am not thoroughly versed in the pros and
cons of broadcast, nor in how well the combination of BBMDs, FDTs, ARP, and
Annex J have served the BACnet community. Those on the outside looking in,
however, who are familiar with the IT world but who have also participated in
and commented in BACnet-L, seem to see that the better road forward would be for
BACnet to be more like the myriad technologies that work without broadcast.

I wanted to at least put it into consideration, at this point in time when our
support for IPv6 is nascent, as this is an opportunity for elimination of
broadcast in another BACnet specified data-link layer technology. And even if we
do not choose complete elimination of broadcast, we can alternately at least not
use broadcast in our primary mechanism for device address binding. Does the
Zigbee address binding approach in Annex H work well? Can that approach be just
as well implemented in the IPv6 specification?
     - Duffy O'Craven

Duffy et al,

"I am not thoroughly versed in the pros and cons of broadcast..."

Speaking from Alerton's perspective and experience with some very large
systems, it would be A Very Good Thing if we could eliminate broadcasts,
particularly global broadcasts.

Bill Swan
                                               Honeywell
Buildings Standards Initiatives Leader - LEED AP
Alerton & Honeywell
6670 - 185th Ave NE, Redmond, WA 98052, USA
+1 (425) 897-3981
   http://BACnetBill.blogspot.com

-----Original Message-----
From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
On Behalf Of Duffy OCraven
Sent: Tuesday, December 01, 2009 1:42 PM
To: bacnet-ip-wg@yahoogroups.com
Subject: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination
of broadcast

Introduction of routing support for IPv6 as described in RL-003-10,
specifies using Virtual MAC Addressing (Annex H.X)

It then goes on to specify functions in concept identical to the
BACnet/IP network type (Annex J) with respect to the inclusion of the
BACnet Virtual Link Layer (BVLL) described in Annex J.2. BACnet
broadcasts are replaced by the appropriate scope IPv6 multicasts.

When Annex H and Virtual MAC Addressing for Zigbee was being introduced,
I foresaw this being the advent of BACnet data-link layers which did not
use broadcast for device address binding, relegating that device address
binding step to the routers by maintaining a map from BACnet Device ID
to address in the local network data-link layer technology, as Zigbee
does in Annex H.

IPv6 could go that route as well. I am not thoroughly versed in the pros
and cons of broadcast, nor in how well the combination of BBMDs, FDTs,
ARP, and Annex J have served the BACnet community. Those on the outside
looking in, however, who are familiar with the IT world but who have
also participated in and commented in BACnet-L, seem to see that the
better road forward would be for BACnet to be more like the myriad
technologies that work without broadcast.

I wanted to at least put it into consideration, at this point in time
when our support for IPv6 is nascent, as this is an opportunity for
elimination of broadcast in another BACnet specified data-link layer
technology. And even if we do not choose complete elimination of
broadcast, we can alternately at least not use broadcast in our primary
mechanism for device address binding. Does the Zigbee address binding
approach in Annex H work well? Can that approach be just as well
implemented in the IPv6 specification?
     - Duffy O'Craven


------------------------------------

Yahoo! Groups Links

Buddy wrote:

> 1)       Looking for objects by name, (i.e. doing a who-has for
“Outside-Air-Temperature”)
>
> 2)       Looking for devices by name, (i.e. doing a who-has for “Buddy’s
brilliant device”)
>
> 3)       Looking for a device by id doing a who-is for the device both when
you now the remote network and when you don’t.

A good federated directory service could be stacked on top of our current
services, similar to  the way I-Am and I-Have can be cached.

> 4)       A unsolicited broadcast event-notification (i.e. setting up a
notification class and event-enrollment object to tell everyone something
happened so maybe someone can handle it).

I've been mucking around with the pubsubhubbub project
<http://code.google.com/p/pubsubhubbub/> as a way to collect event notifications
and re-distribute them to interested subscribers.  It's a bit odd turning events
into an atom feed, but perhaps there are some architectural bits that can be an
inspiration.

The most important pieces to me are (1) elimination of broadcast services, (2)
using a simple confirmed service to notify the hub of new event(s), (3) the hub
gathers the events according to its load, (4) publishers and subscribers are
de-coupled but can still be centrally monitored, (5) hubs can be scaled
vertically (multiple hubs in an organization) and horizontally (boosting the
performance of a hub by upgrading the hardware, or using a "cloud" like App
Engine), and last but not least, (6) I have to write very little code :-).


Joel

Joel,

While I think I understand what you are saying and appreciate the effort, I also
think that you need to be careful about creating a single point of failure.

The issue also becomes circular. Let's assume for a second that we have a
service X that eliminates the need for broadcast of type Y. How does service X
gather information to implement that service? If the service is eliminating the
need for broadcast Who-Is messages, how does IT discover all of the devices?

Personally, I don't find broadcast to be as much of a problem as the way that
people use them. For instance, sending a who-has request to every one seems
pretty reasonable unless you are sending a who-has that everyone (or most) WILL
respond too or you are sending it too often. The responses cause as many or more
problems then the request. How many times have you seen a global broadcast
"Who-Is" go out with an unlimited range? How many times have you seen the 'I-AM'
response go out as a global broadcast?

I think an important thing to clarify is whether you are talking about
eliminating IP layer broadcast or BACnet App Layer broadcast.

To me, some important goals of any BACnet-IP revision should be:

1) Be NAT & PAT neutral. In other words, avoid using anything that may not be
valid when crossing intranet and internet boundaries.
2) Use host names (or URLs) for addressing instead of IP addresses. This allows
for NAT & PAT neutral names and allowing for dynamic addressing support.
3) Support dynamic addressing (DHCP).
4) Support IP multicasting (this helps eliminate tradition broadcasting) &
legacy BBMD.
5) Minimize the need for IP level broadcasting and retransmitting while
supporting BACnet App layer broadcast.
6) Be respectful of the dynamic nature of IP versus Ethernet & MS/TP networks.
Most intranets are using DHCP and are reconfigured as networks grow. Most
intranet/internet boundaries use NAT/PAT. These can be easily (for the most
part) reconfigured by IT people as network requirements change. Limiting the
problems caused in BACnet when this happens should be a top priority.



*******************************************************************

Buddy Lott
Firmware Design Engineer
19476 Industrial Dr.
New Paris, IN 46553
574.831.5250 x 8197
blott@...

*******************************************************************

-----Original Message-----
From: Joel Bender [mailto:jjb5@...]
Sent: Wednesday, December 02, 2009 10:18 AM
To: bacnet-ip-wg@yahoogroups.com
Subject: Re: [bacnet-ip-wg] RE: IPv6 presents an opportunity for elimination of
broadcast

Buddy wrote:

> 1)       Looking for objects by name, (i.e. doing a who-has for
"Outside-Air-Temperature")
>
> 2)       Looking for devices by name, (i.e. doing a who-has for "Buddy's
brilliant device")
>
> 3)       Looking for a device by id doing a who-is for the device both when
you now the remote network and when you don't.

A good federated directory service could be stacked on top of our current
services, similar to  the way I-Am and I-Have can be cached.

> 4)       A unsolicited broadcast event-notification (i.e. setting up a
notification class and event-enrollment object to tell everyone something
happened so maybe someone can handle it).

I've been mucking around with the pubsubhubbub project
<http://code.google.com/p/pubsubhubbub/> as a way to collect event notifications
and re-distribute them to interested subscribers.  It's a bit odd turning events
into an atom feed, but perhaps there are some architectural bits that can be an
inspiration.

The most important pieces to me are (1) elimination of broadcast services, (2)
using a simple confirmed service to notify the hub of new event(s), (3) the hub
gathers the events according to its load, (4) publishers and subscribers are
de-coupled but can still be centrally monitored, (5) hubs can be scaled
vertically (multiple hubs in an organization) and horizontally (boosting the
performance of a hub by upgrading the hardware, or using a "cloud" like App
Engine), and last but not least, (6) I have to write very little code :-).


Joel



------------------------------------

Yahoo! Groups Links

Hi Roland,

Will we be discussing an IPv6 proposal in Orlando?  If so, I would like
to see it at least a few days prior to the meeting.

Thanks,

- Jim Butler


-----Original Message-----
From: bacnet-ip-wg@yahoogroups.com [mailto:bacnet-ip-wg@yahoogroups.com]
On Behalf Of rolandlus
Sent: Wednesday, November 25, 2009 12:19 PM
To: bacnet-ip-wg@yahoogroups.com
Subject: [bacnet-ip-wg] Internet Protocol Version 6 familiarization

This is a list of the main IPv6 RFC documents that describe the core
components of IPv6. It was requested that the IP-WG familiarize
themselves with IPv6 so that we are equipped to review the next
proposal. Coleman Brumbley will be providing an update to the current
RL-003-10. RL-003-10 is in the Files section of this Yahoo Group.

http://www.ietf.org/rfc.html

RFC  2460:  Internet Protocol, Version 6 (IPv6)
RFC  4294 : IPv6 Node Requirements
RFC 4291: IP Version 6 Addressing Architecture
RFC 4193: Unique Local IPv6 Unicast Addresses
RFC 3306: Unicast-Prefix-based IPv6 Multicast Addresses
RFC 3307: Allocation Guidelines for IPv6 Multicast Addresses

We will be allocated at least two hours in Orlando critically review the
BACnet/IPv6 proposal. As the Smart Grid is looking to IPv6, it is
important that we move this proposal out to public review ASAP. Please
take time before Orlando to study the RFCs and RL-003-10.

Thanks Roland