Re: [dtn] A cut at Custody Transfer

[Carlo Caini <[e-mail]>]

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.
>
>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.
>
>_______________________________________________
>dtn mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dtn