multicast
Senior elf
- Joined
- Jul 13, 2013
- Messages
- 715
Work continues on making e1.31 more useful and more flexible.. I'm currently working some extras and would like your feedback on what you think..
EXPANDED UNIVERSE COUNT
Firstly I know some people have a strong view point that the current 16 bits of universes is sufficient ( and I accept that for many situations it is ), there are situations where it isn’t. I also accept that there are ‘work-arounds’ for more universes and space, but they are just that, workarounds.
I also understand that sending lots of uncompressed data in e1.31 frames to single devices may to some seem like an odd thing to do. There are ways of sending more information compressed, and potentially more more efficiently. If you are building large video walls, then this is very appropriate.
If you are building very large scale installations with tens of thousands of end devices that consume in the range of 1 to 100 universes each, and you have a different set of parameters to that of the video wall situation. You want to be able to use very low cost receiver devices, where having to run decompression is not an option. Of course this has an impact on network bandwidth.. But networks are cheap in comparion to the compute resource required to do a near real time decode of a compressed image.
Why this needs to be standardised, is no different from any of the standards. It means that multiple vendors can work together using a common template.
Fortuantly the way the protocol work ( with the layers in the headers ) supporting more universes while maintaining backwards compatility is easy to achieve.
I would like to propose that we can make a simple addition to the protocol, which a Sender and Receiver MAY implement.
We create a new Vector type ( VECTOR_ROOT_131_EXPANDED_DATA) ß- I used expanded as a place holder. I don’t’ care what its actually called.
We then have a modified Framing layer. The only changes that is required here is that the Universe field is made to 4 bytes
And you have a different VECTOR.
The Universe Numbers in this instance SHALL be restricted to be greater than 65,635, so they do not conflict.
The DMP layer remains unchanged. ( other than the offsets changing )
These expanded universes can be sent unicast or multicast. There would be no implied mapping of universe numbers to multicast address’s. For these universes it would be up to the implementation to decide where to send them. This is essentially the same as you have now with unicast. You have to somehow tell your transmitter where the receivers are. This could be a manual thing, or an automatic process. But it doesn’t have to happen within the context of e1.31
This saves the entire massive effort of needing a discovery process, and or needing to deal to multicast group issues ( in the standard )
I believe this is a *VERY* simple thing to do, that only requires a small hand full of changes, and has no impact on backwards compatibility. The standard could go as far as to say that any device that does implement EXPANDED_DATA frames, SHALL also support ‘DATA’ frames and it has to be done the same way it is done today.
You get to eat your cake, keep your cake and have a new cake ( and ice-cream ).. I’d be very keen to know what negative impact this would have on anyone. I
If you don’t’ need it, that’s fine, you are not impacted by it.. But for those that do desire to do things this way then this really helps and it also helps spread the use-case of e1.31 into the massively growing ‘architainment’ space where large scale deployments are growing.
16 bits of universes sounds a lot until you have lots of buildings / sites that are all co-ordinated together. Overlapping the universe numbers ( by vlan or separated routing spaces ) is troublesome. ( you end up with the possibility that you have multiple universe ‘10’s or ‘207’ etc. )
Manufacturer specific Frames.
I have had reason to want to send some streaming data that does not fit well in a dmx frame to my own devices.. While I don’t’ want to go into too much detail, because its commercially interesting, it broadly falls into what I’d call a ‘dynamic configuration’ where things are interactive. Its not so much ‘configuration’ but more a data set that is used to manipulate other data.
Fortunately thanks to the structure of the packets, and its layers, its easy enough.
At the root layer, we create a new Vector. I’ve called this VECTOR_ROOT_E131_MANUFACTURER
If your device doesn’t know about this because its following earlier standards, it would simply drop the packet. ( assuming that your device actually checks packets.. groan ) and at least in theory, you shouldn’t be sending these packets to devices that don’t’ need them anyway.
At the Framing layer, another VECTOR to identify this is a M
I think its helpful to leave the Synch/priority/sequence/options there so you can use them if you want but don’t’ have to. The Manufacturer ID can be the same ID’s that are already issued for RDM.
The manufacturers Vector code allows the the manufacturer to have multiple frame types.. From a helicopter view the frame ‘type’ is unique when you combine the ‘Vector’ and ‘Manufacturer_Vector’ together.
Rather than ‘hack’ in things that are not in standard, ( and have other vendors devices do ‘odd’ things ), this gives you a way to send out your ‘interesting proprietary’ data in a “non hacky” way.
This encourages a lot of room for innovation without impacting on core feature interoperability.
( Note: Its easy and free to get a manufacturers ID code, so if Xligths / Falcon / smartalec lights ) want codes then its just a form filling exercise.
EXPANDED UNIVERSE COUNT
Firstly I know some people have a strong view point that the current 16 bits of universes is sufficient ( and I accept that for many situations it is ), there are situations where it isn’t. I also accept that there are ‘work-arounds’ for more universes and space, but they are just that, workarounds.
I also understand that sending lots of uncompressed data in e1.31 frames to single devices may to some seem like an odd thing to do. There are ways of sending more information compressed, and potentially more more efficiently. If you are building large video walls, then this is very appropriate.
If you are building very large scale installations with tens of thousands of end devices that consume in the range of 1 to 100 universes each, and you have a different set of parameters to that of the video wall situation. You want to be able to use very low cost receiver devices, where having to run decompression is not an option. Of course this has an impact on network bandwidth.. But networks are cheap in comparion to the compute resource required to do a near real time decode of a compressed image.
Why this needs to be standardised, is no different from any of the standards. It means that multiple vendors can work together using a common template.
Fortuantly the way the protocol work ( with the layers in the headers ) supporting more universes while maintaining backwards compatility is easy to achieve.
I would like to propose that we can make a simple addition to the protocol, which a Sender and Receiver MAY implement.
We create a new Vector type ( VECTOR_ROOT_131_EXPANDED_DATA) ß- I used expanded as a place holder. I don’t’ care what its actually called.
| Octet | Field Size | Field Name | Field Description | Field Contents |
| Root Layer (See Section 5) | ||||
| 0-1 | 2 | Preamble Size | Define RLP Preamble Size. | 0x0010 |
| 2-3 | 2 | Post-amble Size | RLP Post-amble Size. | 0x0000 |
| 4-15 | 12 | ACN Packet Identifier | Identifies this packet as E1.17 | 0x41 0x53 0x43 0x2d 0x45 0x31 0x2e 0x31 0x37 0x00 0x00 0x00 |
| 16-17 | 2 | Flags and Length | Protocol flags and length | Low 12 bits = PDU length High 4 bits = 0x7 |
| 18-21 | 4 | Vector | Identifies RLP Data as 1.31 Protocol PDU | VECTOR_ROOT_E131_EXPANDED |
| 22-37 | 16 | CID | Sender's CID | Sender's unique ID |
We then have a modified Framing layer. The only changes that is required here is that the Universe field is made to 4 bytes
And you have a different VECTOR.
| E1.31 Framing Layer (See Section 6) | ||||
| 38-39 | 2 | Flags and Length | Protocol flags and length | Low 12 bits = PDU length High 4 bits = 0x7 |
| 40-43 | 4 | Vector | Identifies 1.31 data as DMP Protocol PDU | VECTOR_E131_DATA_PACKET (DMX512-A [DMX] data)_EXPANDED |
| 44-107 | 64 | Source Name | User Assigned Name of Source | UTF-8 [UTF-8] encoded string, null-terminated |
| 108 | 1 | Priority | Data priority if multiple sources | 0-200, default of 100 |
| 109-110 | 2 | Synchronization Address | Universe address on which sync packets will be sent | Universe on which synchronization packets are transmitted |
| 111 | 1 | Sequence Number | Sequence Number | To detect duplicate or out of order packets |
| 112 | 1 | Options | Options Flags | Bit 7 = Preview_Data Bit 6 = Stream_Terminated Bit 5 = Force_Synchronization |
| 113-116 | 4 | Universe | Universe Number | Identifier for a distinct stream of DMX512-A [DMX] Data |
The DMP layer remains unchanged. ( other than the offsets changing )
These expanded universes can be sent unicast or multicast. There would be no implied mapping of universe numbers to multicast address’s. For these universes it would be up to the implementation to decide where to send them. This is essentially the same as you have now with unicast. You have to somehow tell your transmitter where the receivers are. This could be a manual thing, or an automatic process. But it doesn’t have to happen within the context of e1.31
This saves the entire massive effort of needing a discovery process, and or needing to deal to multicast group issues ( in the standard )
I believe this is a *VERY* simple thing to do, that only requires a small hand full of changes, and has no impact on backwards compatibility. The standard could go as far as to say that any device that does implement EXPANDED_DATA frames, SHALL also support ‘DATA’ frames and it has to be done the same way it is done today.
You get to eat your cake, keep your cake and have a new cake ( and ice-cream ).. I’d be very keen to know what negative impact this would have on anyone. I
If you don’t’ need it, that’s fine, you are not impacted by it.. But for those that do desire to do things this way then this really helps and it also helps spread the use-case of e1.31 into the massively growing ‘architainment’ space where large scale deployments are growing.
16 bits of universes sounds a lot until you have lots of buildings / sites that are all co-ordinated together. Overlapping the universe numbers ( by vlan or separated routing spaces ) is troublesome. ( you end up with the possibility that you have multiple universe ‘10’s or ‘207’ etc. )
Manufacturer specific Frames.
I have had reason to want to send some streaming data that does not fit well in a dmx frame to my own devices.. While I don’t’ want to go into too much detail, because its commercially interesting, it broadly falls into what I’d call a ‘dynamic configuration’ where things are interactive. Its not so much ‘configuration’ but more a data set that is used to manipulate other data.
Fortunately thanks to the structure of the packets, and its layers, its easy enough.
At the root layer, we create a new Vector. I’ve called this VECTOR_ROOT_E131_MANUFACTURER
| Octet | Field Size | Field Name | Field Description | Field Contents |
| Root Layer (See Section 5) | ||||
| 0-1 | 2 | Preamble Size | Define RLP Preamble Size. | 0x0010 |
| 2-3 | 2 | Post-amble Size | RLP Post-amble Size. | 0x0000 |
| 4-15 | 12 | ACN Packet Identifier | Identifies this packet as E1.17 | 0x41 0x53 0x43 0x2d 0x45 0x31 0x2e 0x31 0x37 0x00 0x00 0x00 |
| 16-17 | 2 | Flags and Length | Protocol flags and length | Low 12 bits = PDU length High 4 bits = 0x7 |
| 18-21 | 4 | Vector | Identifies RLP Data as 1.31 Protocol PDU | VECTOR_ROOT_E131_MANUFACTURER |
| 22-37 | 16 | CID | Sender's CID | Sender's unique ID |
If your device doesn’t know about this because its following earlier standards, it would simply drop the packet. ( assuming that your device actually checks packets.. groan ) and at least in theory, you shouldn’t be sending these packets to devices that don’t’ need them anyway.
At the Framing layer, another VECTOR to identify this is a M
| E1.31 Framing Layer (See Section 6) | ||||
| 38-39 | 2 | Flags and Length | Protocol flags and length | Low 12 bits = PDU length High 4 bits = 0x7 |
| 40-43 | 4 | Vector | Identifies 1.31 data as DMP Protocol PDU | VECTOR_E131_MANUFACTUER |
| 44-107 | 64 | Source Name | User Assigned Name of Source | UTF-8 [UTF-8] encoded string, null-terminated |
| 108 | 1 | Priority | Data priority if multiple sources | 0-200, default of 100 |
| 109-110 | 2 | Synchronization Address | Universe address on which sync packets will be sent | Universe on which synchronization packets are transmitted |
| 111 | 1 | Sequence Number | Sequence Number | To detect duplicate or out of order packets |
| 112 | 1 | Options | Options Flags | Bit 7 = Bit 6 = Bit 5 = |
| 113-116 | 4 | Universe | Universe Number | Identifier for a distinct stream of DMX512-A [DMX] Data |
| 117-118 | 2 | Manufacturer ID | Identifies which manufacturer | Manufacturer ID |
| 119-120 | 2 | Manufacturer_Vector | | |
I think its helpful to leave the Synch/priority/sequence/options there so you can use them if you want but don’t’ have to. The Manufacturer ID can be the same ID’s that are already issued for RDM.
The manufacturers Vector code allows the the manufacturer to have multiple frame types.. From a helicopter view the frame ‘type’ is unique when you combine the ‘Vector’ and ‘Manufacturer_Vector’ together.
Rather than ‘hack’ in things that are not in standard, ( and have other vendors devices do ‘odd’ things ), this gives you a way to send out your ‘interesting proprietary’ data in a “non hacky” way.
This encourages a lot of room for innovation without impacting on core feature interoperability.
( Note: Its easy and free to get a manufacturers ID code, so if Xligths / Falcon / smartalec lights ) want codes then its just a form filling exercise.
