Subject: [dtn-interest] Fwd: Proposal to integrate LTPCL notions into base LTP-for-CCSDS protocol specification

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 May 2011 14:18:43 +0100

Forwarding for Keith from old mailing list.

S.

-------- Original Message --------
Subject: [dtn-interest] Proposal to integrate LTPCL notions into base
LTP-for-CCSDS protocol specification
Date: Mon, 23 May 2011 08:53:55 -0400
From: Scott, Keith L. <[email-masked]>
To: [email-masked]
<[email-masked]>
CC: [email-masked] <[email-masked]>

As many of you know, the Consultative Committee for Space Data Systems
(CCSDS) is in the process of standardizing a 'profile' of BP/LTP for use
with space missions.  One important aspect of such systems is that they can
exhibit extreme asymmetries in bandwidth.  LTP itself does a good job of
being able to support such environments; however, the overall overhead and
efficacy of the 'whole-stack' is dependent on the size of the upper-layer
PDUs (e.g. bundles) sent over LTP and how those upper-layer PDUs are
encapsulated in LTP blocks.  If one encapsulates a single bundle in (the red
part of) an LTP block, then lots of small bundles equates to 'lots of' LTP
acknowledgement traffic.

The LTP CL internet draft addresses this by specifying that multiple bundles
can be concatenated together into a single (red-part) LTP block.  This is
fine for BP, however there is desire in CCSDS to use LTP to support other
protocols besides just BP.  Instead of duplicating essentially the same
LTPCL capabilities repeatedly for each upper-layer protocol, there is a
desire to push this capability down into LTP.

The draft text below is proposed for inclusion in the 'LTP-for-CCSDS'
specification (link below
<http://cwe.ccsds.org/sis/docs/SIS-DTN/Draft%20Documents/Licklider%20Transmi
ssion%20Protocol/LTP%20for%20CCSDS%2020110215_post_CESGReview.docx> ).  This
would go in section 3 of the LTP-for-CCSDS document (regardless of its
numbering below).  Note that the 'LTP-for-CCSDS' document defines an
applique on top of RFC5326 and does NOT modify the LTP protocol or service
interface directly.  If there is enough interest, the dtnrg could certainly
bring the capability into a future version of the LTP RFC.  Note that this
is essentially the concept of the LTPCL translated into a 'standardized'
shim on top of LTP.

Do people have any objections to the text below?  Recommended changes?

Best Regards,

                                --keith

Link to LTP-for-CCSDS draft:
http://cwe.ccsds.org/sis/docs/SIS-DTN/Draft%20Documents/Licklider%20Transmis
sion%20Protocol/LTP%20for%20CCSDS%2020110215_post_CESGReview.docx

1.5         Aggregation of Layer-(N+1) PDUs

1.5.1        This section defines a mechanism whereby sending LTP clients
can aggregate multiple PDUs into a single LTP block.

NOTE   -    The sending side of this 'service' is implemented by the sending
LTP client; there is no separate LTP service at the sending side.

                   The receiving side of this service is implemented by an
LTP client performing the actions defined in this section.  When invoked,
this client sits as a shim between the receiving LTP engine and its other
clients and is transparent to the other clients.  No additional services
beyond those specified in section 4 of this document are presented by LTP.

                   It is expected (though not required) that senders that
aggregate multiple PDUs into a single LTP block will mark the entire block
as Red-Part (reliable) data.

1.5.2        A sending LTP client may aggregate multiple PDUs into a single
LTP block as follows:

1.5.2.1        The sending client must concatenate one or more complete PDUs
and must prepend an SDNV with the LTP client service identifier that would
otherwise have been used to identify the destination client service if a
single (non-aggregated) PDU were used.  No intervening bits are allowed
between concatenated PDUs, before the identifying SDNV, between the SDNV and
the first bit of the first concatenated PDU, or after the end of the last
concatenated PDU.  All PDUs concatenated together by the client be destined
for the same destination client service.

1.5.2.2        When submitting the resulting aggregate PDU to the LTP
service, the sending client must specify a destination client service ID of
2.

1.5.2.3        LTP client services whose PDUs cannot be extracted from an
aggregate of concatenated PDUs as described here must not have their PDUs
aggregated by the sender.

1.5.3        A receiving LTP engine that receives a block with destination
client service identifier 2 processes the block as follows:

1.5.3.1        On reception of a block with destination client service
identifier 2, the receiving LTP engine shall pass the aggregated block to
the 'disaggregation service' client.

NOTE   -    If a client for LTP client service 2 does not exist at the
receiver, the procedures of section 6.0 of RFC5326 are followed.

1.5.3.2        The disaggregation service client shall extract the
individual client service PDUs from the received block and shall pass each
one to the LTP client service identified by the SDNV at the beginning of the
block.  The mechanism for extracting individual PDUs from the aggregation is
an implementation matter.

1.5.3.3        If the disaggregation service cannot extract the individual
PDUs from the aggregate because it can not parse the syntax of the PDUs
identified by the destination client service identifier at the beginning of
the block, it must cancel the session following the procedures in section
6.0 of RFC5326.

---

From: <[email-masked]>
Date: Mon, 23 May 2011 15:02:32 +0100

> Note that this is essentially the concept of 
> the LTPCL translated into a 'standardized'
> shim on top of LTP.

Would that LTPCL turn out to be CFDP, by any chance?

---

From: "Scott, Keith L." <[email-masked]>
Date: Mon, 23 May 2011 10:06:02 -0400

I don't think so.  The LTP CL internet draft really just deals with how to
multiplex / aggregate multiple bundles into a single (red part of) an LTP
block so that the reliability traffic happens once for the block (which may
involve multiple interactions) rather than once per bundle.

		--keith

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Monday, May 23, 2011 4:03 PM
To: [email-masked]
Subject: Re: [dtn-interest] Fwd: Proposal to integrate LTPCL notions into
base LTP-for-CCSDS protocol specification

_______________________________________________
dtn-interest mailing list
[email-masked]
https://www.irtf.org/mailman/listinfo/dtn-interest