[Sis-dtn] HPRP Orange Book - Draft A for Comments

[Jeremy.Mayer at dlr.de]

Hi Brian,
Thanks! Comments inlined.

Thanks,
Jeremy

From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Sipos, Brian J. via SIS-DTN
Sent: Dienstag, 5. März 2024 22:12
To: Felix Flentge <Felix.Flentge at esa.int>
Cc: sis-dtn at mailman.ccsds.org
Subject: Re: [Sis-dtn] HPRP Orange Book - Draft A for Comments

Felix and Jeremy,
This is a good definition of this protocol so far. I have a few feedback comments to clarify some things.

One aspect of the HPRP that doesn't seem to be discussed is the technical relationship between HPRP and LTP in the sense that the two protocols can be disambiguated over the same (datagram) channel. They put the version code in the same starting spot in each datagram and use disjoint code points that an endpoint or a middlebox can use to distinguish them. This could be explicitly not a requirement for interoperation between LTP and HPRP over the same paths, but just to mention that it could happen and there is no problem in doing so. JPM: You caught us ;) One of the previous drafts explicitly outlined this possibility, but the text was removed in a prior review, around the same time as we moved from LTPv2->HPRP. Since we "broke" the lineage between LTP and HPRP, the version number didn't make much sense. I'll re-add the text, but I think we should specify that, for UDP channels, a different port number should be used. However, for space data links, this disambiguation may be useful.

In Section 3.6 I think the need from the underlying layer are not just to send and receive segment data, but when sending there must be either a notion of a destination (parameterized by engine ID perhaps) or a discussion that this parameterization assumes that the underlying layer is assumed to be point-to-point with a single peer engine (and if there are actual link addresses required those addresses need to be handled outside of the HPRP engine/layer).
JPM: Agreed; will specify that the mapping from destination engine ID->link-specific addressing must be managed out-of-band.
In Section 3.6 it would be helpful to have an explicit statement that this protocol does not rely on there being any relation between the forward and return path taken by segments between two HPRP engines. They could involve completely separate underlying transport, framing, or link layers.
JPM: Agreed, will add.
Generally about the integer fields: I don't see any statements about the endianness of multi-octet integers. It would be good to be explicit about this, maybe at the start of Section 4.
JPM: Agreed, will add.
Is there an expected use/need/benefit from non-power-of-two encoded sizes? Is there any requirement for minimum-length encodings? Can an engine choose to just use 4-octet (or whatever other fixed length) encodings for everything (assuming it fits all needed values)?
JPM: Yes, an engine can fix any and all lengths, especially in avionics-world... We originally had a rationale document specified as a green book which described this, but since this is an orange book (and not subject to blue-book terseness), I'll add it as an intro-section.
One other nit: The "session length" field may be less confusingly called the "block length" to use the term "block" consistently with other parts of the document.
JPM: I need to review this :)
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org>> On Behalf Of Felix Flentge via SIS-DTN
Sent: Tuesday, March 5, 2024 8:10 AM
To: Dr. Keith L Scott via SIS-DTN <sis-dtn at mailman.ccsds.org<mailto:sis-dtn at mailman.ccsds.org>>
Subject: [EXT] [Sis-dtn] HPRP Orange Book - Draft A for Comments

APL external email warning: Verify sender sis-dtn-bounces at mailman.ccsds.org<mailto:sis-dtn-bounces at mailman.ccsds.org> before clicking links or attachments



Dear All,

Jeremy and myself produced a new draft for the HPRP Orange Book.

Please note that there are still some open questions which also may lead to some updates of the data formats. In addition, we certainly need to work on the specification of the protocol behaviour.

The document is available in Google Docs. Please add any comment you may have directly to the document.

https://docs.google.com/document/d/1WsxgHSiG7UQNiHNHXtPOv9Dd98fK_ZKN/edit?usp=sharing&ouid=113258250953253070571&rtpof=true&sd=true

Regards,
Felix

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int<mailto:dpo at esa.int>).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240404/6e2ea49b/attachment.htm>