Re: [dtn] LTP CL for BP v7

Keith Scott <keithlscott@gmail.com> Tue, 02 April 2024 13:45 UTC

Return-Path: <keithlscott@gmail.com>
X-Original-To: dtn@ietfa.amsl.com
Delivered-To: dtn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0959C14F6BD for <dtn@ietfa.amsl.com>; Tue, 2 Apr 2024 06:45:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.094
X-Spam-Level:
X-Spam-Status: No, score=-7.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eka-oMapHJst for <dtn@ietfa.amsl.com>; Tue, 2 Apr 2024 06:45:54 -0700 (PDT)
Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2ECC14F6E1 for <dtn@ietf.org>; Tue, 2 Apr 2024 06:45:54 -0700 (PDT)
Received: by mail-pl1-x633.google.com with SMTP id d9443c01a7336-1e27c303573so3910345ad.3 for <dtn@ietf.org>; Tue, 02 Apr 2024 06:45:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712065553; x=1712670353; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=mMf+Qruw9m+1b0eW+oAapoQUXzEgPaclKDdYdfqKMqw=; b=gTFAdXcDcYv8OnfoIeeAvCgI6hrZm+hsfL5v3HVrTJfRVgaJH6RZw3Ycrxaz0ack0E 3IrrKRFyvWpvArfBK6sF7E0hDjK1QtaJyKzRv0wxhH0qB8oYj3gJCExZ2dlpCG11f0g2 QLP0rvs5nEZhatCNcfz9Hut84f2QZGOvRcKWke40bruUHNZ6XoOJTEHYY3T9ACTOzSgl PW6vm/I6bGKmXg+IUx8doptzPfz1R4NPorgCMCYUSI+uyfSfl6PmUCDN2YTPoiTXB7eE 8VBmzVT/6NGQEMr3dBkPEZvsKpaD60L2Fa/kCDNbPIxW3mjxTfpWsWuV4GVIt9umSxGV foVA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712065553; x=1712670353; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=mMf+Qruw9m+1b0eW+oAapoQUXzEgPaclKDdYdfqKMqw=; b=ltsP0CP4CavbQthx4wMOMpjT3wT63VdaKKVFHCnHlG7domWfWXopdAw3pQvaQ8RATx qGSkutb4zqeXijtxgqdtWNCxnYOaG8Ju2LixJ8R3d9miRISsXMiUzVPbvGHPD22qO3Qg d1s3lpWbES7NkppiNwfvCcprc1F+xeX+Wl4SoMVmmSFf0a5jfsSNYN4c+FK3pcX8DnkL FtfI5MkAEfs0wopHbq7IaRkd3JlNO6R6U0X08d7s7oeV7lquwMMH2dmLTsOnc7kad+TZ fPITd2j8geIwCPx5bODUIAp5zMNiWmW6IIAu8/1POSZRIcqkIltMZP1WDVd/qjR/1IFt sLmw==
X-Gm-Message-State: AOJu0Yzrm5gKpe4svJlkFgDHbqguBVVIRNoMy4Dcj5PaziWjHAg6kfZg ZIxUQtg65msmiXrv1PolKl8vCxH+A0fWCykKY+JDQ/qAD589NWSWZMvvYBa7nAxCvplhxzvn2NI 04euPquAx8vRzrc6MBCotQZJ0gnY=
X-Google-Smtp-Source: AGHT+IF3V1QOrSZOvGIJPeADrGstFItisj0xRUjCzyCI/0Bostva8YzFVynFpLykHcupXM63DrHJoMkBXtUM6cpc1Fw=
X-Received: by 2002:a17:902:8a87:b0:1dd:6eba:c592 with SMTP id p7-20020a1709028a8700b001dd6ebac592mr10654266plo.56.1712065553058; Tue, 02 Apr 2024 06:45:53 -0700 (PDT)
MIME-Version: 1.0
References: <7AF8662D-FDA3-4C88-95B7-B116825C7023@gmail.com> <036b01da845f$455ea100$d01be300$@gmail.com> <CAHdkBBm-Ct9h7oMZyM=H4=XcSv0+Gboq=CW_F2Orb2hXAyE4Aw@mail.gmail.com> <CAHdkBBmTGhpamcc=aP7jZh7r-Oq4JhNVRoSkMQ=f+3MP9X1i8Q@mail.gmail.com> <94174279-8191-4098-807B-F86A286AD4C8@gmail.com>
In-Reply-To: <94174279-8191-4098-807B-F86A286AD4C8@gmail.com>
From: Keith Scott <keithlscott@gmail.com>
Date: Tue, 02 Apr 2024 15:45:40 +0200
Message-ID: <CAHdkBBkr52pFq23G=fWrE96hfrL94AsqhXh3VPtUyMJT5iLLVg@mail.gmail.com>
To: John Dowdell <john.dowdell.ietf@gmail.com>
Cc: DTN WG <dtn@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001f53b406151d53af"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn/D-zSx2rAJQcjtwuGeYqBYj7gTQU>
Subject: Re: [dtn] LTP CL for BP v7
X-BeenThere: dtn@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Delay Tolerant Networking \(DTN\) discussion list at the IETF." <dtn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtn>, <mailto:dtn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn/>
List-Post: <mailto:dtn@ietf.org>
List-Help: <mailto:dtn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtn>, <mailto:dtn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Apr 2024 13:45:57 -0000

