- IP-WG,We will have a face to face meeting as part of the summer ASHRAE conference.Unfortunately, I will not be able to attend this meeting. Bernhard Isler has graciously volunteered to convene this meeting. I will send the updated Add. AI and Add. AJ documents to the Yahoo group over the weekend so that they can (hopefully) be reviewed prior to the meeting. The agenda and San Francisco meeting minutes will be available on the FTP server prior to the meeting.
Location: Sheraton Denver Downtown
1550 Court Place Denver CO 80202
Room: Century Room, Tower Building, Mezzanine Level
Time: 21-Jun-2013 1:00 PM - 3:00 PM
Our next face to face meeting will on Friday, 17-Jan-2014 from 1:00PM EST to 4:00OPM EST at the New York Hilton Midtown in NYC, NY. The meeting is in Concourse B on the Concourse Level on the Hilton.
The agenda is to discuss DO-042-1.doc and to discuss tests for the Network Port Object and B/IPv6.
Safe travels, and see you in New York!
Our next meeting will be in Chicago, IL at the Palmer House Hilton Hotel in the Grant Park room on Sunday January 25, 2015 from 10:00 AM until Noon Central Standard Time. The Grant Park room is located on the 6th floor of the Palmer House Hilton.
An agenda will be distributed prior to the meeting. I do not expect that we will be able to provide remote access to the meeting.
- IP-WG,Our next face to face meeting will be Friday, January 22, 2016 at Orange County Convention Center in Orlando, FL.Time: 3:00 PM Eastern Standard TimeLocation: OCCC South Concourse, Room S330HWe will be discussing B/IPv6 and Network Port Object test concepts as well as any proposals that have updates that are ready for review during the meeting (MSO-009, JB-035, CLB-027).Hope to see you in Florida!Regards,Coleman
- IP-WG,Our next face to face meeting will be Wednesday, April 20, 2016 at the Lutron Experience Center in Ft. Lauderdale, FL.Time: 1:00 PM Eastern Daylight TimeLocation: Lutron Experience Center, FoyerWe will be discussing CLB-029 (B/IPv6 tests) and CLB-028 (Network Port Object tests).Hope to see you in Florida!Regards,Coleman
Our next face to face meeting will be Friday, June 23, 2016 at the Marriott St. Louis Grand Hotel in St. Louis, MO.
Time: 10:00 AM Central Daylight Time
Location: Parkview Room, Marriot St. Louis Grand Hotel, 800 Washington Ave, St. Louis, MO
We will be discussing CLB-029 (B/IPv6 tests) and CLB-028 (Network Port Object tests) as well new proposals.
Hope to see you in St. Louis!
Dear BACnet IP-WG members,
I received the following questions about the Network Port Object from our BACnet stack team, and I hope that we can discuss them during our meeting in Las Vegas. If this is the wrong forum for this topic, please direct me to the correct forum.
- Jim Butler
While implementing Network Port Object (Add-135-2012-ai) we faced the following problem: it is not at all clear, what the contents of the Routing Table property of the Object should be.
Some background first.
Routing table is defined in the Standard, clause 6.6.1 "Routing Tables" as
> "a list of network numbers reachable through the port along with the MAC
> address of the next router on the path to each network number and the
> reachability status of each such network."
> "The "reachability status" is an implementation-dependent value [...
> which] shall be able to distinguish, between "permanent" [...] and
> "temporary" unreachability due [...] congestion control.
A few things to note here:
A) As defined later in the Standard, the routing table is filled with data received in I-Am-Router-To-Network messages.
B) It is implied, but not explicitly stated, that there can exist no more than one entry for a any given network number. This is because BACnet does not support multi-path routing.
C) PTP half-routers discovered by I-Could-Be-Router-To-Network do not belong to the routing table.
D) As you may remember, we were not able to find any references to "permanent" route failures in the rest of the Standard text. No procedures for this case are defined, so it was considered it best to delete completely the "permanently unreachable" state from our routing table, because we did not come up with any sensible algorithm for treating such networks.
E) PTP half-routers is an interesting topic. There are good reasons for not including them in the routing table:
First, those half-routers can NOT be used to send packets through them. A half-router can route packets only after it establishes a PTP connection to the remote network. After the connection is established, it poses itself as a "normal" router (that is: broadcasts "I-Am-Router" message).
Second: there can be more than one half-router for any given network number. Some implementations ... may keep a list of all known PTP half-routers to a given network, and iterate over the list when trying to establish a connection. Other implementations ... may store only the "best" (performance-index wise) half-router for any network.
Third: a PTP half-router is identified by a full BACnet address (as opposed to a next-hop router, which is identified by a MAC address on the local network) and also have a "performance-index" value associated with it. This data is not listed as part of the routing table in 6.6.1.
Note, that the Standard defines no way for a half-router to inform other BACnet devices that it has established a connection. The half-router simply issues I-Am-Router-To-Network, and acts as a "normal" router, as long as the connection lasts. So, there is no way for a BACnet device to know which PTP half-router established the connection. There is even no way to know, whether the connection to a remote network is a PTP one, or, maybe, it is a "normal" permanent connection (B/IP over Internet), and PTP half-routers are configured as a back-up in case the Internet connection goes down.
It follows from the above: when connection to a remote network is set up, it is not possible to "convert" a PTP router to a "normal" router, because the device never knows which specific PTP router established the connection. The list of PTP half-routers is maintained completely independently of routing table and is updated only when I-Could-Be-Router-To-Network message is received, or when an attempt to establish a connection fails (in the latter case the router is considered "dead" and the entry is removed).
In summary: the routing table (that is: the list of active next-hop routers) is very different from the list of known PTP half-routers. These lists are maintained independently, and in general it is not possible to correlate the entries in these two lists.
Now to the Routing Table property of Network Port Object (NPO) as defined in Add-135-2012ai. (Actually, there is a new addendum Add-135-2012bf, which re-defines some NPO aspects, but it does not change anything regarding the Routing Table.)
The contents of the "Routing Table" property is a list of Router-Entries. Each Router-Entry contains the following data items:
> network-numberAs the presence of "performance-index" implies, this list should contain not only next-hop routers, but also the PTP half-routers. However, the data structure does not match the data associated with a PTP half-router. It is even impossible to uniquely identify a PTP half-router, because the full BACnet address (with a network number) is required for that.
> status (enum: available, busy, disconnected)
> performance-index (OPTIONAL)
Another issue with this property: the "status" field can not be easily mapped to the "reachability status" defined in Clause 6.6.1, AND it is meaningful for a PTP half-router.
The description of "status" in the Addendum: "Conveys whether the associated network is able to receive traffic." (BTW, the wording implies no more than one entry per network number.) It is not clear, how exactly this value should be determined based on the data stored in the Routing Table.
So, below are the technical questions regarding contents of the Routing Table property, for which we could not find an answer in the official Standard and Addendum:
1) Do the "Routing Table" property include entries for PTP half-routers along with the entries of "routing table" as defined in (6.6.1) ?
We suppose that the answer is "yes", otherwise "performance-index" would make no sense.
2) May there be more than one entry for any given network number?
The answer is probably yes, because there always can be more than one PTP half-router for any given network, and there can be an active route (via PTP, or otherwise) to the same network at the same time. Note, however, that a "true" BACnet routing table contains no more that one item per a network number.
3) What is the meaning of the "status" value ?
Here is our analysis:
"available" probably maps to "normal" or "reachable" state as defined in Clause 6.6.1.
"busy" probably maps to "temporary unreachable" state as defined in Clause 6.6.1, which is also know as "BUSY" and indicated by the "router busy" network message.
However, "disconnected" status seems to have no obvious mapping. Clause 6.6.1 defines "permanently unreachable" state, which is not exactly "disconnected".
As the word "disconnected" implies, it may be designed for PTP routers. However, it can not be associated with a PTP half-router, because there is no standard way to know whether a given half-router is disconnected or connected at any given time.
4) What status value should be associated with a PTP half-router? BACnet provides no way to "track" the status of a half-router, so this value will never change, and actually makes no sense. But this value is mandatory, so we have to select a value.
5) Is it OK to populate the list with many completely identical records (full duplicates)?
Duplicates would happen inevitably, if all PTP half-router entries are added to the list. As mentioned earlier, it is impossible to identify a PTP half-router with a local MAC address. Two or more PTP half-routers to the same target network, which reside on a remote network (or different networks, accessible through the same next-hop router) will produce identical entries (strictly speaking, only if they advertise the same performance-index, but this is immaterial here).
There is no good solution for this problem, except for changing the property format by adding an optional "BACnet Address" field to store the full address of the remote PTP half-router.
Possible partial solutions using the existing format are:
5.1) Populate the list with duplicates: one record per PTP router. The list will be somewhat meaningless, but would conform to the "word" of the Standard.
5.2) Do not list any PTP half-routers in the "Routing table" property. This seems to be the most sensible solution, but it apparently contradicts the "spirit" of the Addendum, because it makes the performance-index senseless.
5.3) An alternative: only list the PTP half-routers which reside on the local network. These routers can be uniquely identified by a MAC address, so there will be no duplicates. However, a PTP router residing on remote networks will not be listed.
Can you, please, clarify the issue and help us with these five questions?
Perhaps the "right solution" for these questions is to change the format of the Routing Table property of NPO. Here are two options: EITHER remove the "performance-index" and making the value reflect the "true" routing table (as defined in 6.6.1), no PTP half-routers; OR add an optional "BACnet Address" field for PTP half-routers and making "status" optional omitting it from PTP-related entries. In any case, the status value "DISCONNECTED" should be renamed to "PERMANENTLY_UNREACHABLE", or something like that.
We certainly can add it to the IP-WG agenda (unless you or Dan feels strongly otherwise). I only asked for an hour, though, because the only item on the table currently is the B/IPv6 tests which I’m hoping we move to the SSPC for further discussion within the bigger group.
The history of that property was that it originally completely ignored PTP half-routers and the addition of the performance-index was made as attempt to accommodate them. The idea all along, though, is what is stated in point 5.3 below. That the routing table would only contain the first hop to a network number, not remote networks. So routers residing on remote networks would not be listed in the routing-table property.
In fact, 12.56.58 says this “…contains the table of first hop routers”, which supports the 5.3 solution.
Does that solve the issue they’re having?
- Dear Coleman,
Thank you very much for clarification.
Formally "option 5.3" solves the problem with PTP half-routers. However,
the contents of the property would be somewhat unnatural, because all
PTP half-routers are "created equal", and from routing standpoint there
is no difference between a half-router connected to the adjacent network
and a router connected to a remote network. A distant half-router could
have a better "performance-index", so that a "local" half-router would
never be used. Having said that, including only "adjacent" half-routers
is OK from the implementer's standpoint.
However, there are still questions regarding the "status" field:
1) It is not possible to determine "status" value for a PTP half-router,
so this field is meaningless if "performance-index" is present. It is
not clear, what value should be used. Probably it is better to make the
"status" field optional (and exclude it if performance-index is present).
2) It is not clear when status value "disconnected" should be used. Does
it mean "permanently unreachable", or does it only apply to PTP
half-routers? In the latter case it will be just a constant placeholder,
because there is no way to tell whether a PTP link is up or down.