Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses

["Karstens, Nate" <[e-mail]>]

Mike and Stig,

Sorry for the delay, it took me a while to track down some answers to your questions.

There is an abbreviated version of the standard that we can make available to anyone, though this contains very little technical detail. We can also assign full copies of the standard to individuals for non-commercial review purposes. Each copy will need to be requested and watermarked. Please let me know if you are interested and I can help facilitate this.

That being said, some of the details that would help explain the full problem were delayed to a later version of the standard so that we could publish somewhat on-time. However, I can provide a little more of the relevant information beyond what I shared below. OneNet networks are currently only link-local. Each OneNet device on the network contains one or more PGN Virtual Devices. The application layer of each PGN Virtual Device uses Parameter Groups to transmit data. Parameter Groups are basically packed data structures and are a concept used in industry-standard CAN networks running protocols like ISO 11783, J1939, or NMEA 2000. The PGN Virtual Devices hosted by a device depends on the type of sensor data that device can provide. Consider a hypothetical OneNet device that contains the following PGN Virtual Devices:

1) Radar
2) Heading (to better align the radar image with the chart)
3) Air temperature
4) Humidity
5) Barometric pressure

The high-bandwidth Radar stream (possibly several hundred Mbps, or greater for some shore-based systems) could overwhelm the low-bandwidth links of other sensors on the network. To prevent this, each PGN Virtual Device transmits its data using a separate multicast address (though in practice, this would probably just be split between the high-bandwidth Radar and low-bandwidth heading, temperature, humidity, and pressure sensors). Network switches use multicast snooping to ensure that high-bandwidth multicast streams are kept off of the low-bandwidth links; devices with low-bandwidth links will simply not request that data.

Using interface local for this is not ideal because the PGN Virtual Devices on a OneNet device may be part of different applications installed on the same device, without any collaboration ahead of time (consider a PC with different applications from different manufacturers installed as-needed for a given vessel). This means that a PGN Virtual Device needs to negotiate an address both with other PGN Virtual Devices on the network and with PGN Virtual Devices running on the same host.

Hopefully that provides a good overview, but it would be great if I could come to Philadelphia to discuss further. Are there specific days you had in mind to discuss this topic?

Nate

-----Original Message-----
From: Stig Venaas <[e-mail]> 
Sent: Friday, June 3, 2022 12:33
To: Michael McBride <[e-mail]>
Cc: Karstens, Nate <[e-mail]>; [e-mail]
Subject: Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses

CAUTION - EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.


Hi Nate and Mike

We had some discussions about a fairly similar problem for IPv4 10-15 years ago, but it didn't go anywhere. But this is an interesting problem and I think we should look into it. At least I am interested.

Regarding multiple applications on the same host. I wonder if interface-local, scope 1, could be used for that. If the application doesn't need to use the same group on multiple interfaces, that should work. Of course if the protocol uses link-local, then that could also work for multiple applications in the same host.

Regards,
Stig

On Wed, Jun 1, 2022 at 1:53 PM Michael McBride <[e-mail]> wrote:
>
> Hi Nate,
>
>
>
> Thank you for bringing this up on the list. Very interesting application of multicast. It appears we would need to purchase the OneNet standard to review it. Is there anything available we can read to delve further into the multicast aspects of the OneNet architecture? It would also be great if you could present an overview at our upcoming meeting in Philadelphia (in person or remote) the week of July 24th.
>
>
>
> This pim group is the correct group to help determine if modifying existing protocols will work or if a new one should be developed. We will likely need to also reach out to some of the individuals who worked on zeroconf (including ZMAAP). Perhaps we can revive that work in pim.
>
>
>
> mike
>
>
>
> From: pim <[e-mail]> On Behalf Of Karstens, Nate
> Sent: Thursday, May 26, 2022 10:17 AM
> To: [e-mail]
> Subject: [pim] Zero-Configuration Assignment of IPv6 Multicast 
> Addresses
>
>
>
> Greetings,
>
>
>
> I am the chair of a standards committee at the National Marine Electronics Association (NMEA). We are in the final stages of developing NMEA OneNet, a standard for Ethernet/IPv6-based communication and control of marine systems (a little background: NMEA has existing standards, NMEA 0183 and NMEA 2000, that provide similar functionality over serial and CAN).
>
>
>
> Marine networks can be a mix of low-bandwidth embedded sensors and high-bandwidth streams for radar and video data, and most of this data is sent multicast on the local network. In order to prevent high-bandwidth streams from overwhelming low-bandwidth links, we assign traffic to different multicast addresses and then use multicast snooping to direct those streams only to hosts that request them.
>
>
>
> Source-specific multicast is not feasible due to the available switch hardware. As such, we believe we have identified a need for zero-configuration assignment of IPv6 multicast addresses on the local network.
>
>
>
> We investigated MADCAP, but this is not ideal because maritime systems try to avoid single points of failure. We also found ZMAAP, which seemed promising, but it was only a draft standard that expired in 2003. Link-scoped multicast addresses also seemed promising, but when you transmit these addresses on Ethernet you get 33:33 followed by 32 bits of the group ID, so even devices that assign their own IPv6 multicast addresses using a unique IID can still collide at the Ethernet layer due to the colliding group IDs.
>
>
>
> Another related complication is that multicast streams can originate from different applications on the same host, and there is no mechanism for those applications collaborating to avoid collisions at the IPv6 layer.
>
>
>
> Instead of developing our own method, we decided it may be preferable to work with IETF to develop an Internet standard that we could then use in our work. (Or, if there is something that will work for us but we’re not aware of, to learn about that). Alvaro recommended that we email this group to start the conversation and see where that leads us.
>
>
>
> Thanks,
>
>
>
> Nate Karstens
>
> Garmin International, Inc.
>
> Chair, NMEA OneNet TSC
>
>
>
> ________________________________
>
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you.
>
> _______________________________________________
> pim mailing list
> [e-mail]
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/pim_
> _;!!EJc4YC3iFmQ!VWcPzFC4cjG_LQmNSJB-A6sSm6AmWHu4oMI_OdY6E5xOa_ZIjTM7dm
> MEif2-iruW_QU86IeKVUqZQg$