Subject: [dtn-interest] Progressing draft-irtf-bundle-encapsulation

From: Elwyn Davies <[email-masked]>
Date: Mon, 25 Jul 2011 20:42:11 +0100

Hi, Susan

Joerg asked if there was anybody able to help with progressing the 
bundle-in-bundle encapsulation draft, and I was moved to put my head 
above the parapet.  So if I can help I will try to do so.

I just had a quick read of the draft and there are a couple of process 
issues that we need to sort out and I spotted some technical issues that 
I would like to think about some more.

On the process front:
- The draft is normatively dependent on draft-irtf-dtnrg-bundle-divert.  
Joerg didn't mention progressing this draft in the meeting, but clearly  
either the capability in the diversion draft will have to be 
incorporated into the encapsulation draft or the divert draft has to be 
progressed in parallel - this doesn't look terribly controversial.
- The draft is nominally normatively dependent on 'draft-dtnrg-bundle-mm
ulticast-custodial-06'.  However after a bit of research, it appears 
that this draft never became a DTN RG item and I assume the draft 
referred to should be 
http://tools.ietf.org/html/draft-symington-dtnrg-bundle-multicast-custodial-06.  
In fact this draft is only used as an illustrative use case, so it 
needn't be normative.  The question is whether we want to progress this 
draft. Alternatively, the use case could be removed from the draft.

On the technical front, I think some further thinking about custody is 
required. - If you encapsulate a mixture of bundles, some asking for 
custody transfer and others not, what happens if you have to retransmit 
the bundle?  Indeed I am not sure what happens if the encapsulating node 
is not able to take custody.

Regards,
Elwyn

---

From: "Symington, Susan F." <[email-masked]>
Date: Tue, 26 Jul 2011 16:20:23 -0400

Elwyn,
Whatever moved you to put your head above the parapet?? ;)

1. It makes sense to me that the "divert" draft needs to go hand in hand with the encapsulation draft.

2. As far as I can tell, no one besides me has paid much attention to the custodial multicast draft. Therefore, it would probably be a lot easier to remove the use case that refers to custodial multicast from the encapsulation draft than progress the custodial multicast draft.  Joerg tells us that the IBR people have been implementing encapsulation for some of their CBIS work and have included encapsulation in their latest release, so you should be able to describe a use case based on their use of it. According to Joerg:

"We are using their code for some of our CBIS work.  Among this, one
simple and generic way to differentiate different security levels of
bundles is to have them in different "sub-bundles" within the same
bundle.  This would allow easily discarding parts when forwarding to,
e.g., a red node from a black one (independent of other security
mechanisms in place).

We currently just use this as a proof of concept for our
local policy mechanisms."

3. Yes, encapsulation by nature hides what's going on in the inner bundle. It has been a long time since I thought about this, but I remember it being very interesting at the time.  If the encapsulating node can't take custody then I don't think anything breaks, it's just that the node that does have custody can't get notified that another node has taken custody until the bundle emerges from the other end of the tunnel. If the encapsulating bundle is dropped, the only way the node that has custody can find out is when the retransmission timer times out.  At least that's my best recollection.  I agree that it could not hurt to spend more time thinking about custody. It might be nice to have an extension header that tells you about the custody status of the encapsulated bundles. Could get complicated though. Just brainstorming there.

-susan

>-----Original Message-----
>From: Elwyn Davies [mailto:[email-masked]]
>Sent: Monday, July 25, 2011 3:42 PM
>To: Symington, Susan F.
>Cc: Joerg Ott; DTN-interest; Ivancic, William D. (GRC-RHN0)
>Subject: Progressing draft-irtf-bundle-encapsulation
>
>Hi, Susan
>