[Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Felix.Flentge at esa.int
Felix.Flentge at esa.int
Mon Oct 25 10:38:03 UTC 2021
Hi,
I don't see a major issue of having LTPv1 and LTPv2 (or LTP+ ?) as Blue
Books for a longer period of time as they are 'only' link layer protocols
and these links will have to be designed for interoperability anyway
(frequencies, coding & modulation, data link layer protocol, ...).
Furthermore, we may have really separate domains with optical / high-rate
RF Earth observation downlinks and Gateway/LunaNet/Moonlight. Of course,
in the long term, we should converge to a single protocol.
Also, I would prefer to have a bit longer time frame for the LTP+
definition. ESA will kick-off a dedicated activity for the definition and
prototyping (including hardware implementation) very soon but it will take
until end of 2022 to finish. This would give us also a reference
implementation for the interoperability testing.
Regards,
Felix
From: "Torgerson, J. Leigh\(US 332C\) via SIS-DTN"
<sis-dtn at mailman.ccsds.org>
To: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>, "Vint
Cerf" <vint at google.com>, "Dr. Keith L Scott" <kscott at mitre.org>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford,
Kevin" <kevin.gifford at colorado.edu>
Date: 12/10/2021 23:34
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Sent by: "SIS-DTN" <sis-dtn-bounces at mailman.ccsds.org>
Fair enough ? I?m not too worried about BPv6 one way or another ? users
are not limited to several dozen ISS payloads, a few cubesats that are due
to launch next year, and KPLO. Everyone now is working on using BPv7, and
there aren?t going to be any pink sheets to the BPv6 book that I foresee..
I do believe LTPv1 and LTPv2 should be two separate books, unless CCSDS
thinks it is OK to deprecate protocols that are in active use by missions
and in continued support by the DSN. LTPv1 is a different protocol from
LTPv2; it isn?t merely an older version of the same protocol. Not
backwards compatible, not just an enhanced version, but a new beast.
Therefore we need a new book that can co-exist with LTPv1 until such time
as no one is using LTPv1. Once LTPv2 is practically ready for use in
actual missions, we can debate when (or whether) to silverize LTPv1?s
book.
Leigh
From: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Date: Tuesday, October 12, 2021 at 2:03 PM
To: "Torgerson, Jordan L (332M)" <jordan.l.torgerson at jpl.nasa.gov>, Vint
Cerf <vint at google.com>, "Scott, Keith L." <kscott at mitre.org>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford,
Kevin" <kevin.gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Hey Leigh,
I never said ?make BPv6 (or LTPv1) Silver before the new BB exist?. Never
did. Never would.
I did say that I thought that once the new versions are published that
then the old books should be ?silverized?. This is the way that CCSDS
handles such matters. Either that or we name them as two separate
protocols with two separate numbers. That does not remove them, they are
still available. It does deprecate them. This is a consequence of both
of these protocol version updates being designed to not be backward
compatible.
We (CCSDS, IETF, and the DTN community) have made all of our lives more
complicated by pushing these specs while they were still maturing. We all
want DTN to succeed, but making significant protocol changes this early in
the game is the cause of the problem and, as you have clearly pointed out,
this is going to push complexity into deployments for some time into the
future.
That?s the reality. Now let?s deal with it as best we can until we can
get to some more stable point.
Peter
From: Leigh Torgerson <jordan.l.torgerson at jpl.nasa.gov>
Date: Tuesday, October 12, 2021 at 10:51 AM
To: Peter Shames <peter.m.shames at jpl.nasa.gov>, Vint Cerf
<vint at google.com>, Keith Scott <kscott at mitre.org>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford,
Kevin" <kevin.gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
As I have mentioned before, I don?t have a problem with making the BPv6
book a ?silver book? - other than existing missions that use it, no new
missions are contemplating bpv6 now, and no new features will be added to
ION v3.7.x versions (bpv6), just bug fixes as they come up.
However, I strongly disagree with making the ltpv1 spec ?silver? at this
time.
There are currently bpv7 (ION 4.1) / ltpv1 systems being developed for
flight missions, and assuming that the promised IETF spec for bpv7 is out
soon (something we?ve been promised for months now), contracts may have to
be let soon by NASA that specify BPv7/LTPv1.
What CCSDS never considers is the fact that from the time a new CCSDS spec
hits the street until the DSN is funded to implement, test and be ready to
offer that new protocol as a service, it?s $millions and years before that
happens.
CCSDS and the DTN program already shot DTN in the kneecaps by rushing in
to BPv7 right at the time NASA was starting to let contracts for vendors
and get the DSN to support DTN ? no specs for BPv7 meant no way to specify
DTN but to lamely describe ?features? like ?store and forward?, so vendors
were left to either reinvent DTN by some software over UDP/IP/CCSDS
telemetry or to look at cFS or ION with bpv6/ltpv1. CCSDS couldn?t even
agree that a spec for BSSP was necessary, so when we had to support that
for the KPLO mission, we couldn?t even put it in the ICD properly (citing
?man pages? isn?t an approved way to write an ICD).. So as of today,
contracts that would come out in the next year or so for specifying DTN
use in the 2024-25 timeframe (and near-term RFIs for Marsnet) will have to
specify BPv7 (assuming IETF comes through soon) and LTPv1.
Then NASA will have to fund the DSN to incorporate ION v4.x.x to have a
BPv7 and LTPv1 capability.
Nip ltpv1 in the bud? Here?s what it is going to take to get ltpv2 in
place and ready to support missions that are supported by the DSN:
The steps:
1. Define the spec and at least get a Redbook out ?
2. Pay at least two independent groups to write two LTPv2
implementations for the purpose of interoperability testing to validate
the spec. (standard CCSDS practice except when no one else cares, as was
the case with SCPS)
One implementation should be ION, as that is what will go into the DSN ?
and that?s not funded at present.
3. Test these reference implementation to certify that the new
specification is correct, and then commence the process of going from
Redbook to Bluebook.
4. Make these ?reference implementations? available to DTN
implementors and the DTN ION Hardening / DSN implementation test teams at
JPL to
a. Write the official ION implementation of LTPv2 for the DSN
b. Validate the performance, memory management, set-up methods and
efficiency of the new LTPv2, at least for DSN RF downlink speeds. (Optical
comm implementations at Table Mountain, etc is a whole ?nother discussion)
5. Fund the DSN, NSN, and maybe MSU, to install, test and operate
LTPv2 so the ground infrastructure can support it.
6. Then we will be in a position to encourage use of LTPv2, assist
any early-stage vendors to switch over to LTPv2, and come up with
cost-benefits analyses that will show NASA why it is worth paying vendors
or (by then) flight missions to switch over to LTPv2, do all the
interoperability testing with NSN and DSN, etc.
If CCSDS and SCaN can come up with the budget and timetable that would let
steps 1-6 be accomplished in the next 12-24 months, then maybe killing
ltpv1 now would be OK. But I also might as well ask for a pony for
Christmas.
On the other hand, if you just want to insure that DTN will not be used in
Lunanet until 2030, then go ahead and deprecate ltpv1 now, making it
unlikely any vendor in the next 3-4 years will implement ltp at all (no
spec, no DSN support, no sale. I know you can still cite a silver book in
a contract, but knowing that ltpv1 is a deprecated standard means no one
would be eager to implement it.)
The DSN is going to have to support 3 versions of DTN as it stands now ?
BPv6/ltpv1, BPv7/ltpv1 and BPv7/ltp2, and two of the three are not funded
for infusion any time soon. (and ION development isn?t funded yet for
ltpv2 compatibility.) No one has funded the implementation of USLP in the
DSN yet either, by the way, and no reference implementations have been
made available to commercial telemetry vendors.. I hold that up as yet
another case where CCSDS specs come out years and years before anyone in
the community is ready to use them in an end-to-end system.. (Want to
discuss how long it took between the time I was NASA rapporteur for
?protocol-X? (circa 1997?), which became CFDP, and the time when some
missions actually used it?)
I have no faith that steps 1-6 above can be completed in time to get the
Lunar missions on the bandwagon to use BPv7 over a ?high speed? LTP
version not many spacecraft would even need. (I believe that LTPv2 could
well serve for specialized optical comm missions that needed the high
speed FPGA implementations, and LTPv1 could continue to serve most RF
missions.)
We can move in the direction of BPv7/LTPv2 certainly, but don?t eliminate
the CCSDS Bluebook for LTPv1 until there are specs for BPv7 and LTPv2 that
can be used by NASA in contracts (or by DSN in ICDs).
Leigh
J. Leigh Torgerson
Space Communications Networking Architect
Protocol Technology Lab Manager
Communications Architectures & Research (332)
Jet Propulsion Laboratory
4800 Oak Grove Drive M/S: 238-420
Pasadena, CA 91109
Office: (818) 393-0695
Email: ltorgerson at jpl.nasa.gov
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of "Shames,
Peter M (US 312B) via SIS-DTN" <sis-dtn at mailman.ccsds.org>
Reply-To: "Shames, Peter M (US 312B)" <peter.m.shames at jpl.nasa.gov>
Date: Monday, October 11, 2021 at 5:55 PM
To: Vint Cerf <vint at google.com>, "Scott, Keith L." <kscott at mitre.org>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, "Gifford,
Kevin" <kevin.gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Vint and Keith,
Given that we are really just getting started with building and deploying
DTN and LTP based systems in space in any broad sense I think we are
better off silverizing these now and nipping in the bud any expansion of
these older protocols we are trying to leave behind.
With IPv4 vs IPv6 there was already a major deployment of IPv4 such that
it could not easily be abandoned. In our case I think LTPv1 and BPv6 are
more like IPv1, v2, and v3. They must have existed along the way to IPv4,
but they are now lost to the dusts of time. In the RFC Editor files there
is not even a mention of these, but I assume that they existed at some
point.
I worry with our current relatively small community that we will just
start to build in more complexity if we perpetuate both versions of both
of these key protocols.
Regards, Peter
From: Vint Cerf <vint at google.com>
Date: Monday, October 11, 2021 at 7:18 AM
To: Keith Scott <KSCOTT at mitre.org>
Cc: "Tomaso.deCola at dlr.de" <tomaso.decola at dlr.de>, Peter Shames
<peter.m.shames at jpl.nasa.gov>, "sis-dtn at mailman.ccsds.org"
<sis-dtn at mailman.ccsds.org>, "Gifford, Kevin" <Kevin.Gifford at colorado.edu>
Subject: Re: [Sis-dtn] [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
i think Keith and Leigh have correctly characterized the situation. I
would stick with both as valid but incompatible. CF: IPv4 and IPv6'
v
On Mon, Oct 11, 2021 at 10:12 AM Dr. Keith L Scott <kscott at mitre.org>
wrote:
Peter,
I think the real issue at hand is whether or not to maintain the LTPv1
spec as Blue once LTPv2 is published.
My interpretation of Leigh?s argument is that vendors are currently
implementing to LTPv1 (and the current BPv6-based BP for CCSDS Book) and
that deprecating those specs in favor of new, non-backward-compatible ones
would be looked upon unfavorably.
v/r,
--keith
From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>
Date: Monday, October 11, 2021 at 3:11 AM
To: peter.m.shames at jpl.nasa.gov <peter.m.shames at jpl.nasa.gov>
Cc: Dr. Keith L Scott <kscott at mitre.org>, Gifford, Kevin <
kevin.gifford at colorado.edu>, marc.sanchez.net at jpl.nasa.gov <
marc.sanchez.net at jpl.nasa.gov>, sis-dtn at mailman.ccsds.org <
sis-dtn at mailman.ccsds.org>
Subject: RE: [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Dear Peter,
Thank you for your kind support and availability for helping us in finding
a suitable solution.
Indeed the two options you have mentioned are also those we have put on
the table as possible solutions, although both of them show pros and cons
and therefore compromise and agreement/consensus between the parties will
have to be reached. This discussion will keep on going during the next DTN
telco as well as the official CCSDS DTN WG Fall meetings in order to reach
soon an agreed approach as also mentioned by Keith in a previous e-mail.
In case no solution will be agreed, then I?ll certainly bring this point
in the SIS area summary at the CESG meeting in November in order to find a
way out for this impasse. Obviously, I?ll certainly count on your and
other CESG colleagues suggestions to move forward and more importantly to
avoid any postponed decision that would be detrimental to the activities
of the DTN WG.
Best Regards
Tomaso
From: Shames, Peter M (US 312B) <peter.m.shames at jpl.nasa.gov>
Sent: Samstag, 9. Oktober 2021 01:26
To: Kevin K Gifford <kevin.gifford at colorado.edu>; Dr. Keith L Scott <
kscott at mitre.org>; Cola, Tomaso de <Tomaso.deCola at dlr.de>; Sanchez Net,
Marc (US 332H) <marc.sanchez.net at jpl.nasa.gov>
Cc: sis-dtn at mailman.ccsds.org
Subject: Re: [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Guys,
As a long term member of the CESG I do agree that you can kick it
?upstairs? to the CESG and have, I believe, a hope of getting a sensible
response (most of the time). Heck, we are human and therefore fallible.
>From my own point of view I recommend doing two things:
1. As I understand it, they are different protocols, hence not
?backward compatible?. Using the ?version? option, including, in this
case, adopting some explicit name extension like LTPv2 makes the most
sense to me. The rationale for that is that what you plan to produce is
not backward compatible with v1. In other words, there is no way to
configure V2, without the new options, and still have a v1 implementation
accept it.
2. Silverize the v1 book. This is normally done when a new protocol
version is created. The old silver book will still be available and it
may be referenced with its (new) silver name and number. This has
happened before with other specs. It is not unusual for some mission to
nail their interface to some specific version of a document, even, in some
cases, a Red Book (which is really dangerous since they are likely to
change).
If you want to discuss this further please let me know. And it you do
decide to send it to the CESG you now know where I stand, and why. Of
course, if any of my assumptions are flawed I am happy to be corrected.
Cheers, Peter
From: Kevin K Gifford <kevin.gifford at colorado.edu>
Date: Friday, October 8, 2021 at 11:58 AM
To: Keith Scott <kscott at mitre.org>, "Tomaso.deCola at dlr.de" <
Tomaso.deCola at dlr.de>, Marc Sanchez Net <marc.sanchez.net at jpl.nasa.gov>
Cc: "sis-dtn at mailman.ccsds.org" <sis-dtn at mailman.ccsds.org>, Peter Shames
<peter.m.shames at jpl.nasa.gov>, Kevin K Gifford <kevin.gifford at colorado.edu
>
Subject: [EXTERNAL] Re: [EXT] RE: LTP vs LTPv2
Hi SIS-DTN -
FWIW, I want to emphasize that the CESG does a great job in this regard
(fixing issues that arise in WGs or inter-WG conflicts or inter-agency
conflicts).
-- Keith was a member of the CESG for several years and understands this
vital role that the CESG plays in issues such as this
Thus, my two cents worth is await CESG advice as well as Keith already
stated (I wanted to maybe ease any queasiness in regard to CESG
involvement/inputs).
Thanks.
Kevin
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> on behalf of Dr. Keith L
Scott <kscott at mitre.org>
Sent: Friday, October 8, 2021 12:49 PM
To: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>;
marc.sanchez.net at jpl.nasa.gov <marc.sanchez.net at jpl.nasa.gov>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: Re: [Sis-dtn] [EXT] RE: LTP vs LTPv2
OK fine, if the CESG decides to not rule on it, great, we?ll make a
decision in the WG and they can live with it (and we can certainly discuss
it SOME in the WG; don?t want to put too much time into it until the CESG
is at least given a chance to get us out of this).
--keith
From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>
Date: Friday, October 8, 2021 at 10:04 AM
To: Dr. Keith L Scott <kscott at mitre.org>, marc.sanchez.net at jpl.nasa.gov <
marc.sanchez.net at jpl.nasa.gov>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: RE: [EXT] RE: LTP vs LTPv2
Hi Keith,
I agree with your point on troubles in maintaining two books and the fact
that this will imply the same treatment for BPv7. Then whether agencies
are happy to refer to a silver book rather than a blue book is a bit
question mark in my opinion. I remember we decided a few years ago not to
silverize SCPS-TP exactly because there were activities or usage of the
corresponding blue book.
We can certainly bring this matter to the next CESG meeting, although I
fear that there might be no strict decision in this regard, since I think
there is no specific rule again either approaches and the hot potato could
be sent back to WG.
Regards,
Tomaso
From: Dr. Keith L Scott <kscott at mitre.org>
Sent: Freitag, 8. Oktober 2021 15:52
To: Cola, Tomaso de <Tomaso.deCola at dlr.de>; marc.sanchez.net at jpl.nasa.gov
Cc: sis-dtn at mailman.ccsds.org
Subject: Re: [EXT] RE: LTP vs LTPv2
I don?t like it, but I propose that the WG move forward with developing
the book and you bring up the new-version vs. new-book issue to the CESG.
Reasons I don?t like the two-book solution:
So now we?re maintaining two versions of LTP, which version are folks
supposed to choose for missions going forward? They?ll choose the one
with flight heritage, right?
We?ll have to do the same thing with BPv7
There?s a version number in the header; receivers will know what was sent.
The book as Silver is still reference-able. If folks have systems they?re
building to the current (v1) book, they can switch to referencing the
silver book.
Why don?t we do that with ALL CCSDS books, backward-compatible or not?
--keith
From: Tomaso.deCola at dlr.de <Tomaso.deCola at dlr.de>
Date: Friday, October 8, 2021 at 4:19 AM
To: marc.sanchez.net at jpl.nasa.gov <marc.sanchez.net at jpl.nasa.gov>, Dr.
Keith L Scott <kscott at mitre.org>
Cc: sis-dtn at mailman.ccsds.org <sis-dtn at mailman.ccsds.org>
Subject: [EXT] RE: LTP vs LTPv2
Then probably we should better keep two books, one with the ?old LTP? for
which we?ll do some pink sheets to fix some inconsistencies and another
one (the new LTP). In such a away we could have two versions of LTP
available, similarly to IPv4 and IPv6 in IETF. Probably we may have to
slightly change the title of the books (v1 and v2?) to have a clear
demarcation between the two version of the protocols and avoid any
ambiguity.
@Scott, Keith L.:what do you think?
Tomaso
From: SIS-DTN <sis-dtn-bounces at mailman.ccsds.org> On Behalf Of Sanchez
Net, Marc (US 332H) via SIS-DTN
Sent: Donnerstag, 7. Oktober 2021 00:21
To: sis-dtn at mailman.ccsds.org
Subject: [Sis-dtn] LTP vs LTPv2
All,
I had to leave today?s meeting early. Did we reach consensus on how to
proceed?
Also, I will note that some colleagues at JPL (I have similar concerns) do
not really like the idea of turning the current version of LTP into a
silver book. The problem is that, by definition, a silver book implies
that a protocol is deprecated or obsolete, but several systems that are
being built today use BPv6+LTP or BPv7+LTP and thus might be in operation
for a long time. So, essentially, we are ?telling? industry that they have
developed an already obsolete standard?
Best,
-----------------------------------------------------------------------------------------------------------------------
Marc Sanchez Net
Telecommunications Engineer
Jet Propulsion Laboratory
Office: (818) 354-1650 | Email: marc.sanchez.net at jpl.nasa.gov
-----------------------------------------------------------------------------------------------------------------------
_______________________________________________
SIS-DTN mailing list
SIS-DTN at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn
--
Please send any postal/overnight deliveries to:
Vint Cerf
1435 Woodhurst Blvd
McLean, VA 22102
703-448-0965
until further notice
_______________________________________________
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/20211025/1e130fdc/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 11926 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mailman.ccsds.org/pipermail/sis-dtn/attachments/20211025/1e130fdc/attachment-0001.bin>
More information about the SIS-DTN
mailing list