Subject: [dtn] A cut at Custody Transfer

From: Keith Scott <[email-masked]>
Date: Thu, 30 Mar 2017 16:31:13 -0400

Below is my first cut at what would need to be done to custody transfer to
make it work in conjunction with fragmentation, together with an example of
how I think it should work.  I think that what's below allows both custody
transfer and fragmentation to peacefully coexist, and I don't think there
are any issues with CT and security per se.  The cross-product of security
and fragmentation may still be an issue.

Comments welcome -- ESPECIALLY if anyone can provide details on the
discussion Tuesday night that resulted in the desire to move CT to another
document.

I favor inclusion of something like what's below into the CURRENT 5050bis,
as I think it would make implementing CT much easier than trying to meld
two documents (given 5050bis' procedural structure).

NOTE: The custody acceptance procedure in 5050bis-06 deletes all current
custodians when a new node takes custody (5.10.1).  I haven't run this to
ground yet, but does that square with a bundle possibly having multiple
current custodian blocks?  Not sure it matters much...?

In general the notion would be to logically merge what's below with the
existing CT text in 5050bis, whether it ends up part of 5050bis or
separate.  That is, what's below describes the changes from / additions to
what is currently in 5050bis to accommodate combinations of custody
transfer, fragmentation, and encryption.

Custody transfer as defined in 5050bis and here still only applies to
bundles with singleton EIDs (and identified as such in the bundle
processing control flags).

=============
Modifications
=============

Remove the restriction in 5050bis-06 section 5.8 that bundles with
custodians MUST NOT be fragmented.  The procedures below allow for
fragmenting bundles that contain current custodian blocks, whether or not
the receiving node takes custody of the bundle.

======

The 'Block must be replicated in every fragment' flag in the Block
Processing Control Flags of Current Custodian Blocks MUST be set to 1.

========================================
Management of Custody Signal Information
========================================
On receipt of a custody signal of type 0 (custody acceptance) or type 2
(custody delegation) a node SHOULD record the data contained in the custody
signal and associate it with all bundles currently stored at the current
node that meet all of the following criteria:
- The node previously accepted custody of the bundle;
- The stored bundle's source EID and sending timestamp match the source EID
and sending timestamp of the bundle identified in the custody signal;
- The stored bundle's payload range intersects the payload range in the
custody signal (as identified by the combination of the fragment offset and
payload fragment length) .  If such a range is not present in the custody
signal then the range of the signal MUST be assumed to coincide with the
entire orignal bundle payload range and this condition MUST be assumed to
be met.

If no bundles stored at the current node meet all of the criteria above,
then the information in the custody signal SHOULD be discarded.

For custody acceptance signals, the data recorded MUST include the range of
payload bytes for which custody acceptance has been asserted.

For custody delegation signals, the data recorded MUST include the range of
payload bytes for which custody delegation has been asserted together with
the next node to which the bundle will be forwarded and the estimate of the
interval that will elapse between when the bundle was received and the time
at which it will be forwarded.

It may be possible to merge received information with information already
associated with a particular bundle or fragment.  For example, if two
custody acceptance signals are received with overlapping but unique payload
ranges, they might be combined into a single entry referencing the union of
the ranges.

The information obtained from received custody signals associated with a
given bundle or fragment SHOULD be released when custody of that bundle or
fragment is released.

========================
Fragmentation Procedures
========================
When fragmenting a bundle for which the local node is the current
custodian, the local node MUST follow the procedures in [5050bis-06 section
5.8].  In addition, the local node SHOULD copy all data recorded from
received custody acceptance and custody delegation signals associated with
the bundle to those fragments whose ranges intersect the ranges in the
records.

Notes on the use of the data in received custody signals:
The ranges in received custody acceptance signals can be used to release
custody of those portions of stored bundles whose payload ranges are
completely covered by the custody transfer success signals.  The current
node could for example fragment a custodially-held  bundle so that the
fragment boundaries coincide with the boundaries of received custody
acceptance signals in order to release custody of those fragments.
Similarly, received custody delegation signals might be used by the current
custodian of a bundle to inform fragmentation of the bundle and revision of
the fragments' custody retransmission timeout values.

========================
Encapsulation Procedures
========================
If a node encapsulates a bundle that requests custody transfer in another
bundle without taking custody of it, the node SHOULD send a custody signal
of type 2 (custody delegation) to the current custodian of the bundle
listing the tunnel destination as the next hop to which the bundle will be
forwarded.

=====
NOTES
=====
The extent of a bundle's payload bytes is always determinable at any node
in the network.  Neither the fragment offset in the primary block (if
present) nor the length value of the payload block is affected by security
mechanisms [[BPSec ref]]

===========================================
Fragmentation with Custody Transfer Example
===========================================

Example: A node receives a non-fragmented bundle (or fragment) with a
1,000-byte payload extent, custody transfer requested, and a single current
custodian block.  The node does not take custody of the bundle, and
fragments the bundle before forwarding it.
- The current custodian block is is copied into each of the fragments per
the 'Block must be replicated in every fragment' flag.
- The custodian of the bundle may receive multiple custody transfer signals
referencing various payload ranges of the bundle.  Because these all
reference fragments of a single original bundle, each signal will reference
the same source EID and sending timestamp, and so the ranges of payload
bytes for which custody transfer success is asserted will be associated
with the custodially-held bundle at the custodian.

If the custodian receives custody acceptance signals covering the entire
received bundle payload extent before its custodial retransmission timer
expires, it releases custody of the bundle and discards all of the
accumulated custody signal information.

If the custodian receives some combination of custody acceptance signals
covering bytes 0--99 and 300-999 of the bundle and no custody delegation
signals before the bundle's custodial retransmission timer expires, the
node could:
- retransmit the entire bundle
- fragment the bundle, forming fragments with payload ranges 0--99,
100--299, and 300-999; assert successful custody transfer of the fragments
with payload ranges 0--99 and 300-999, releasing custody of those
fragments; retransmit the fragment with payload range 100--299.

---

From: Carlo Caini <[email-masked]>
Date: Fri, 31 Mar 2017 10:59:37 +0200

Dear Keith,
      After reading the proposed text and having found it very clear 
thanks also to the excellent example, I am definitively in favor of 
your proposal of including it in the current BP5050bis.
CT is in my opinion a fundamental feature, and not an ancillary one, 
of DTN, and it is strongly interlaced with a lot (the majority?) of 
other procedures. This because the concept of custody is 
intrinsically and logically linked with all aspects of bundle 
processing. To recognize it, it is enough to carry out a search of 
the "custody" word in the current document version.
Although to write a separate document  is possible, the logical merge 
would be hard for experts and likely beyond the capabilities of 
normal readers, for whom RFCs should be intended.
Maybe there are other peculiar cases, not covered yet. I would kindly 
invite who has already discovered them to make the mailing list know, 
to see if they can be timely and effectively tackled, as in this case.
Yours,
    Carlo

At 22:31 30/03/2017, Keith Scott wrote:
>Below is my first cut at what would need to be done to custody 
>transfer to make it work in conjunction with fragmentation, together 
>with an example of how I think it should work.  I think that what's 
>below allows both custody transfer and fragmentation to peacefully 
>coexist, and I don't think there are any issues with CT and security 
>per se.  The cross-product of security and fragmentation may still be an issue.
>
>discussion Tuesday night that resulted in the desire to move CT to 
>another document.
>
>I favor inclusion of something like what's below into the CURRENT 
>5050bis, as I think it would make implementing CT much easier than 
>trying to meld two documents (given 5050bis' procedural structure).
>
>
>
>
>NOTE: The custody acceptance procedure in 5050bis-06 deletes all 
>current custodians when a new node takes custody (5.10.1).  I 
>haven't run this to ground yet, but does that square with a bundle 
>possibly having multiple current custodian blocks?  Not sure it 
>matters much...?
>
>
>
>In general the notion would be to logically merge what's below with 
>the existing CT text in 5050bis, whether it ends up part of 5050bis 
>or separate.  That is, what's below describes the changes from / 
>additions to what is currently in 5050bis to accommodate 
>combinations of custody transfer, fragmentation, and encryption.
>
>Custody transfer as defined in 5050bis and here still only applies 
>to bundles with singleton EIDs (and identified as such in the bundle 
>fragmenting bundles that contain current custodian blocks, whether 
>or not the receiving node takes custody of the bundle.
>
>======
>
>On receipt of a custody signal of type 0 (custody acceptance) or 
>type 2 (custody delegation) a node SHOULD record the data contained 
>in the custody signal and associate it with all bundles currently 
>stored at the current node that meet all of the following criteria:
>- The stored bundle's source EID and sending timestamp match the 
>source EID and sending timestamp of the bundle identified in the 
>custody signal;
>- The stored bundle's payload range intersects the payload range in 
>the custody signal (as identified by the combination of the fragment 
>offset and payload fragment length) .  If such a range is not 
>present in the custody signal then the range of the signal MUST be 
>assumed to coincide with the entire orignal bundle payload range and 
>this condition MUST be assumed to be met.
>
>If no bundles stored at the current node meet all of the criteria 
>above, then the information in the custody signal SHOULD be discarded.
>
>For custody acceptance signals, the data recorded MUST include the 
>range of payload bytes for which custody acceptance has been asserted.
>
>For custody delegation signals, the data recorded MUST include the 
>range of payload bytes for which custody delegation has been 
>asserted together with the next node to which the bundle will be 
>forwarded and the estimate of the interval that will elapse between 
>when the bundle was received and the time at which it will be forwarded.
>
>It may be possible to merge received information with information 
>already associated with a particular bundle or fragment.  For 
>example, if two custody acceptance signals are received with 
>overlapping but unique payload ranges, they might be combined into a 
>single entry referencing the union of the ranges.
>
>The information obtained from received custody signals associated 
>with a given bundle or fragment SHOULD be released when custody of 
>that bundle or fragment is released.
>
>
>========================
>Fragmentation Procedures
>========================
>custodian, the local node MUST follow the procedures in [5050bis-06 
>section 5.8].  In addition, the local node SHOULD copy all data 
>recorded from received custody acceptance and custody delegation 
>signals associated with the bundle to those fragments whose ranges 
>intersect the ranges in the records.
>
>The ranges in received custody acceptance signals can be used to 
>release custody of those portions of stored bundles whose payload 
>ranges are completely covered by the custody transfer success 
>signals.  The current node could for example fragment a 
>custodially-held  bundle so that the fragment boundaries coincide 
>with the boundaries of received custody acceptance signals in order 
>to release custody of those fragments.  Similarly, received custody 
>delegation signals might be used by the current custodian of a 
>bundle to inform fragmentation of the bundle and revision of the 
>fragments' custody retransmission timeout values.
>
>
>========================
>Encapsulation Procedures
>========================
>If a node encapsulates a bundle that requests custody transfer in 
>another bundle without taking custody of it, the node SHOULD send a 
>custody signal of type 2 (custody delegation) to the current 
>custodian of the bundle listing the tunnel destination as the next 
>hop to which the bundle will be forwarded.
>
>
>=====
>NOTES
>=====
>The extent of a bundle's payload bytes is always determinable at any 
>node in the network.  Neither the fragment offset in the primary 
>block (if present) nor the length value of the payload block is 
>affected by security mechanisms [[BPSec ref]]
>
>
>Example: A node receives a non-fragmented bundle (or fragment) with 
>a 1,000-byte payload extent, custody transfer requested, and a 
>single current custodian block.  The node does not take custody of 
>the bundle, and fragments the bundle before forwarding it.
>- The current custodian block is is copied into each of the 
>fragments per the 'Block must be replicated in every fragment' flag.
>- The custodian of the bundle may receive multiple custody transfer 
>signals referencing various payload ranges of the bundle.  Because 
>these all reference fragments of a single original bundle, each 
>signal will reference the same source EID and sending timestamp, and 
>so the ranges of payload bytes for which custody transfer success is 
>asserted will be associated with the custodially-held bundle at the custodian.
>
>If the custodian receives custody acceptance signals covering the 
>entire received bundle payload extent before its custodial 
>retransmission timer expires, it releases custody of the bundle and 
>discards all of the accumulated custody signal information.
>
>If the custodian receives some combination of custody acceptance 
>signals covering bytes 0--99 and 300-999 of the bundle and no 
>custody delegation signals before the bundle's custodial 
>retransmission timer expires, the node could:
>100--299, and 300-999; assert successful custody transfer of the 
>fragments with payload ranges 0--99 and 300-999, releasing custody 
>of those fragments; retransmit the fragment with payload range 100--299.
>
>_______________________________________________
>dtn mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dtn

---

From: <[email-masked]>
Date: Fri, 31 Mar 2017 11:48:12 +0000

Hello Keith,

I also concur with Carlo that CT specification should be part of the overall BP specification. Keeping the two separated does not seem to me to bring any special advantages in understanding and then implementing the specs. On the contrary having a single one would help to have a self-contained specification, with all major features in (as CT is in my view).

Concerning the text you proposed, I'll try to give you some more specific feedback (if I spot anything critical) within the next week,

Regards,

Tomaso

------------------------ 
Deutsches Zentrum für Luft- und Raumfahrt (DLR) 
German Aerospace Center 
Institute of Communications and Navigation | Satellite Networks | Oberpfaffenhofen | 82234 Wessling | Germany 
Tomaso de Cola, Ph.D. 
Telefon +49 8153 28-2156 | Telefax  +49 8153 28-2844 | [email-masked] 
http://www.dlr.de/kn/institut/abteilungen/san 

> -----Original Message-----
> From: dtn [mailto:[email-masked]] On Behalf Of Carlo Caini
> Sent: Friday, March 31, 2017 11:00 AM
> To: Keith Scott; [email-masked]
> Subject: Re: [dtn] A cut at Custody Transfer
> 
> Dear Keith,
>       After reading the proposed text and having found it very clear thanks also
> to the excellent example, I am definitively in favor of your proposal of
> including it in the current BP5050bis.
> CT is in my opinion a fundamental feature, and not an ancillary one, of DTN,
> and it is strongly interlaced with a lot (the majority?) of other procedures.
> This because the concept of custody is intrinsically and logically linked with all
> aspects of bundle processing. To recognize it, it is enough to carry out a
> search of the "custody" word in the current document version.
> Although to write a separate document  is possible, the logical merge would
> be hard for experts and likely beyond the capabilities of normal readers, for
> whom RFCs should be intended.
> Maybe there are other peculiar cases, not covered yet. I would kindly invite
> who has already discovered them to make the mailing list know, to see if
> they can be timely and effectively tackled, as in this case.
> Yours,
>     Carlo
> 
> 
> 
> >Below is my first cut at what would need to be done to custody transfer
> >to make it work in conjunction with fragmentation, together with an
> >example of how I think it should work.  I think that what's below
> >allows both custody transfer and fragmentation to peacefully coexist,
> >and I don't think there are any issues with CT and security per se.
> >The cross-product of security and fragmentation may still be an issue.
> >
> >current custodians when a new node takes custody (5.10.1).  I haven't
> >run this to ground yet, but does that square with a bundle possibly
> >having multiple current custodian blocks?  Not sure it matters much...?
> >
> >
> >

---

From: Keith Scott <[email-masked]>
Date: Fri, 31 Mar 2017 08:28:50 -0400

Carlo,

thanks.

Yes, I'm very interested in counterexamples that would cause the proposed
method to fail.

One complication is what to do with multiple custody deferral signals from
different nodes, and how to actually USE that information at the current
custodian.  The information in the various deferral signals could be
contradictory (e.g. if a custodial bundle is forwarded through multiple
nodes that don't take custody).  I think that's saved by the fact that how
the current custodian uses any of the custody deferral information is
implementation-specific.

    --keith

On Fri, Mar 31, 2017 at 4:59 AM, Carlo Caini <[email-masked]> wrote:

> Dear Keith,
>      After reading the proposed text and having found it very clear thanks
> also to the excellent example, I am definitively in favor of your proposal
> of including it in the current BP5050bis.
> CT is in my opinion a fundamental feature, and not an ancillary one, of
> DTN, and it is strongly interlaced with a lot (the majority?) of other
> procedures. This because the concept of custody is intrinsically and
> logically linked with all aspects of bundle processing. To recognize it, it
> is enough to carry out a search of the "custody" word in the current
> document version.
> would be hard for experts and likely beyond the capabilities of normal
> readers, for whom RFCs should be intended.
> invite who has already discovered them to make the mailing list know, to
> see if they can be timely and effectively tackled, as in this case.
> Yours,
>    Carlo
>
>
>
>
>> to make it work in conjunction with fragmentation, together with an example
>> of how I think it should work.  I think that what's below allows both
>> custody transfer and fragmentation to peacefully coexist, and I don't think
>> there are any issues with CT and security per se.  The cross-product of
>> security and fragmentation may still be an issue.
>>
>> 5050bis, as I think it would make implementing CT much easier than trying
>> to meld two documents (given 5050bis' procedural structure).
>>
>>
>>
>>
>> - The stored bundle's source EID and sending timestamp match the source
>> EID and sending timestamp of the bundle identified in the custody signal;
>> For custody acceptance signals, the data recorded MUST include the range
>> of payload bytes for which custody acceptance has been asserted.
>>
>> For custody delegation signals, the data recorded MUST include the range
>> of payload bytes for which custody delegation has been asserted together
>> with the next node to which the bundle will be forwarded and the estimate
>> of the interval that will elapse between when the bundle was received and
>> the time at which it will be forwarded.
>>
>> signals referencing various payload ranges of the bundle.  Because these
>> all reference fragments of a single original bundle, each signal will
>> reference the same source EID and sending timestamp, and so the ranges of
>> payload bytes for which custody transfer success is asserted will be
>> associated with the custodially-held bundle at the custodian.
>>