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

Keith Scott keithlscott at gmail.com
Wed Mar 6 02:05:45 UTC 2024


Maybe in 3.6 instead of 'forward and return PATHS' -- 'forward and return
DIRECTIONS'?  Yes, you can run LTP over multi-hop (e.g. UDP), but I think
that in general, especially for in-space networks (where LTP makes the most
sense) we want to discourage that.

v/r,

    --keith


On Tue, Mar 5, 2024 at 3:26 PM Sipos, Brian J. via SIS-DTN <
sis-dtn at mailman.ccsds.org> wrote:

> 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.
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> 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.
>
> 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)?
>
>
>
> 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.
>
>
>
> *From:* SIS-DTN <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>
> *Subject:* [EXT] [Sis-dtn] HPRP Orange Book - Draft A for Comments
>
>
>
> *APL external email warning: *Verify sender
> 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).
> _______________________________________________
> SIS-DTN mailing list
> SIS-DTN at mailman.ccsds.org
> https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20240305/d859c110/attachment.htm>


More information about the SIS-DTN mailing list