I might say it differently: "The ION open source (going back probably to
the first version that supported BPv7, certainly in open-source-4.1.1)
implementation supports the use of LTP convergence layer adaptors whether
ION is configured to use BPv6 or BPv7.  The LTP blocks formed by the
adaptors may each contain one or more bundles (depending on the bundles'
sizes, reliability requirements, and the LTP CLA configuration).  Multiple
bundles to be sent reliably to the same destination client ID (e.g. LTP
Service Data Aggregation per section 7 of
https://public.ccsds.org/Pubs/734x1b1.pdf) may be accumulated into a single
red LTP block; if an unreliable bundle is sent, it will be the only bundle
in an unreliable (green) LTP block.  Whether using BPv6 or BPv7, ION
behaves the same way w.r.t. its implementation of the LTP CLA and LTP CL)."
 This might sound like it's not quite what section 7 of the CCSDS book
says, but I think that it is in fact conformant.  If using multiple 'red
bundles' (bundles that go into red blocks) then SDA is used and the bundles
can be concatenated into a single red LTP block.  When sending an
unreliable bundle, SDA is NOT used and the bundle goes into a single green
LTP block.

    --keith


On Tue, Apr 2, 2024 at 1:02 PM John Dowdell <john.dowdell.ietf@gmail.com>
wrote:

> Many thanks Scott and Keith.
>
> The LTPv2 dev team have kindly made the draft copy of the CCSDS spec
> available to me for comment but I’ll leave that to them to publish here if
> they want to.
>
> One last question, just to be sure: does the LTP CLA in the I-D and
> ION-DTN support BP v7 (RFC 9171), or just v6 (RFC 5050)?
>
> Many thanks
> John
>
> On 1 Apr 2024, at 20:44, Keith Scott <keithlscott@gmail.com> wrote:
>
>
> Scott pointed out to me that the CL definition and the CL*A* definition
> (how to carry bundles in the CL protocol) are different, so there might
> still be a small bit of un-spec'ed work.  And that I forgot to cc: the
> dtnwg (thx).... :o
>
>     --keith
>
> ---------- Forwarded message ---------
> From: Keith Scott <keithlscott@gmail.com>
> Date: Mon, Apr 1, 2024 at 8:28 PM
> Subject: Re: [dtn] LTP CL for BP v7
> To: <sburleig.sb@gmail.com>
>
>
> Though the CCSDS profile of the RFC5326-based LTP specification *is* a
> published spec (https://public.ccsds.org/Pubs/734x1b1.pdf) that should be
> suitable for contracting.
>
> I'll also point you at a docker container-based emulation environment here
> in case that's useful: https://github.com/keithlscott/opennetem. It comes
> with a test scenario that uses LTP convergence layers.
>
> The replacement for LTPCL is very much on CCSDS' todo list.  There's a
> draft available to CCSDS dtn working group members but I'm not sure if
> that's publicly available.  Let me see if that could be made available....
>
>     --keith
>
>
>
> On Mon, Apr 1, 2024 at 8:06 PM <sburleig.sb@gmail.com> wrote:
>
>> Hi, John.  A quick answer that can be discussed further if needed: the
>> LTP specification has not changed since RFC 5326, so that expired LTP CL
>> spec should still be usable for software development – though it’s not a
>> published standard that can be cited in a quote or bid, so you’re out of
>> luck if that’s needed.
>>
>>
>>
>> The successor to LTP, currently under development in CCSDS DTN WG, will
>> not be backward-compatible with LTP, and no CL specification for that
>> protocol exists yet anyway, so at this time it’s not an option.
>>
>>
>>
>> Scott
>>
>>
>>
>> *From:* dtn <dtn-bounces@ietf.org> *On Behalf Of *John Dowdell
>> *Sent:* Monday, April 1, 2024 9:34 AM
>> *To:* DTN WG <dtn@ietf.org>
>> *Subject:* [dtn] LTP CL for BP v7
>>
>>
>>
>> Dear all
>>
>>
>>
>> I have been looking for a published specification for LTP CL without
>> success. The only draft I can find is one from Scott that expired some
>> years back. I can see that ION-DTN has a LTP CL function but I’m not quite
>> sure how that works.
>>
>>
>>
>> I have a need to build a stack that includes at least LTP v1 and BP v7,
>> and hence the need for a working LTP CL. If the upcoming LTP v2 works with
>> that same CL, all well and good but I get the feeling that it won’t.
>>
>>
>>
>> Can someone help me out here please? LTP CL seems to be on nobody’s
>> current to-do list, neither IETF nor CCSDS, and I need something for the
>> project I’m working on (those of you who know me will know what this is).
>>
>>
>>
>> Many thanks
>>
>>
>>
>> John
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> dtn mailing list
>> dtn@ietf.org
>> https://www.ietf.org/mailman/listinfo/dtn
>>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>
>
> _______________________________________________
> dtn mailing list
> dtn@ietf.org
> https://www.ietf.org/mailman/listinfo/dtn
>