[Sis-dtn] IMC group IDs and namespaces/scoping

[Sipos, Brian J.]

This is mostly directed at Josh, as he is editing the IMC orange book, but
sending it to the mailing list for feedback.

 

The basic syntax of the IMC scheme EID is fine the way it is documented in
the orange book draft today, but for operational and interoperability
reasons the Group ID and Service ID components will probably need a similar
treatment to the IPN scheme Service ID [1] in order to separate code point
ranges for different purposes.

 

Specific to the IMC group ID, I think there may be some benefit to having
more than just "well known" and "private use" ranges in the same sense that
IPv6 architecture [2] has some defined "scopes". This is NOT (!) a
recommendation to take those names or meanings or anything like that. Just
that there may be some benefit within the IMC group ID code space to
separate between "well-known to the world" and "well-known within my
administrative domain" and "assigned within my mission for this video
stream". The reason being that all IMC group IDs will need to be
distinguished and unique across a whole big overlay network.

 

I had some discussion with Scott Burleigh earlier about also enabling the
concept of source-specific multipoint (SSM), which would require no
signaling changes but would be present in the API between BPA and
application. The reason for defining an SSM semantics would be for that last
range of group IDs above, where the group doesn't want to (or need to) be
globally unique just unique per-Source Node ID. This would avoid needing an
explosion of unique mission-specific private-use allocations to coordinate
when there are many sources wanting to use multipoint messaging concurrently
but each group member cares about only one source at a time (e.g. "stream
the video from this camera on this console, other camera on the other
console"). SSM also simplifies signaling needed to establish group
membership with CGR multipoint routing without changing its fundamental
behavior. This kind of logic agrees with the operational issues identified
with IP multicast in [3]; again I know that multipoint messaging is a
different mechanism than IP multicast but these same logical issues of
needing to avoid destination EID collisions across a network will come up
here just as well.

 

Any thoughts are welcome,

Brian S.

 

[1]
https://www.ietf.org/archive/id/draft-ietf-dtn-ipn-update-10.html#section-9.
3

[2] https://www.rfc-editor.org/rfc/rfc4291.html#section-2.7

[3]
https://www.ietf.org/archive/id/draft-ietf-pim-multicast-lessons-learned-03.
html

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240503/0030872e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6540 bytes
Desc: not available
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240503/0030872e/attachment.bin>