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

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Jun 2011 12:48:26 +0100

Right - but how is a reader of RFC 5326 supposed to know about
a CCSDS registry? I also don't think that its really correct
that someone interested in that RFC is expected to ask CCSDS
for a codepoint - that's not very Internet-like is it?

One thing we might do is add a client service ID IANA registry
that sets out a range to be managed by CCSDS? Not sure if that
would cross-the-streams too much or not but worth thinking
about if CCSDS felt it was too hard to register numbers in an
IANA registry.

I'm happy to write the short I-D that would do all that
and that'd update 5326 so folks could know about it all.

S.

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

---

From: "Scott, Keith L." <[email-masked]>
Date: Wed, 1 Jun 2011 09:01:06 -0400

OK, Stephen and I are going to write an LTP Registries I-D for LTP Client
Service IDs and LTP Engine IDs.  The I-D that establishes the registries
will designate some ranges of each as managed by CCSDS (I'm thinking like
~8-16 LTP Client Service IDs) and hopefully the first three bytes of LTP
Engine ID space (1--2**21-1).

For CCSDS we'll state in the SANA section of the LTP document that there
will be allocations coming from IANA for both LTP Client Service IDs and LTP
Engine IDs.  Whatever those allocations are, CCSDS can then manage them
internally.

		--keith

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Wednesday, June 01, 2011 7:48 AM
To: Scott, Keith L.
Cc: DTN interest; [email-masked]
Subject: Re: [Sis-dtn] Proposal to integrate LTPCL notions into base

S.

---

From: "Burleigh, Scott C (313B)" <[email-masked]>
Date: Fri, 3 Jun 2011 10:55:32 -0700

That sounds like the right solution to me.  Let me suggest that the IANA allocation for engine IDs echo the allocation of ipn-scheme node numbers that's in the CCSDS BP spec.  I know I haven't yet convinced everyone that using the same numeric value for both purposes will vastly simplify spacecraft operations, but for now let's at least avoid making it impossible or illegal to support that simplification in the event that its utility ever does become more clear.

Scott 

> From: [email-masked] [mailto:sis-dtn-
> [email-masked]] On Behalf Of Scott, Keith L.
> Sent: Wednesday, June 01, 2011 6:01 AM
> To: Stephen Farrell
> Cc: [email-masked]; DTN interest
> Subject: RE: [Sis-dtn] Proposal to integrate LTPCL notions into base LTP-
> for-CCSDS protocol specification
> 
> will be allocations coming from IANA for both LTP Client Service IDs and
> LTP Engine IDs.  Whatever those allocations are, CCSDS can then manage them
> internally.
> 
> 		--keith
> 
> Subject: Re: [Sis-dtn] Proposal to integrate LTPCL notions into base LTP-
> for-CCSDS protocol specification
> 
> 
> <http://cwe.ccsds.org/sis/docs/SIS-
> DTN/Draft%20Documents/Licklider%20Transmi
> http://cwe.ccsds.org/sis/docs/SIS-
> DTN/Draft%20Documents/Licklider%20Transmis