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

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Mon, 23 May 2011 16:47:25 -0700

Hi, Keith.  I think pushing this generalized service data aggregation functionality into the CCSDS LTP specification is the right idea, but I don't think this specific text is the right way to do it.

What we are talking about here is a standardized LTP "client service" that is defined inside the LTP specification volume but is not a part of the LTP protocol.  (It can't be, because RFC 5326 defines the LTP protocol and it doesn't say anything about this aggregation function.)  Which is kind of a weird concept in a way, but for which we actually have got ample precedent in CCSDS standards documents: section 6 of the CFDP specification defines six standard CFDP "User Operations" (such as Remote Status Report) that utilize CFDP but are not part of it, and section 6 of the AMS specification defines a standard AMS "User Operation" (AMS Proxy) that utilizes AMS but is not part of it.

I think the best way to add generalized service data aggregation to the CCSDS LTP spec would be to follow the same model, adding a separate section that explicitly identifies this capability as a standard LTP "Client Operation" that utilizes LTP but is not part of it.  In addition, I think that section needs to include all the logic that was worked out for the LTPCL Internet Draft, rather than just the red-part aggregation rules.  I'm attaching a first cut at the text for such an LTP "Client Operations" section, if that helps.

Scott

From: [email-masked] [mailto:[email-masked]] On Behalf Of Scott, Keith L.
Sent: Monday, May 23, 2011 5:54 AM
To: [email-masked]
Cc: [email-masked]
Subject: [Sis-dtn] Proposal to integrate LTPCL notions into base LTP-for-CCSDS protocol specification

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%20Transmission%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%20Transmission%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: Stephen Farrell <[email-masked]>
Date: Sat, 28 May 2011 18:38:53 +0100

Hi Keith,

(Sorry for the slow response)

I think this shows a need for yet another IANA registry for
LTP client service IDs. (Its a pity we didn't spot that
earlier;-)

I also think that both this scheme and the similar scheme in
the LTPCL should be defined so as to work sensibly together,
which may require a bit of analysis.

I don't think that that it makes much sense to do this
stuff spread out between both DTNRG and CCSDS so
maybe best would be to get relevant folks on a call to
thrash it out or even better meet up to discuss it. (If
DTNRG meets in Quebec would that be a good venue?)

Cheers,
S.

On 23/05/11 13:53, Scott, Keith L. wrote:
> 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.
> 
> 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.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.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.
> 
>  
> 
>  
> 
>  
> 
> 
> 
> 
> 
> _______________________________________________
> Sis-dtn mailing list
> [email-masked]
> http://mailman.ccsds.org/cgi-bin/mailman/listinfo/sis-dtn

---

From: "Scott, Keith L." <[email-masked]>
Date: Tue, 31 May 2011 21:23:37 -0400

There actually now *IS* a candidate (not yet approved) CCSDS registry that
we can populate with known LTP client service IDs
(http://sanaregistry.org/c/ltp_serviceid/ltp_serviceid.html), at least for
space missions.

I can't make it to Quebec, but I'll put out a Doodle poll to see if I can
get a quorum of interested parties.  I think there's an opportunity for
synergy with the LTPCL, but (I think) a motivator for the CCSDS interest is
now the possibility of using LTP as the base reliability mechanism for
things other than bundles.

		--keith

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Saturday, May 28, 2011 1:39 PM
To: Scott, Keith L.
Cc: DTN interest; [email-masked]
Subject: Re: [Sis-dtn] Proposal to integrate LTPCL notions into base
LTP-for-CCSDS protocol specification

Hi Keith,

Cheers,
S.

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

---

From: "Scott, Keith L." <[email-masked]>
Date: Tue, 31 May 2011 21:30:36 -0400

As promised, a link to a Doodle Poll.  Please respond even if your
availability for the proposed times is uniformly negative so I can get an
idea of the interested parties.

http://www.doodle.com/pp6y7dh8cp5iixei

		--keith

-----Original Message-----
From: Scott, Keith L. 
Sent: Tuesday, May 31, 2011 9:24 PM
To: 'Stephen Farrell'
Cc: DTN interest; [email-masked]
Subject: RE: [Sis-dtn] Proposal to integrate LTPCL notions into base

		--keith

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Saturday, May 28, 2011 1:39 PM
To: Scott, Keith L.
Cc: DTN interest; [email-masked]
Subject: Re: [Sis-dtn] Proposal to integrate LTPCL notions into base

Hi Keith,

Cheers,
S.

single