E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDMnet (BSR E1.33) Draft Standard General Discussion

RDMnet (BSR E1.33) Draft Standard General Discussion General Discussion and questions concerning the draft E1.33 standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old August 27th, 2011   #1
owaits
Member
 
Join Date: Aug 2011
Posts: 32
Default Some questions and comments

Some of these I will submit in my feedback form but thought I would leave them here for others to see and discuss. Most are questions though.

1) The SLP scope is listed as ACN_DEFAULT when it should be ACN-DEFAULT
2) Why is the test representation of the UId 0mmmmdddddddd when in E1.20 the textual format of the UId is mmmm:dddddddd
3) It is not made clear what the format of a URL Entry is in SLP. There is even a missleading section called "URL Entry" which does not define the correct packet structure for the URL Entry block.
4) In the Service Reply packet for SLP it incorrectly states that the URL Entry is a string value. Infact it is an array of URL Entry structs as defined in RFC 2608 Section 4.3
5) It has not been clear to me how a device which is connected directly to the ACN network but is not a gateway, DMX splitter or DMX converter should behave. Is it intended that ACN native devices should be allowed to support RDM through e1.33?
6) I spent a while working out that the RDM packet data was intended to be transport over the sACN using the DMX Data section of the packet. Once I realised this it all made allot more sense. While reading careful you can grasp this a drawing showing the RDM packets nested in the sACN packets might be helpful.
7) When you wrap the RDM packet into the E1.30 DMX data should you use the full RDM header with Sub-Start Code, Message Length, Desitination UID and Source UID?
owaits is offline   Reply With Quote
Old August 29th, 2011   #2
sblair
Administrator
 
Join Date: Feb 2006
Posts: 415
Send a message via AIM to sblair Send a message via MSN to sblair
Default

Thanks for the posting. Just to point out for everyone, any comments you want to be considered for changes will need to be submitted through the Public Review comment form.

Quote:
1) The SLP scope is listed as ACN_DEFAULT when it should be ACN-DEFAULT
This is intentional as it references what would be a #define and a dash is not a valid character for those as it would be viewed as an operator. You'll see these frequently throughout the E1.20 document.

Quote:
2) Why is the test representation of the UId 0mmmmdddddddd when in E1.20 the textual format of the UId is mmmm:dddddddd
The E1.20 format is intended for human readable fields. If you are talking about the UID where it is referenced in the SLP URL, then that is intended as a machine readable field and not for human consumption The : usage in the URL Entry has specific meaning to denote an IP port.

It is worth submitting as a Public Review comment so that we can research it further though.

Quote:
3) It is not made clear what the format of a URL Entry is in SLP. There is even a missleading section called "URL Entry" which does not define the correct packet structure for the URL Entry block.
Yes, we have discovered that there is information missing in the URL Entry sections that we will be adding in the next Public Review document. Please be sure to submit comments with the elements you see missing as well, so that we catch everything.

Quote:
4) In the Service Reply packet for SLP it incorrectly states that the URL Entry is a string value. Infact it is an array of URL Entry structs as defined in RFC 2608 Section 4.3
I believe you are correct. I recall an email discussion in the task group highlighting this recently but I don't have any notes in our working draft yet to this effect, so please submit this one as a comment!

Quote:
5) It has not been clear to me how a device which is connected directly to the ACN network but is not a gateway, DMX splitter or DMX converter should behave. Is it intended that ACN native devices should be allowed to support RDM through e1.33?
It depends on how you define ACN. We are really only concentrating on networks involving E1.31 (aka sACN). It is fully intended that native E1.31/E1.33 devices can exist on a network. This may be an area that needs further explanation, if so please help us in the Public Review comments by highlighting what changes you believe will help clarify it.

In short though we have tried to be flexible in how it operates by embracing the fact that many products that take E1.31/E1.33 natively will often act as a Gateway themselves by transmitting DMX directly on their 485 output port to other devices along a truss. We also embraced that there are numerous products these days that will consume multiple universes of E1.31/E1.33 natively (such as media servers). In these cases many of the messages for configuring gateway devices are also very valid for configuring native devices. You'll see a "Gateway" field in the PORT_TO_UNIVERSE message that informs the controller if the Port is a Physical (Gateway) or Virtual port (native device).

I hope this helps clarify, again please submit public review comments to the affect of anything you think needs to be added to clarify the situation.

Quote:
6) I spent a while working out that the RDM packet data was intended to be transport over the sACN using the DMX Data section of the packet. Once I realised this it all made allot more sense. While reading careful you can grasp this a drawing showing the RDM packets nested in the sACN packets might be helpful.
That is a good suggestion. Sometimes it is hard for us to see the forest for the trees in the Task Group. Please include as a Public Review comment and I'll be certain we include that.

Quote:
7) When you wrap the RDM packet into the E1.30 DMX data should you use the full RDM header with Sub-Start Code, Message Length, Desitination UID and Source UID?
Yes, it is intended to be fully wrapped, this makes it easier for parsing and translation between devices and networks.

All good questions!
__________________
Scott M. Blair
RDM Protocol Forums Admin
sblair is offline   Reply With Quote
Old August 29th, 2011   #3
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 355
Default

Quote:
Originally Posted by sblair View Post
This is intentional as it references what would be a #define and a dash is not a valid character for those as it would be viewed as an operator. You'll see these frequently throughout the E1.20 document.
For the sake of interoperability, E1.33 needs to match the SLP implementation used in E1.17 EPI 19. Since EPI 19 uses, the dash, we'll need to stick with a dash in E1.33.

There's relatively little risk of it being interpreted as a subtraction operator since ACN-DEFAULT is an ASCII string, and not a named constant definition.

Thus, the preprocessor definition is:

#define SLP_SCOPE "ACN-DEFAULT"
and not
#define ACN-DEFAULT 0x1234

If we change the scope, E1.33 devices may not work with pre-existing SLP Directory Agents (DAs).

owaits:
Please keep scrutinizing the SLP portion of the document. It's one of the places that we're most concerned about errors creeping in.
ericthegeek is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Cable shield connection questions berntd RDM Physical Layer/Hardware Discussion 0 May 25th, 2008 11:22 PM


All times are GMT -6. The time now is 08:29 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.