155Denver MS/TP working group meeting
- Jul 15, 2013Hello MS/TP Working Group!
Below are the meeting minutes from the Denver meeting, which are recorded as MSTP025-2.doc in BACnet FTP archives.
BACnet - MS/TP Working Group
Friday, June 21, 2013, 8am-10am
Sheraton Denver Center, Century, Tower Building, Mezzanine Level
Jim Butler Cimetrics
Klaus Waechter Siemens
Steve Karg Watt Stopper
Thomas Kurowski Siemens
Duffy O'Craven Quinda
The meeting was called to order at 8am, with Steve Karg convening.
Introductions were made. The agenda was reviewed and approved. There were no previous meeting minutes available to review.
1. Add-135-2012an, the MS/TP Extended Frames proposal, completed plenary review at the previous SSPC meeting in San Francisco, is slated for publication public review, and awaiting a vote by SPLS.
2. STK-030-7, ZeroConfig for MS/TP, had plenary review at the previous SSPC meeting in San Francisco, failed a publication public review vote, and is slated for another plenary review after editorial cleanup (referencing 135-2012 and other editorial changes).
3. STK-037-1, MS/TP FindNewSuccessorUnknown, completed review at the previous working group meeting and was forwarded to SSPC for plenary review.
4. Jim Butler worked with a team developing new firmware for an MS/TP and BACnet/IP router. The team had some questions about expected responses for two situations in BACnet where the standard isn't clear about what to do.
o A device is not aware of a router to a specific network, and sends a packet with a MAC broadcast which includes a DNET. The router on the local network hears the packet, and does not have the DNET in its routing tables. The router issues a Who-Is-Router-To-Network to find the router for the DNET, but after a period of time, does not receive a response from any downstream routers. Should the router be silent, or issue a Reject-Message-To-Network message with rejection reason 1: "The router is not directly connected to DNET and cannot find a router to DNET on any directly connected network using Who-Is-Router-To-Network messages".
o A resource constrained non-routing device wants to initiate peer to peer communication, and has a routing table size of one. The device remembers the last router it used, and on subsequent requests, uses the MAC of the router and the DNET possibly served by another router. If the router receiving the message is not directly routing to the DNET, should it reject the message, drop the message, or unicast the message to the correct router (either by looking up the DNET in the routing table, or discovering the DNET via Who-Is-Router-To-Network)?
5. DO-038-1, DER_alignments_with_Frame_Type, was discussed by the group. Duffy explained that the document also contained some ideas on elements in the MS/TP BACnet standard that are not clear. After discussion of the document, the group felt that 9.3.6 and 9.3.7 changes should be the only items in the proposal, and the other unclear elements should be moved to another proposal. Duffy will revise for next meeting. Some of the discussion of the unclear elements were:
o The case for unicast TS to TS is used in ZeroConfig MS/TP.
o The case for Broadcast Test-Request frames is during factory test and configuration where a single device is connected to the TD.
o If ReceipientIsSelf, should the device route, drop, or send? Current standard language is Send.
6. Network Port object discovery was discussed, and Duffy asked about using 4194303. Steve explained that the workstations he helped design used the oldest common methods to find an application layer Device object in a product by using a unicast Who-Is to the router address discovered by the Who-Is-Router message. When trying to use a ReadProperty to 4194303 with a router, the routers that were tested didn't support that feature. WhoHas may also work in discovering the application layer Device object.
7. The MS/TP working group needs a new convener, as David Fisher has asked to have someone take over the position. Steve will mention it during the SSPC report for the MS/TP working group.
8. MS/TP working group work to be done:
o Responses to comments of PPR.
o Back log of proposals
o Ongoing maintenance
9. Klaus described the work that Siemens in Europe has done in moving to MS/TP, creating a router that includes MS/TP, and testing.
10. Duffy mentioned at the BTL-WG meeting that 115k bps for MS/TP does not work well between vendors, although it seems to work fine for single vendor products. Duffy will research to find the problems with the implementations, and a proposal will be crafted to fix or constrict any necessary parameters for 115k bps.
11. The next MS/TP working group meeting will be at BACnet Fall meeting, scheduled for November 4-8, 2013. The MS/TP working group will likely need at least half a day for comment responses.
The meeting adjourned 10 am Mountain Time.