Subject: Re: [dtn] Forwarding Failed and Previous Node

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Mon, 2 Oct 2017 23:02:34 +0000

Hi, Lucas.  On your first point: the updating of bundle age is part of Step 4 of section 5.4, so it should certainly happen in this context.  We don't say explicitly at which point hop count is supposed to be updated, leaving this as an implementation matter, but I think the definition  of "hop" in 4.3.3 makes it clear that such an update is required in this case in order to preserve the correctness of the hop count.

On your second point: the text says that the bundle protocol agent MAY forward the bundle back to the node that sent it, not that it MUST or SHALL or even CAN.  If transmission to that node is possible only in the future, no problem; step 4 of 5.4 addresses that.  If transmission to that node is altogether impossible now and in the future then clearly no convergence layer adapters can effect the sending of the bundle to that node.  In that event, steps 4 and 5 of 5.4 are clearly moot and processing immediately proceeds to step 2 of 5.4.2; the bundle is simply deleted.  No route selection is performed because step 1 of 5.4.2 skips steps 1-3 of 5.4.  I think this is what the existing language says, but do you think we need to spell it out further?

Scott

-----Original Message-----
From: dtn [mailto:[email-masked]] On Behalf Of Lucas Kahlert
Sent: Sunday, September 24, 2017 5:00 AM
To: [email-masked]
Subject: Re: [dtn] Forwarding Failed and Previous Node

Hello again :)

The direct jump to step 4 and 5 of section 5.4 solves the issue with the loop. Another question: Should Bundle Age and Hop Count blocks nonetheless be processed? I think they should.

But there is another problem: The spec assumes in its current form that the bundle can directly send back to the previous node. But what if the bundle was received over a unidirectional link or the next contact with the previous node is in the future? This would require - again - a routing decision. How to handle this case?

Regards,
Lucas

On 18.09.2017 17:33, Burleigh, Scott C (312B) wrote:
> Wups, sorry, this is my proposed fix to your other email, "Re: Bundle Dispatching and Local Bundle Delivery".
> 
> For this email ("Forwarding Failed and Previous Node") I again agree that a fix is needed.  Here I would propose to add the following line to the end of Step 1 of section 5.4.2: "This forwarding SHALL be accomplished by performing Step 4 and Step 5 of section 5.4."
> 
> Scott
> ________________________________________
> From: dtn [[email-masked]] on behalf of Burleigh, Scott C (312B) 
> [[email-masked]]
> Sent: Monday, September 18, 2017 8:28 AM
> To: Lucas Kahlert; [email-masked]
> Subject: Re: [dtn] Forwarding Failed and Previous Node
> 
> Excellent catch, Lucas.  I think the fix for this is to insert the following language at the end of Step 1 of 5.3: "...and for the purposes of all subsequent processing of this bundle the node's membership in the bundle's destination endpoint SHALL be negated."  Good?
> 
> Scott
> ________________________________________
> From: dtn [[email-masked]] on behalf of Lucas Kahlert 
> [[email-masked]]
> Sent: Thursday, September 14, 2017 4:26 AM
> To: [email-masked]
> Subject: Re: [dtn] Forwarding Failed and Previous Node
> 
> Hi,
> 
> in section "5.4.2 Forwarding Failed" step 1 it is stated that the BPA 
> may forward the bundle back to the EID specified in the Previous Node Block.
> 
> A routing decision has to be made for this Previous Node Block EID but 
> the destination EID of the bundle is not changed. This means that the 
> routing component of the BPA has to consider a different EID then the 
> destination of a bundle.
> 
> In the BPbis flow chart [1] I had to introduce a special "$send_to"
> parameter for the "5.2 Bundle Transmission" which is quite confusing.
> 
> Another problem: if the forwarding to the previous node fails (which 
> means that "5.4.2 Forwarding Failed" is executed) we have a potential loop.
> 
> Maybe the specification should describe such a "Send back" mechanism 
> is more detail?
> 
> Regards,
> Lucas
> 
> [1]: https://upcn.eu/Bundle_Protocol.png
> 
> On 23.06.2017 00:34, Burleigh, Scott C (312B) wrote:
>> Hi.  I just posted an updated BPbis specification that I think 
>> addresses nearly all of the comments on which we reached consensus, 
>> either over email or at IETF 98.  The one exception I can think of is 
>> the request to add references to formal definitions for CRC-16-ANSI 
>> and CRC-32, which I omitted because on a quick search I wasn't able 
>> to find any; if anyone knows where those definitions live, please speak up.
>>
>> I think we may have two quite different approaches on the table for 
>> defining custody transfer outside of the BP specification.  I will be 
>> posting one of them in a few minutes and hope to post the other 
>> sometime tomorrow.
>>
>> Scott
>>
>>
>>
>> _______________________________________________
>> dtn mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dtn
>>
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
> 
> _______________________________________________
> dtn mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtn
> 

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