Subject: Re: Process question: Re: [dtn-interest] an Internet Draft for CBHE
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Date: Sat, 30 Dec 2006 07:51:24 -0800
List-Id: Delay Tolerant Networking Interest List <dtn-interest.mailman.dtnrg.org>

Stephen Farrell wrote:
> 
> Hi Wes,
> 
> Wesley Eddy wrote:
>> On Fri, Dec 29, 2006 at 10:44:41AM -0800, Fall, Kevin wrote:
>>> Some time ago I posted a message to dtn-interest pointing out the
>>> existence of IETF's SIGCOMP protocol.  What's interesting/surprising is
>>> that this stuff has a language and a sort of active networks paradigm
>>> (you download code to do the compression).
>>>
>>> See here:
>>>
>>> http://www.opensigcomp.org/
>>>
>>> I'd like to understand the tradeoffs between using this sort of system
>>> and the other options...
>>>
>>
>> Me too.  Maybe the CBHE draft should start as an individual-submission
>> (non-RG draft) for a few months while the group considers whether there
>> might be value in a more general scheme similar to (or based on)
>> SIGCOMP, pushing off the decision on whether or not to adopt it as an RG
>> item until later.  
> 
> Well, process-wise I guess there's no problem with an RG exploring
> two or more ways to do things, so we could have two different drafts
> on the go at once. (In fact, as an RG and not an IETF WG, that's
> perhaps a good approach.) Sure, we don't want 100 drafts on the
> same thing, but 2 or so reasonable alternatives seems ok for
> optional things like compression.

I think that's a very good approach; let's handle it that way.

> As to the SIGCOMP stuff - is someone willing to take on writing
> up an I-D? It does look interesting, though I'd be surprised if
> space folks were keen on uploading bytecode, so maybe sigcomp is
> more appropriate for other use cases?
> 
>> (I noticed the proposed document was draft-irtf-* and
>> not draft-lastname-* and wondered if that was a typo.)
> 
> I thought that that was just Scott being noncommittal:-)

Actually that was just me being clueless about the applicable convention and taking a wild stab.

>> I'm personally in favor of the CBHE work, assuming no alternatives are
>> proposed that are comparably simple and effective.
> 
> Alternatives here may be good. And we'll want alternatives when
> we get routing drafts on the go, so I think we'd be wrong to limit
> ourselves to one draft per topic as a general rule.

I agree.

Scott

Date: Sat, 30 Dec 2006 13:22:48 +0000
From: Stephen Farrell <[email-masked]>
To: [email-masked]
CC: DTN <[email-masked]>
Subject: Re: Process question: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Hi Wes,

Wesley Eddy wrote:
> On Fri, Dec 29, 2006 at 10:44:41AM -0800, Fall, Kevin wrote:
>> Some time ago I posted a message to dtn-interest pointing out the
>> existence of IETF's SIGCOMP protocol.  What's interesting/surprising is
>> that this stuff has a language and a sort of active networks paradigm
>> (you download code to do the compression).
>>
>> See here:
>>
>> http://www.opensigcomp.org/
>>
>> I'd like to understand the tradeoffs between using this sort of system
>> and the other options...
>>
> 
> Me too.  Maybe the CBHE draft should start as an individual-submission
> (non-RG draft) for a few months while the group considers whether there
> might be value in a more general scheme similar to (or based on)
> SIGCOMP, pushing off the decision on whether or not to adopt it as an RG
> item until later.  

Well, process-wise I guess there's no problem with an RG exploring
two or more ways to do things, so we could have two different drafts
on the go at once. (In fact, as an RG and not an IETF WG, that's
perhaps a good approach.) Sure, we don't want 100 drafts on the
same thing, but 2 or so reasonable alternatives seems ok for
optional things like compression.

As to the SIGCOMP stuff - is someone willing to take on writing
up an I-D? It does look interesting, though I'd be surprised if
space folks were keen on uploading bytecode, so maybe sigcomp is
more appropriate for other use cases?

> (I noticed the proposed document was draft-irtf-* and
> not draft-lastname-* and wondered if that was a typo.)

I thought that that was just Scott being noncommittal:-)

> I'm personally in favor of the CBHE work, assuming no alternatives are
> proposed that are comparably simple and effective.

Alternatives here may be good. And we'll want alternatives when
we get routing drafts on the go, so I think we'd be wrong to limit
ourselves to one draft per topic as a general rule.

S.

Date: Fri, 29 Dec 2006 22:03:01 -0500
From: Wesley Eddy <[email-masked]>
To: "Fall, Kevin" <[email-masked]>
Cc: [email-masked], Stephen Farrell <[email-masked]>, [email-masked], DTN <[email-masked]>
Subject: Re: Process question: Re: [dtn-interest] an Internet Draft for CBHE
Reply-To: [email-masked]
Sender: [email-masked]

On Fri, Dec 29, 2006 at 10:44:41AM -0800, Fall, Kevin wrote:
> Some time ago I posted a message to dtn-interest pointing out the
> existence of IETF's SIGCOMP protocol.  What's interesting/surprising is
> that this stuff has a language and a sort of active networks paradigm
> (you download code to do the compression).
> 
> See here:
> 
> http://www.opensigcomp.org/
> 
> I'd like to understand the tradeoffs between using this sort of system
> and the other options...
> 

Me too.  Maybe the CBHE draft should start as an individual-submission
(non-RG draft) for a few months while the group considers whether there
might be value in a more general scheme similar to (or based on)
SIGCOMP, pushing off the decision on whether or not to adopt it as an RG
item until later.  (I noticed the proposed document was draft-irtf-* and
not draft-lastname-* and wondered if that was a typo.)

I'm personally in favor of the CBHE work, assuming no alternatives are
proposed that are comparably simple and effective.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Date: Fri, 29 Dec 2006 17:25:07 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Stephen Farrell wrote:
> Scott Burleigh wrote:
>> So the value of dictionary length in the primary block unambiguously 
>> distinguishes CBHE-encoded bundles from non-CBHE-encoded bundles.
> Ok, that's good. So my follow-up question is whether, for future
> proofing, we'd be wiser to have a specific flag (or even version)
> in the CBHE-encoded bundle as an indicator that CBHE was applied?
>
> Potential reason: in some future spec someone figures out some
> sort of session layer over bundles and then wants to omit the
> repeated dictionary fields - a zero-length dictionary indicating
> "same as last time". Note - I'm not suggesting doing this, just
> wondering if we'd be better future-proofing CBHE against this
> kind of thing.
Technically, I think this would have to be done in another 
convergence-layer adaptation underneath Bundle Protocol rather than in a 
session-layer adaptation above it (since bundles themselves are in 
theory not exposed to protocols above BP).  But your point is well taken 
anyway: there might be some alternative non-CBHE bundle compression 
approach in the future that would like to use dictionary length zero for 
its own purposes.

I think a reasonable way to approach this would be to say that it's 
purely a convergence-layer matter and we can safely leave it to be 
sorted out in the future.  That's because one of the constraints on the 
use of CBHE and (I would expect) likewise on the use of any other 
convergence-layer compression system would be that you can only apply 
your compression method when you know that the receiving 
convergence-layer adapter is expecting bundles that are compressed using 
your method, if in fact they are compressed at all.  (The mechanism by 
which you know this is a problem for the CL protocol designer to work out.)

That is, each CL adapter is designed (or perhaps configured) to 
interpret dictionary length of zero as a signal that the bundle is to be 
decompressed in one specific way, and there's no clash because nodes 
never send bundles that are compressed in different ways to the same CL 
adapter -- just as machines never send both Ethernet and PPP frames to 
the same network interface card.  A modest amount of initial 
configuration keeps everything organized.

An alternative would be to add some sort of compression method ID to the 
primary block of the header and register new IDs as new methods are 
developed.  I'm unenthusiastic, though: we'd be adding a field to the 
bundle header that is of no value to the bundle protocol.  If anything, 
it seems as if this is the sort of thing that ought to go into a 
"meta-CL" shim layer between BP and CL, but I'm not wild about that 
either; I think this level of runtime adaptation would be overkill in 
the real world.  Leaving it as a configuration matter still makes more 
sense to me.

Scott

Date: Fri, 29 Dec 2006 23:43:34 +0000
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Scott Burleigh wrote:
> So the value of dictionary length in the primary block unambiguously 
> distinguishes CBHE-encoded bundles from non-CBHE-encoded bundles.

Ok, that's good. So my follow-up question is whether, for future
proofing, we'd be wiser to have a specific flag (or even version)
in the CBHE-encoded bundle as an indicator that CBHE was applied?

Potential reason: in some future spec someone figures out some
sort of session layer over bundles and then wants to omit the
repeated dictionary fields - a zero-length dictionary indicating
"same as last time". Note - I'm not suggesting doing this, just
wondering if we'd be better future-proofing CBHE against this
kind of thing.

S.

Date: Fri, 29 Dec 2006 14:57:08 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------040707000804070805090005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stephen Farrell wrote:
> Scott Burleigh wrote:
>> So I'm thinking that there is no point in the CBHE decode process at 
>> which the CBHE bundle decoding will fail, because you never start 
>> that decode process at all.  But I suspect you are actually asking 
>> about something different and I don't yet understand what....
> Ok. Forget for now what goes in this, or later versions of the draft,
> and I'll try another form of the question:
>
> Can a CBHE encoded bundle ever be successfully decoded by a non-CBHE
> aware bundle agent,
I can't think of any way that it could be.  When you say "decoded" here 
I think you actually mean "parsed (and potentially forwarded and/or 
delivered)", since a non-CBHE aware bundle agent wouldn't even know that 
there was any decoding to do.  It would just try to parse the bundle in 
the same way that it parses any normal (non-CBHE-compressed) bundle that 
it receives, and that parsing would fail due to the absence of a dictionary.
> or, is there any way to construct a set of octets
> that is a valid CBHE-encoded bundle but which is also the valid
> encoding of a (different) non CBHE-encoded bundle?
I don't think so.  Every valid CBHE-encoded bundle will have dictionary 
length equal to zero.  Every valid non-CBHE-encoded bundle with have 
dictionary length greater than zero because:

1.    (section 4.2, step 2 of BP spec) 'The source endpoint ID of the 
bundle must be either the ID of an endpoint of which the node is a 
member or else the null endpoint ID "dtn:none"'.

2.    Each EID must be a URI, and a valid URI must contain a scheme name 
of 1 or more characters, so the source endpoint ID of the bundle must 
contain at least a scheme name of 1 or more characters.

3.   In a valid non-CBHE-encoded bundle, all scheme names in all EIDs in 
the primary block appear in the dictionary, so the dictionary cannot be 
of length zero.

So the value of dictionary length in the primary block unambiguously 
distinguishes CBHE-encoded bundles from non-CBHE-encoded bundles.

Scott

--------------040707000804070805090005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stephen Farrell wrote:
<blockquote cite="[email-masked]" type="cite">Scott
Burleigh wrote:<br>
  <blockquote type="cite">So I'm thinking that there is no point in the
CBHE decode process at which the CBHE bundle decoding will fail,
because you never start that decode process at all.&nbsp; But I suspect you
are actually asking about something different and I don't yet
understand what....
    <br>
  </blockquote>
Ok. Forget for now what goes in this, or later versions of the draft,
  <br>
and I'll try another form of the question:
  <br>
  <br>
Can a CBHE encoded bundle ever be successfully decoded by a non-CBHE
  <br>
aware bundle agent,</blockquote>
I can't think of any way that it could be.&nbsp; When you say "decoded" here
I think you actually mean "parsed (and potentially forwarded and/or
delivered)", since a non-CBHE aware bundle agent wouldn't even know
that there was any decoding to do.&nbsp; It would just try to parse the
bundle in the same way that it parses any normal (non-CBHE-compressed)
bundle that it receives, and that parsing would fail due to the absence
of a dictionary.<br>
<blockquote cite="[email-masked]" type="cite">or, is
there any way to construct a set of octets
  <br>
that is a valid CBHE-encoded bundle but which is also the valid
  <br>
encoding of a (different) non CBHE-encoded bundle?</blockquote>
I don't think so.&nbsp; Every valid CBHE-encoded bundle will have dictionary
length equal to zero.&nbsp; Every valid non-CBHE-encoded bundle with have
dictionary length greater than zero because:<br>
<br>
1.&nbsp;&nbsp;&nbsp; (section 4.2, step 2 of BP spec) '<span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">The source
endpoint ID of the bundle must be
either the ID of an endpoint of which the node is a member or else the
null
endpoint ID "dtn:none"'.<br>
<br>
2.&nbsp;&nbsp;&nbsp; </span><span
 style="font-size: 12pt; font-family: &quot;Times New Roman&quot;;">Each EID must
be a URI, and a valid URI must contain a scheme name of 1 or more
characters, so the source endpoint ID of the bundle must contain at
least a scheme name of 1 or more characters.<br>
<br>
3.&nbsp;&nbsp; In a valid non-CBHE-encoded bundle, all scheme names in all EIDs
in the primary block appear in the dictionary, so the dictionary cannot
be of length zero.<br>
<br>
So the value of dictionary length in the primary block unambiguously
distinguishes CBHE-encoded bundles from non-CBHE-encoded bundles.<br>
<br>
Scott<br>
</span>
</body>
</html>

--------------040707000804070805090005--

Date: Fri, 29 Dec 2006 22:18:53 +0000
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Scott Burleigh wrote:

> So I'm thinking that there is no point in the CBHE decode process at 
> which the CBHE bundle decoding will fail, because you never start that 
> decode process at all.  But I suspect you are actually asking about 
> something different and I don't yet understand what....

Ok. Forget for now what goes in this, or later versions of the draft,
and I'll try another form of the question:

Can a CBHE encoded bundle ever be successfully decoded by a non-CBHE
aware bundle agent, or, is there any way to construct a set of octets
that is a valid CBHE-encoded bundle but which is also the valid
encoding of a (different) non CBHE-encoded bundle?

S.

Date: Fri, 29 Dec 2006 12:34:42 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Stephen Farrell wrote:
> Scott Burleigh wrote:
>> I dunno, Stephen, it seemed to be fairly time-consuming and 
>> labor-intensive to get a well-known port number assigned to LTP or to 
>> register the "dtn" URI scheme.  The only way we can be headed for 
>> collisions is if a user community for CBHE comes into being on a 
>> common network (let's say the new BundleBone) and not all members of 
>> that community are informally clued in to "ipn" = 1.  Maybe I'm 
>> unduly pessimistic but I don't see that happening for several years 
>> at best.
> The URI scheme foul-up was because of the review process that's
> associated with the URI scheme registry. Since each registry
> specifies its own rules for additions/updates its actually often
> easier to create a new registry!
>
> Saying "maybe a new registry" in the IANA considerations is fine
> for now.
Sure, that's fine by me.
>> But again, the conditions under which the implementation of a CL 
>> protocol should fail -- whether it's because the CL protocol doesn't 
>> support CBHE or for any one of a thousand other possible errors -- 
>> have got to be in the spec for that CL protocol, not in the CBHE spec 
>> (which the CL protocol developer might not even be aware of).
> We're talking at cross-purposes I think. I'm wondering where in
> the decode process that the CBHE bundle decoding will fail, that's
> all.
Okay, maybe I misunderstood your original question.  I thought you were 
asking what would happen if a CBHE-compressed bundle were to arrive at a 
convergence-layer adapter that doesn't implement CBHE decoding.  My 
answer would be that there's no point in defining this procedure in the 
CBHE spec because -- by definition -- the developer of this 
convergence-layer adapter isn't implementing the CBHE spec and may not 
even know that it exists.

When this scenario occurs, the receiving convergence-layer adapter is 
either going to validate the received bundle's format in some 
CL-specific or implementation-specific manner (in which case I would 
expect it to simply discard the bundle immediately because it has no 
dictionary) or else it is going to pass the unexamined bundle up to the 
BP implementation.  In the latter case the bundle protocol agent will 
attempt to parse the bundle, discover the missing dictionary, judge the 
bundle to be in invalid format (just as if its version number were 31, 
for example), and again simply discard the bundle, though at the BP 
level rather than at the CL level.  It's exactly as if an HTTP message 
got sent to a BP convergence-layer adapter: it's not a valid bundle, so 
at some point you just throw it away.

So I'm thinking that there is no point in the CBHE decode process at 
which the CBHE bundle decoding will fail, because you never start that 
decode process at all.  But I suspect you are actually asking about 
something different and I don't yet understand what....

Scott

Date: Fri, 29 Dec 2006 19:08:07 +0000
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Scott Burleigh wrote:

> Also, I believe our deal with DARPA calls for an Internet Draft on 
> compression to be submitted quite soon now; I'd prefer not to delay it 
> while we come to consensus on additional language.  (And in any case I 
> expect that this Internet Draft in its present form isn't exactly what 
> we'll end up proposing as an RFC.)

That's fine. I'd be happy to argue the toss on inclusion/exclusion
of security stuff later.

> I dunno, Stephen, it seemed to be fairly time-consuming and 
> labor-intensive to get a well-known port number assigned to LTP or to 
> register the "dtn" URI scheme.  The only way we can be headed for 
> collisions is if a user community for CBHE comes into being on a common 
> network (let's say the new BundleBone) and not all members of that 
> community are informally clued in to "ipn" = 1.  Maybe I'm unduly 
> pessimistic but I don't see that happening for several years at best.

The URI scheme foul-up was because of the review process that's
associated with the URI scheme registry. Since each registry
specifies its own rules for additions/updates its actually often
easier to create a new registry!

Saying "maybe a new registry" in the IANA considerations is fine
for now.

> But again, the conditions under which the implementation of a CL 
> protocol should fail -- whether it's because the CL protocol doesn't 
> support CBHE or for any one of a thousand other possible errors -- have 
> got to be in the spec for that CL protocol, not in the CBHE spec (which 
> the CL protocol developer might not even be aware of).

We're talking at cross-purposes I think. I'm wondering where in
the decode process that the CBHE bundle decoding will fail, that's
all.

S.

Content-class: urn:content-classes:message
Subject: RE: Process question: Re: [dtn-interest] an Internet Draft for CBHE
Date: Fri, 29 Dec 2006 10:44:41 -0800
From: "Fall, Kevin" <[email-masked]>
To: <[email-masked]>, "Stephen Farrell" <[email-masked]>, <[email-masked]>
Cc: "DTN" <[email-masked]>
Sender: [email-masked]

Some time ago I posted a message to dtn-interest pointing out the
existence of IETF's SIGCOMP protocol.  What's interesting/surprising is
that this stuff has a language and a sort of active networks paradigm
(you download code to do the compression).

See here:

http://www.opensigcomp.org/

I'd like to understand the tradeoffs between using this sort of system
and the other options...

- K

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Rajesh
Krishnan
Sent: Thursday, December 28, 2006 8:23 AM
To: Stephen Farrell; [email-masked]
Cc: DTN
Subject: Re: Process question: Re: [dtn-interest] an Internet Draft for
CBHE

I am speaking for myself here.  I think that compressed bundle headers
fill an important need in several applications with challenged link
layers (e.g., low data-rate radio links, micro-sensor networks, and
underwater acoustic networks).  There is value in having a single
standard way of doing compressed headers rather than have each community
develop its own non-interoperable DTN header compression specification.

Different research communities often need to develop their own header
compression standard in order to include a particular subset of header
fields (chosen from various layers of the networking protocol stack)
required for their applications.  If a header compression scheme could
be crafted in a manner that allows different communities to selectively
include fields (including from bundle extension blocks), this will be a
big advantage.  

A related research problem would be to develop a compiler that reads in
a declarative header specification (what fields are included and how),
and an uncompressed header instance,  and generates a terse header
compilation.  As long as peers use the same header specification and a
common compilation procedure, they should be able to communicate with
each other.

IMHO, even with the header compression problem scoped more narrowly than
the way I have described it (I understand that the scope of the current
CBHE draft is limited to compressing EIDs), a compressed header
specification is certainly worthy of consideration within the DTNRG.

Best Regards,
Rajesh

On Thu, 2006-12-28 at 15:21 +0000, Stephen Farrell wrote:
> Folks,
> 
> Since we're now at the stage where we've a bunch of drafts that
> are popping up and which may or may not become "official" RG
> work items (to the extent that that terminology applies), I'd
> like to ask whether or not folks agree that that this work should
> be done by dtnrg. I guess it'd be fine to adopt this if 2 or 3
> existing, sort-of independent from the authors, RG participants
> think that it should be adopted and no-one objects. If we don't
> reach that level of consensus then we should probably discuss
> things a bit.
> 
> The intent here is to try document some level of RG buy-in which
> should help a bit whenever the draft is handed off to the IRSG
> for review, so if you could let the list know if you think this
> draft should be adopted or not that'd be great.
> 
> Kevin and I plan to do the same whenever other folks suggest that
> the RG do work on other drafts, so as well as saying what you
> think of this draft, feel free to say what you think of this
> bit of process stuff too,
> 
> Cheers,
> S.
> 
> Scott Burleigh wrote:
> > Hi.  Here's my first cut at an Internet draft for the Compressed
Bundle 
> > Header Encoding conventions I'm using in the ION implementation of
the 
> > Bundle Protocol, updated per version 5 of the protocol.  (I haven't
yet 
> > modified the code to catch up to these changes [i.e., using 8 SDNVs
in 
> > the primary block] but hope to get that done by the end of next
month.)  
> > I'd like to submit it to IETF some time in January; any comments?
> > 
> > Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Fri, 29 Dec 2006 09:24:57 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Stephen Farrell wrote:
> Scott Burleigh wrote:
>> Stephen Farrell wrote:
>>> 2. Are there no opportunities to compress the security
>>> blocks where those are in use?
>> There may well be, but I figured that a spec for compression of the 
>> security blocks ought to be coming from the people who are most 
>> familiar with how those blocks work.
> Sure, you should expect help, but shouldn't those details also
> be specified in the same place since they'd be implemented at
> the same time (I guess).
Okay, augmenting this spec with procedures for compressing the security 
blocks as well is fine with me if somebody wants to propose some 
language.  But I think it also would be perfectly okay to add a section 
of optional CBHE-aligned compression procedures to the bundle security 
protocol spec instead, or even to write another small stand-alone spec 
for CBHE compression of bundle security blocks; I kind of prefer the 
former as it limits the proliferation of documents.  My reasoning here 
is that I can imagine wanting to do CBHE-style compression for other 
kinds of extension blocks as well, and I don't think it would make sense 
to dive back into the CBHE book and extend it every time we work out the 
CBHE procedures for another extension block.

Also, I believe our deal with DARPA calls for an Internet Draft on 
compression to be submitted quite soon now; I'd prefer not to delay it 
while we come to consensus on additional language.  (And in any case I 
expect that this Internet Draft in its present form isn't exactly what 
we'll end up proposing as an RFC.)
>>>
>>> 3. It looks to me like you'd need an IANA registry for the
>>> scheme name/number mappings.
>> Registering those mappings within IANA would certainly be a good 
>> approach.  At this very early stage of things I think it would be 
>> overkill, though; nobody that I know of outside of the space mission 
>> operations community is even proposing to use CBHE at this point, and 
>> for the near term (out to several years) I think we can get by with 
>> just using a single scheme named "ipn", numbered 1.  If a larger user 
>> community emerged then of course something more formal would be 
>> needed, but for now I think we'd look silly going to IANA with this.
> Not sure about that. IANA have a lot of sparse registries and
> there's not much of a cost. Basically, the fact that evceryone has
> to know that 1=="ipn:" really does call for a registry, otherwise
> we head for collisions.
I dunno, Stephen, it seemed to be fairly time-consuming and 
labor-intensive to get a well-known port number assigned to LTP or to 
register the "dtn" URI scheme.  The only way we can be headed for 
collisions is if a user community for CBHE comes into being on a common 
network (let's say the new BundleBone) and not all members of that 
community are informally clued in to "ipn" = 1.  Maybe I'm unduly 
pessimistic but I don't see that happening for several years at best.
>>> 4. Since this specifies a profile, I guess that there'll be
>>> bundles that don't match the profile that'll arrive at the
>>> compression gateway - is there a new error code needed for
>>> such out-of-profile bundles? If not, then I think there's a
>>> missing MUST - agents MUST attempt to transmit those bundles
>>> uncompressed. (3.1 almost makes this clear, but I'm not
>>> sure.)
>> The intent of 3.1 is to say that the convergence-layer adapter isn't 
>> required to do CBHE compression even for bundles that are amenable to 
>> it, though it may, and I think that's what the words say.
>>
>> I'm trying to make this spec merely additive rather than something 
>> that overrides any part of the BP spec, and the BP spec already goes 
>> as far as I think we want it to go in levying requirements on 
>> convergence layer adapters.  I would say that any further MUST 
>> language that applies to convergence layer adapters belongs in the 
>> convergence layer specs and is independent of what the CBHE spec says.
> But that seems to say that we need a CL-specific CBHE document before
> we can implement? I didn't think so, but rather that this could be a
> shim layer on top of lots of different CLs.
I don't think I'm saying that, though.  I think I'm instead saying that 
the specification for each CL protocol on which we want CBHE support 
will need to have its own language referencing the common, CL-neutral 
CBHE spec.

It's the same idea as what I'm proposing to do about the bundle security 
protocol and other extension blocks: don't build all this stuff into the 
CBHE spec, just reference the CBHE spec in language that is added to 
each CL protocol spec or extension block spec.  This way we keep the 
CBHE spec as small, simple, and stable as possible.
>>>
>>> 5. What would happen were a compressed bundle to arrive at
>>> an agent that doesn't implement this? I think that that
>>> ought be explained.
>> Well, you're right.  How about this?
>>
>> 1.    At the end of the first paragraph of section 3 we can say 
>> "Bundle Protocol convergence-layer adapters that conform to the CBHE 
>> specification must implement the following procedures."
>>
>> 2.    Then in 3.1 we amend the text to say (emphasis added) "When and 
>> only when required by the bundle protocol agent to transmit TO SOME 
>> CBHE-CONFORMANT CONVERGENCE LAYER ADAPTER a bundle whose primary 
>> block's endpoint IDs satisfy the constraints summarized in section 
>> 2.1 above, the convergence layer adapter may encode the primary block 
>> of the bundle in accordance with the CBHE compression convention 
>> described in section 2.2 above."
>>
>> Now if a compressed bundle arrives at a non-CBHE-conformant 
>> convergence layer adapter it's due to an error in the sending 
>> convergence layer adapter.  A wide variety of errors in the 
>> operations of sending convergence layer adapters are always possible, 
>> with any number of causes, and the receiving convergence layer 
>> adapter has got to be able to deal with all of those errors; we leave 
>> the handling of this error, like any other, to the convergence layer 
>> specification and/or the implementation of the convergence layer 
>> adapter.
> That's all good. However, I guess I wanted to be convinced that
> the CBHE bundle wouldn't cause odd behaviour in a non-CBHE bundle
> codec. I know it shouldn't, but I'd rather know where the non-CBHE
> codec should barf, and see that written down, so that a non-CBHE
> developer could read this and say "ah, better put in & test an error
> handler for that case".
But again, the conditions under which the implementation of a CL 
protocol should fail -- whether it's because the CL protocol doesn't 
support CBHE or for any one of a thousand other possible errors -- have 
got to be in the spec for that CL protocol, not in the CBHE spec (which 
the CL protocol developer might not even be aware of).
>> One additional issue occurs to me, now that I think of it: as the 
>> spec currently reads, it would be possible to compress a bundle -- 
>> destroying its dictionary -- even in the event that one or more 
>> extension blocks contain citations of endpoint IDs that are contained 
>> in the dictionary.  
> That was something we thought of for the security stuff, but I thought
> it had been disallowed for some reason? If the security blocks could
> use the dictionary then I think that'd be good too and would maybe want
> to change back to that.
>> So we need yet one more constraint on CBHE compression:
>>
>> "When and only when required by the bundle protocol agent to transmit 
>> TO SOME CBHE-CONFORMANT CONVERGENCE LAYER ADAPTER a bundle whose 
>> primary block's endpoint IDs satisfy the constraints summarized in 
>> section 2.1 above AND WHOSE EXTENSION BLOCKS (IF ANY) CONTAIN NO 
>> CITATIONS OF ENDPOINT IDS THAT ARE CONTAINED IN THE PRIMARY BLOCK'S 
>> DICTIONARY, the convergence layer adapter may encode the primary 
>> block of the bundle in accordance with the CBHE compression 
>> convention described in section 2.2 above."
> That calls for the CBHE-tx-codec to understand all extensions present,
> or else to send the uncompressed bundle, right?
Correct.  In the CBHE spec we can't (and shouldn't) tell the CL protocol 
developer how to figure out whether or not the conditions that make CBHE 
possible are satisfied, because that determination will be 
implementation-specific; maybe the CL adapter reads through the bundle, 
maybe the BP agent hands it a hint along with the bundle that's to be 
transmitted, whatever.  We do have to say what those conditions are, though.

Worst case, the bundle doesn't get compressed and the network misses out 
on this bit of optimization, but still nothing breaks.  The Bundle 
Protocol should always work just fine, whether CBHE is applied or not 
(which is why the language in 3.1 says "may").

Scott

Date: Fri, 29 Dec 2006 15:09:31 +0000
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Hi Scott,

Scott Burleigh wrote:
> Stephen Farrell wrote:
>>
>> FWIW, I do think we should do this work in the DTNRG.
>>
>> My comments after a quick read (sorry if I've missed stuff
>> that's covered already).
>>
>> 1.  This seems to be a mixture of a profile and a compression
>> method, rather than just the latter. I'm not sure if that's a
>> good or a bad idea, but maybe the title is a bit misleading?
> Stephen, I'm not sure what you mean by profile in this context.  Can you 
> explain?  

I'll try. The document is a profile in the sense that it
defines a set of bundles to which the compression method
applies. A compression method that applied to any bundle
wouldn't involve a profile. A generic compression method
might of course be more of less efficient depending on
the bundle content.

As I said though, I've no strong opinion as to whether
that's a good or bad idea.

 > I certainly don't want the title to be misleading, and
> obviously I'm too close to the topic to see what might be confusing to 
> others, but don't see anything in this document beyond an extremely 
> simple compression scheme.
>>
>> 2. Are there no opportunities to compress the security
>> blocks where those are in use?
> There may well be, but I figured that a spec for compression of the 
> security blocks ought to be coming from the people who are most familiar 
> with how those blocks work.

Sure, you should expect help, but shouldn't those details also
be specified in the same place since they'd be implemented at
the same time (I guess).

>> (I assume that signatures etc.
>> are supposed to verify regardless of compression since this
>> is all CL stuff?)
> Exactly.  You decompress before you verify.

Cool.

>>
>> 3. It looks to me like you'd need an IANA registry for the
>> scheme name/number mappings.
> Registering those mappings within IANA would certainly be a good 
> approach.  At this very early stage of things I think it would be 
> overkill, though; nobody that I know of outside of the space mission 
> operations community is even proposing to use CBHE at this point, and 
> for the near term (out to several years) I think we can get by with just 
> using a single scheme named "ipn", numbered 1.  If a larger user 
> community emerged then of course something more formal would be needed, 
> but for now I think we'd look silly going to IANA with this.

Not sure about that. IANA have a lot of sparse registries and
there's not much of a cost. Basically, the fact that evceryone has
to know that 1=="ipn:" really does call for a registry, otherwise
we head for collisions.

>> 4. Since this specifies a profile, I guess that there'll be
>> bundles that don't match the profile that'll arrive at the
>> compression gateway - is there a new error code needed for
>> such out-of-profile bundles? If not, then I think there's a
>> missing MUST - agents MUST attempt to transmit those bundles
>> uncompressed. (3.1 almost makes this clear, but I'm not
>> sure.)
> The intent of 3.1 is to say that the convergence-layer adapter isn't 
> required to do CBHE compression even for bundles that are amenable to 
> it, though it may, and I think that's what the words say.
> 
> I'm trying to make this spec merely additive rather than something that 
> overrides any part of the BP spec, and the BP spec already goes as far 
> as I think we want it to go in levying requirements on convergence layer 
> adapters.  I would say that any further MUST language that applies to 
> convergence layer adapters belongs in the convergence layer specs and is 
> independent of what the CBHE spec says.

But that seems to say that we need a CL-specific CBHE document before
we can implement? I didn't think so, but rather that this could be a
shim layer on top of lots of different CLs.

>>
>> 5. What would happen were a compressed bundle to arrive at
>> an agent that doesn't implement this? I think that that
>> ought be explained.
> Well, you're right.  How about this?
> 
> 1.    At the end of the first paragraph of section 3 we can say "Bundle 
> Protocol convergence-layer adapters that conform to the CBHE 
> specification must implement the following procedures."
> 
> 2.    Then in 3.1 we amend the text to say (emphasis added) "When and 
> only when required by the bundle protocol agent to transmit TO SOME 
> CBHE-CONFORMANT CONVERGENCE LAYER ADAPTER a bundle whose primary block's 
> endpoint IDs satisfy the constraints summarized in section 2.1 above, 
> the convergence layer adapter may encode the primary block of the bundle 
> in accordance with the CBHE compression convention described in section 
> 2.2 above."
> 
> Now if a compressed bundle arrives at a non-CBHE-conformant convergence 
> layer adapter it's due to an error in the sending convergence layer 
> adapter.  A wide variety of errors in the operations of sending 
> convergence layer adapters are always possible, with any number of 
> causes, and the receiving convergence layer adapter has got to be able 
> to deal with all of those errors; we leave the handling of this error, 
> like any other, to the convergence layer specification and/or the 
> implementation of the convergence layer adapter.

That's all good. However, I guess I wanted to be convinced that
the CBHE bundle wouldn't cause odd behaviour in a non-CBHE bundle
codec. I know it shouldn't, but I'd rather know where the non-CBHE
codec should barf, and see that written down, so that a non-CBHE
developer could read this and say "ah, better put in & test an error
handler for that case".

> One additional issue occurs to me, now that I think of it: as the spec 
> currently reads, it would be possible to compress a bundle -- destroying 
> its dictionary -- even in the event that one or more extension blocks 
> contain citations of endpoint IDs that are contained in the dictionary.  

That was something we thought of for the security stuff, but I thought
it had been disallowed for some reason? If the security blocks could
use the dictionary then I think that'd be good too and would maybe want
to change back to that.

> So we need yet one more constraint on CBHE compression:
> 
> "When and only when required by the bundle protocol agent to transmit TO 
> SOME CBHE-CONFORMANT CONVERGENCE LAYER ADAPTER a bundle whose primary 
> block's endpoint IDs satisfy the constraints summarized in section 2.1 
> above AND WHOSE EXTENSION BLOCKS (IF ANY) CONTAIN NO CITATIONS OF 
> ENDPOINT IDS THAT ARE CONTAINED IN THE PRIMARY BLOCK'S DICTIONARY, the 
> convergence layer adapter may encode the primary block of the bundle in 
> accordance with the CBHE compression convention described in section 2.2 
> above."

That calls for the CBHE-tx-codec to understand all extensions present,
or else to send the uncompressed bundle, right?

S.

> 
> Scott
>> Scott Burleigh wrote:
>>> Here's a revised Internet Draft that reflects this change.
>>>
>>> Scott
>>>> So okay, recognizing that it's useful to enable service numbers to 
>>>> serve the same sort of function as port numbers, let's change CBHE 
>>>> around.  I still want to stick to doing no more than redefining the 
>>>> semantics of those eight DSNVs in the primary block (to make it easy 
>>>> for convergence-layer adapters to handle both compressed and 
>>>> non-compressed bundles), so the best approach seems to be this:
>>>>
>>>> 1.   Use just one SDNV for scheme number, which must be common to 
>>>> all four EIDs rather than just to the source and reply-to.  (This is 
>>>> the way CBHE was defined before version 5 of BP anyway.)  Bundles 
>>>> can still flow readily between endpoints whose IDs have different 
>>>> schemes -- they just can't be compressed.  Since there has to date 
>>>> been zero inter-scheme traffic in all DTN testing that I can think 
>>>> of, this should impose no great hardship; CBHE helps to optimize 
>>>> intra-scheme traffic and doesn't inhibit (non-existent) inter-scheme 
>>>> traffic, so the focus seems appropriate.
>>>>
>>>> 2.   That frees up two SDNVs for service numbers, so we can carry 
>>>> distinct service numbers for the destination, source, and report-to 
>>>> endpoints; the service number for the current custodian endpoint
>>>> remains a constant zero.
>>>>
>>>> So now (a) the destination and source service numbers can be 
>>>> different, acting as port numbers where this is useful, and (b) the 
>>>> report-to service number can be a number other than zero, which may 
>>>> be helpful for applications like bundlePing.
>>>>   
>> _______________________________________________
>> dtn-interest mailing list
>> [email-masked]
>> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>>
> 
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Date: Thu, 28 Dec 2006 09:20:59 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Stephen Farrell wrote:
>
> FWIW, I do think we should do this work in the DTNRG.
>
> My comments after a quick read (sorry if I've missed stuff
> that's covered already).
>
> 1.  This seems to be a mixture of a profile and a compression
> method, rather than just the latter. I'm not sure if that's a
> good or a bad idea, but maybe the title is a bit misleading?
Stephen, I'm not sure what you mean by profile in this context.  Can you 
explain?  I certainly don't want the title to be misleading, and 
obviously I'm too close to the topic to see what might be confusing to 
others, but don't see anything in this document beyond an extremely 
simple compression scheme.
>
> 2. Are there no opportunities to compress the security
> blocks where those are in use?
There may well be, but I figured that a spec for compression of the 
security blocks ought to be coming from the people who are most familiar 
with how those blocks work.
> (I assume that signatures etc.
> are supposed to verify regardless of compression since this
> is all CL stuff?)
Exactly.  You decompress before you verify.
>
> 3. It looks to me like you'd need an IANA registry for the
> scheme name/number mappings.
Registering those mappings within IANA would certainly be a good 
approach.  At this very early stage of things I think it would be 
overkill, though; nobody that I know of outside of the space mission 
operations community is even proposing to use CBHE at this point, and 
for the near term (out to several years) I think we can get by with just 
using a single scheme named "ipn", numbered 1.  If a larger user 
community emerged then of course something more formal would be needed, 
but for now I think we'd look silly going to IANA with this.
>
> 4. Since this specifies a profile, I guess that there'll be
> bundles that don't match the profile that'll arrive at the
> compression gateway - is there a new error code needed for
> such out-of-profile bundles? If not, then I think there's a
> missing MUST - agents MUST attempt to transmit those bundles
> uncompressed. (3.1 almost makes this clear, but I'm not
> sure.)
The intent of 3.1 is to say that the convergence-layer adapter isn't 
required to do CBHE compression even for bundles that are amenable to 
it, though it may, and I think that's what the words say.

I'm trying to make this spec merely additive rather than something that 
overrides any part of the BP spec, and the BP spec already goes as far 
as I think we want it to go in levying requirements on convergence layer 
adapters.  I would say that any further MUST language that applies to 
convergence layer adapters belongs in the convergence layer specs and is 
independent of what the CBHE spec says.
>
> 5. What would happen were a compressed bundle to arrive at
> an agent that doesn't implement this? I think that that
> ought be explained.
Well, you're right.  How about this?

1.    At the end of the first paragraph of section 3 we can say "Bundle 
Protocol convergence-layer adapters that conform to the CBHE 
specification must implement the following procedures."

2.    Then in 3.1 we amend the text to say (emphasis added) "When and 
only when required by the bundle protocol agent to transmit TO SOME 
CBHE-CONFORMANT CONVERGENCE LAYER ADAPTER a bundle whose primary block's 
endpoint IDs satisfy the constraints summarized in section 2.1 above, 
the convergence layer adapter may encode the primary block of the bundle 
in accordance with the CBHE compression convention described in section 
2.2 above."

Now if a compressed bundle arrives at a non-CBHE-conformant convergence 
layer adapter it's due to an error in the sending convergence layer 
adapter.  A wide variety of errors in the operations of sending 
convergence layer adapters are always possible, with any number of 
causes, and the receiving convergence layer adapter has got to be able 
to deal with all of those errors; we leave the handling of this error, 
like any other, to the convergence layer specification and/or the 
implementation of the convergence layer adapter.

One additional issue occurs to me, now that I think of it: as the spec 
currently reads, it would be possible to compress a bundle -- destroying 
its dictionary -- even in the event that one or more extension blocks 
contain citations of endpoint IDs that are contained in the dictionary.  
So we need yet one more constraint on CBHE compression:

"When and only when required by the bundle protocol agent to transmit TO 
SOME CBHE-CONFORMANT CONVERGENCE LAYER ADAPTER a bundle whose primary 
block's endpoint IDs satisfy the constraints summarized in section 2.1 
above AND WHOSE EXTENSION BLOCKS (IF ANY) CONTAIN NO CITATIONS OF 
ENDPOINT IDS THAT ARE CONTAINED IN THE PRIMARY BLOCK'S DICTIONARY, the 
convergence layer adapter may encode the primary block of the bundle in 
accordance with the CBHE compression convention described in section 2.2 
above."

Scott
> Scott Burleigh wrote:
>> Here's a revised Internet Draft that reflects this change.
>>
>> Scott
>>> So okay, recognizing that it's useful to enable service numbers to 
>>> serve the same sort of function as port numbers, let's change CBHE 
>>> around.  I still want to stick to doing no more than redefining the 
>>> semantics of those eight DSNVs in the primary block (to make it easy 
>>> for convergence-layer adapters to handle both compressed and 
>>> non-compressed bundles), so the best approach seems to be this:
>>>
>>> 1.   Use just one SDNV for scheme number, which must be common to 
>>> all four EIDs rather than just to the source and reply-to.  (This is 
>>> the way CBHE was defined before version 5 of BP anyway.)  Bundles 
>>> can still flow readily between endpoints whose IDs have different 
>>> schemes -- they just can't be compressed.  Since there has to date 
>>> been zero inter-scheme traffic in all DTN testing that I can think 
>>> of, this should impose no great hardship; CBHE helps to optimize 
>>> intra-scheme traffic and doesn't inhibit (non-existent) inter-scheme 
>>> traffic, so the focus seems appropriate.
>>>
>>> 2.   That frees up two SDNVs for service numbers, so we can carry 
>>> distinct service numbers for the destination, source, and report-to 
>>> endpoints; the service number for the current custodian endpoint
>>> remains a constant zero.
>>>
>>> So now (a) the destination and source service numbers can be 
>>> different, acting as port numbers where this is useful, and (b) the 
>>> report-to service number can be a number other than zero, which may 
>>> be helpful for applications like bundlePing.
>>>   
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Subject: Re: Process question: Re: [dtn-interest] an Internet Draft for CBHE
From: Rajesh Krishnan <[email-masked]>
Reply-To: [email-masked]
To: Stephen Farrell <[email-masked]>, [email-masked]
Cc: DTN <[email-masked]>
Organization: BBN Technologies
Date: Thu, 28 Dec 2006 11:23:18 -0500
Sender: [email-masked]

I am speaking for myself here.  I think that compressed bundle headers
fill an important need in several applications with challenged link
layers (e.g., low data-rate radio links, micro-sensor networks, and
underwater acoustic networks).  There is value in having a single
standard way of doing compressed headers rather than have each community
develop its own non-interoperable DTN header compression specification.

Different research communities often need to develop their own header
compression standard in order to include a particular subset of header
fields (chosen from various layers of the networking protocol stack)
required for their applications.  If a header compression scheme could
be crafted in a manner that allows different communities to selectively
include fields (including from bundle extension blocks), this will be a
big advantage.  

A related research problem would be to develop a compiler that reads in
a declarative header specification (what fields are included and how),
and an uncompressed header instance,  and generates a terse header
compilation.  As long as peers use the same header specification and a
common compilation procedure, they should be able to communicate with
each other.

IMHO, even with the header compression problem scoped more narrowly than
the way I have described it (I understand that the scope of the current
CBHE draft is limited to compressing EIDs), a compressed header
specification is certainly worthy of consideration within the DTNRG.

Best Regards,
Rajesh

On Thu, 2006-12-28 at 15:21 +0000, Stephen Farrell wrote:
> Folks,
> 
> Since we're now at the stage where we've a bunch of drafts that
> are popping up and which may or may not become "official" RG
> work items (to the extent that that terminology applies), I'd
> like to ask whether or not folks agree that that this work should
> be done by dtnrg. I guess it'd be fine to adopt this if 2 or 3
> existing, sort-of independent from the authors, RG participants
> think that it should be adopted and no-one objects. If we don't
> reach that level of consensus then we should probably discuss
> things a bit.
> 
> The intent here is to try document some level of RG buy-in which
> should help a bit whenever the draft is handed off to the IRSG
> for review, so if you could let the list know if you think this
> draft should be adopted or not that'd be great.
> 
> Kevin and I plan to do the same whenever other folks suggest that
> the RG do work on other drafts, so as well as saying what you
> think of this draft, feel free to say what you think of this
> bit of process stuff too,
> 
> Cheers,
> S.
> 
> Scott Burleigh wrote:
> > Hi.  Here's my first cut at an Internet draft for the Compressed Bundle 
> > Header Encoding conventions I'm using in the ION implementation of the 
> > Bundle Protocol, updated per version 5 of the protocol.  (I haven't yet 
> > modified the code to catch up to these changes [i.e., using 8 SDNVs in 
> > the primary block] but hope to get that done by the end of next month.)  
> > I'd like to submit it to IETF some time in January; any comments?
> > 
> > Scott
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Thu, 28 Dec 2006 16:09:32 +0000
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

FWIW, I do think we should do this work in the DTNRG.

My comments after a quick read (sorry if I've missed stuff
that's covered already).

1.  This seems to be a mixture of a profile and a compression
method, rather than just the latter. I'm not sure if that's a
good or a bad idea, but maybe the title is a bit misleading?

2. Are there no opportunities to compress the security
blocks where those are in use? (I assume that signatures etc.
are supposed to verify regardless of compression since this
is all CL stuff?)

3. It looks to me like you'd need an IANA registry for the
scheme name/number mappings.

4. Since this specifies a profile, I guess that there'll be
bundles that don't match the profile that'll arrive at the
compression gateway - is there a new error code needed for
such out-of-profile bundles? If not, then I think there's a
missing MUST - agents MUST attempt to transmit those bundles
uncompressed. (3.1 almost makes this clear, but I'm not
sure.)

5. What would happen were a compressed bundle to arrive at
an agent that doesn't implement this? I think that that
ought be explained.

Stephen.

Scott Burleigh wrote:
> Here's a revised Internet Draft that reflects this change.
> 
> Scott
>> So okay, recognizing that it's useful to enable service numbers to 
>> serve the same sort of function as port numbers, let's change CBHE 
>> around.  I still want to stick to doing no more than redefining the 
>> semantics of those eight DSNVs in the primary block (to make it easy 
>> for convergence-layer adapters to handle both compressed and 
>> non-compressed bundles), so the best approach seems to be this:
>>
>> 1.   Use just one SDNV for scheme number, which must be common to all 
>> four EIDs rather than just to the source and reply-to.  (This is the 
>> way CBHE was defined before version 5 of BP anyway.)  Bundles can 
>> still flow readily between endpoints whose IDs have different schemes 
>> -- they just can't be compressed.  Since there has to date been zero 
>> inter-scheme traffic in all DTN testing that I can think of, this 
>> should impose no great hardship; CBHE helps to optimize intra-scheme 
>> traffic and doesn't inhibit (non-existent) inter-scheme traffic, so 
>> the focus seems appropriate.
>>
>> 2.   That frees up two SDNVs for service numbers, so we can carry 
>> distinct service numbers for the destination, source, and report-to 
>> endpoints; the service number for the current custodian endpoint
>> remains a constant zero.
>>
>> So now (a) the destination and source service numbers can be 
>> different, acting as port numbers where this is useful, and (b) the 
>> report-to service number can be a number other than zero, which may be 
>> helpful for applications like bundlePing.
>>   

Date: Thu, 28 Dec 2006 15:21:00 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: Process question: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Folks,

Since we're now at the stage where we've a bunch of drafts that
are popping up and which may or may not become "official" RG
work items (to the extent that that terminology applies), I'd
like to ask whether or not folks agree that that this work should
be done by dtnrg. I guess it'd be fine to adopt this if 2 or 3
existing, sort-of independent from the authors, RG participants
think that it should be adopted and no-one objects. If we don't
reach that level of consensus then we should probably discuss
things a bit.

The intent here is to try document some level of RG buy-in which
should help a bit whenever the draft is handed off to the IRSG
for review, so if you could let the list know if you think this
draft should be adopted or not that'd be great.

Kevin and I plan to do the same whenever other folks suggest that
the RG do work on other drafts, so as well as saying what you
think of this draft, feel free to say what you think of this
bit of process stuff too,

Cheers,
S.

Scott Burleigh wrote:
> Hi.  Here's my first cut at an Internet draft for the Compressed Bundle 
> Header Encoding conventions I'm using in the ION implementation of the 
> Bundle Protocol, updated per version 5 of the protocol.  (I haven't yet 
> modified the code to catch up to these changes [i.e., using 8 SDNVs in 
> the primary block] but hope to get that done by the end of next month.)  
> I'd like to submit it to IETF some time in January; any comments?
> 
> Scott

Date: Wed, 27 Dec 2006 15:39:37 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------080002000009060606000302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Here's a revised Internet Draft that reflects this change.

Scott
> So okay, recognizing that it's useful to enable service numbers to serve the same sort of function as port numbers, let's change CBHE around.  I still want to stick to doing no more than redefining the semantics of those eight DSNVs in the primary block (to make it easy for convergence-layer adapters to handle both compressed and non-compressed bundles), so the best approach seems to be this:
>
> 1.   Use just one SDNV for scheme number, which must be common to all four EIDs rather than just to the source and reply-to.  (This is the way CBHE was defined before version 5 of BP anyway.)  Bundles can still flow readily between endpoints whose IDs have different schemes -- they just can't be compressed.  Since there has to date been zero inter-scheme traffic in all DTN testing that I can think of, this should impose no great hardship; CBHE helps to optimize intra-scheme traffic and doesn't inhibit (non-existent) inter-scheme traffic, so the focus seems appropriate.
>
> 2.   That frees up two SDNVs for service numbers, so we can carry distinct service numbers for the destination, source, and report-to endpoints; the service number for the current custodian endpoint
> remains a constant zero.
>
> So now (a) the destination and source service numbers can be different, acting as port numbers where this is useful, and (b) the report-to service number can be a number other than zero, which may be helpful for applications like bundlePing.
>   

--------------080002000009060606000302
Content-Type: text/plain;
 name="draft-irtf-cbhe-00.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-irtf-cbhe-00.txt"

Network Working Group                                        S. Burleigh
Internet-Draft                                Jet Propulsion Laboratory,
Intended status: Experimental                   California Institute of
Expires: June 30, 2007                                        Technology
                                                       December 27, 2006

                Compressed Bundle Header Encoding (CBHE)
                           draft-irtf-cbhe-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 30, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a convention for representing Delay-Tolerant
   Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a
   compressed manner within the primary blocks of bundles.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Burleigh                  Expires June 30, 2007                 [Page 1]

Internet-Draft                    CBHE                     December 2006

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Compression convention  . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Constraints . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Method  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 6
     3.1.  Transmission  . . . . . . . . . . . . . . . . . . . . . . . 6
     3.2.  Reception . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

Burleigh                  Expires June 30, 2007                 [Page 2]

Internet-Draft                    CBHE                     December 2006

1.  Introduction

   This document describes a convention for representing Delay-Tolerant
   Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a
   compressed manner within the primary blocks of bundles.

   Each DTN bundle's primary block contains four BP endpoint identifiers
   (EIDs), of which any two, any three, or even all four may be
   lexically identical: the endpoint identifiers of the source, the
   destination, the report-to endpoint, and the current custodian.  Each
   EID is a Uniform Record Identifier (URI), an ASCII string of the form
   "scheme_name:scheme_specific_part".

   A degree of block compression is provided by the design of the
   primary block: the scheme names and scheme-specific parts of the four
   endpoints' IDs - up to eight NULL-terminated strings - are
   concatenated at the end of the block in a variable-length character
   array called a "dictionary", enabling each EID to be represented by a
   pair of integers indicating the offsets (within the dictionary) of
   the EID's scheme name and scheme-specific part.  Duplicate strings
   may be omitted from the dictionary, so the actual number of
   concatenated NULL-terminated strings in the dictionary may be less
   than eight and two or more of the scheme name or scheme-specific part
   offsets in the block may have the same value.  Moreover, the eight
   offsets in the primary block are encoded as self-delimiting numeric
   values (SDNVs), which shrink to fit the encoded values; when the
   total length of the dictionary is less than 127 bytes, all eight
   offsets can be encoded into just eight bytes.

   However, these strategems do not prevent the scheme names and scheme-
   specific parts themselves from being arbitrarily lengthy strings of
   ASCII text.  It is therefore still possible for the length of a
   bundle's primary header to be a very large fraction of the total
   length of the bundle when the bundle's payload is relatively small,
   as is anticipated for a number of DTN applications such as space
   flight operations.

   The Compressed Bundle Header Encoding (CBHE) convention was developed
   to improve DTN transmission efficiency for such applications by
   further reducing the number of bytes used to express EIDs in the
   primary blocks of bundles.

2.  Compression convention

Burleigh                  Expires June 30, 2007                 [Page 3]

Internet-Draft                    CBHE                     December 2006

2.1.  Constraints

   Compressed Bundle Header Encoding (CBHE) is possible only when the
   scheme names of all non-null endpoint IDs in the primary block of a
   given bundle (that is, all endpoint IDs in the primary block that are
   not "dtn:none") identify a single scheme that is understood
   universally within the network to be "CBHE-conformant".

   All CBHE-conformant schemes are numbered and are identifiable by
   their numbers as well as their names.  A one-to-one correspondence
   between scheme numbers and the names of CBHE-conformant schemes is
   assumed to be well-known throughout the network (either by management
   or, as the scope of the network grows, by means of a protocol yet to
   be developed).

   The scheme-specific part of each entity-identifying URI whose scheme
   name identifies a CBHE-conformant scheme must be of the form
   "element_number.service_number".

   By convention, element number is a non-negative integer that can be
   thought of as a BP node identifier, such as a spacecraft identifier.
   Element number zero is used to indicate the null endpoint; any EID
   whose scheme name identifies a CBHE-conformant scheme and whose
   element number is zero, regardless of service number, is interpreted
   within the CBHE convention as an alternative representation of the
   standard null endpoint ID "dtn:none".

   By convention, service number is a non-negative integer that
   functions as a de-multiplexing token.  When the protocol encapsulated
   within BP has its own de-multiplexing identifiers, the service number
   may function in a manner similar to that of the protocol number in an
   IP packet, characterizing the bundle payload; alternatively, the
   service number may function in a manner similar to that of the port
   number in a UDP datagram.  Service numbers enable inbound bundles'
   application data units to be de-multiplexed to elements of
   application functionality that are designed to process them, so that
   effective communication relationships can be developed between bundle
   producers and consumers.

   Service number zero is used exclusively to identify BP custody signal
   traffic.

   Conversion of an EID in URI form - where the URI's scheme is CBHE-
   conformant - to and from a tuple of three integers is therefore
   straightforward.  This ease of conversion enables an array of
   integers to serve the same function as a dictionary of EID ASCII
   strings.

Burleigh                  Expires June 30, 2007                 [Page 4]

Internet-Draft                    CBHE                     December 2006

   To summarize, CBHE representation of EIDs in a given bundle's primary
   block is constrained as follows:

   o  The scheme names of all non-null endpoint IDs must be the same.

   o  The scheme name common to all non-null endpoint IDs must identify
      a scheme that is well-known to be CBHE-conformant, and that scheme
      must be uniquely identified by a well-known scheme number.

   o  The scheme-specific parts of all non-null endpoint IDs must be in
      "element_number.service_number" form, where both element_number
      and service_number are non-negative integers.

   o  If the bundle's Current Custodian endpoint ID is not null, then
      the service number for that endpoint ID must be zero.

2.2.  Method

   When the constraints summarized above are met, the CBHE block
   compression method can be applied.  In a CBHE-compressed primary
   block, the eight SDNVs that normally contain EIDs' offsets within the
   dictionary are instead used to contain the eight integer values
   listed below, in the order shown:

   1.  The scheme number that is common to all non-null endpoint IDs.

   2.  The element number of the destination endpoint ID, or zero if the
       destination endpoint is the null endpoint.

   3.  The service number of the destination endpoint ID, or zero if the
       destination endpoint is the null endpoint.

   4.  The element number of the source endpoint ID, or zero if the
       source endpoint is the null endpoint.

   5.  The service number of the source endpoint ID, or zero if the
       source endpoint is the null endpoint.

   6.  The element number of the report-to endpoint ID, or zero if the
       report-to endpoint is the null endpoint.

   7.  The service number of the report-to endpoint ID, or zero if the
       report-to endpoint is the null endpoint.

   8.  The element number of the current custodian endpoint ID, or zero
       if the current custodian endpoint is the null endpoint.

   Further, the dictionary is omitted from the primary block and the

Burleigh                  Expires June 30, 2007                 [Page 5]

Internet-Draft                    CBHE                     December 2006

   primary block's dictionary length is set to zero.

   This compression method is applied at the convergence layer: the
   transmitting convergence-layer adaptation compresses the primary
   block as shown above, and upon reception the receiving convergence-
   layer adaptation de-compresses the block by simply reversing the
   process.

3.  Specification

   CBHE compression is a convergence-layer adaptation.  It is opaque to
   bundle processing.  It therefore has no impact on the
   interoperability of different Bundle Protocol implementations, but
   instead affects only the interoperability of different convergence
   layer adaptation implementations.

3.1.  Transmission

   When and only when required by the bundle protocol agent to transmit
   a bundle whose primary block's endpoint IDs satisfy the constraints
   summarized in section 2.1 above, the convergence layer adapter may
   encode the primary block of the bundle in accordance with the CBHE
   compression convention described in section 2.2 above.

3.2.  Reception

   Upon receiving a bundle whose dictionary length is zero (and only in
   this circumstance), the convergence layer adapter must decode the
   primary block of the bundle in accordance with the CBHE compression
   convention described in section 2.2 above before delivering it to the
   bundle protocol agent.

4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

5.  Security Considerations

   CBHE introduces no new security considerations beyond those discussed
   in the DTN Bundle Protocol and Bundle Security Protocol
   specifications.

Burleigh                  Expires June 30, 2007                 [Page 6]

Internet-Draft                    CBHE                     December 2006

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address

   Scott Burleigh
   Jet Propulsion Laboratory, California Institute of Technology
   4800 Oak Grove Drive, m/s 301-490
   Pasadena, CA  91109
   USA

Burleigh                  Expires June 30, 2007                 [Page 7]

Internet-Draft                    CBHE                     December 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Burleigh                  Expires June 30, 2007                 [Page 8]


--------------080002000009060606000302--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] an Internet Draft for CBHE
Date: Wed, 27 Dec 2006 16:23:00 -0500
From: "Scott, Keith L." <[email-masked]>
To: "DTNRG" <[email-masked]>
Sender: [email-masked]

Sorry, I quickly skimmed and thought this morning's post was just an
errant repost of last night's.  I like what you have here a lot better.
I think that allowing for different service numbers in the various EIDs
makes the approach a lot more flexible.

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
Sent: Wednesday, December 27, 2006 11:41 AM
To: DTNRG
Subject: Re: [dtn-interest] an Internet Draft for CBHE

Scott Burleigh wrote:
> Scott, Keith L. wrote:
>> Page 4 of the intro: you state that:
>>
>>   "By convention, service number is a numeric value that is
>> functionally
>>    similar to the protocol number in an IP packet, characterizing
>> bundle
>>    payload."
>>
>> I suspect you really intend for the service number in CBHE bundles
to
>> be functionally similar to the port number in a transport layer
(e.g.
>> TCP, UDP) packet.  The protocol number in an IP packet identifies
the
>> next protocol, which is typically one of (TCP,UDP,IPSEC ESP).  The
>> protocol number does not provide (much) direct information about the
>> application being used.
>
> Thanks, Keith, a very reasonable question.  Actually I do
specifically 
> mean protocol number, because I look at BP as being functionally 
> similar to IP rather than to TCP or UDP.  For example, in space 
> mission operations I would expect to use just one service number for 
> all CFDP traffic.
>
> Certainly the well-known port numbers (e.g., 80) function as 
> next-protocol identifiers at the transport layer in the same way that

> protocol numbers function as next-protocol identifiers at the network

> layer.  But not all TCP and UDP port numbers are well-known, and I 
> suspect that in operations it will turn out that all CBHE service 
> numbers will indeed need to be well-known; I think they will act more

> like protocol identifiers.
>
> However, it doesn't really matter.  The service number is an 
> intra-node disambiguator and de-multiplexor that you can use in 
> whatever way makes sense for whatever protocol(s) live directly on
top 
> of DTN, and we can think of it in whatever way is most comfortable
for 
> us.
>
>> Does the restriction that the service number of the report-to EIDs
be
>> zero mean that there's no chance for application interaction with
the
>> reports?  That is, since there's not a defined bundle protocol
action
>> on receipt of a bundle status report, what would requesting such
>> reports effect?  I suppose it means that one could still obtain
>> diagnostic information by snooping the wire at the report-to element
>> number, but the parts of bundlePing that print out status report
>> information would stop working.
>
> The reasoning here is that, if service number is a protocol 
> identifier, then the only application that can possibly interact with

> the reports is the one that handles status reports.  The analogy is 
> that status reports are to BP as SNMP messages are to IP.
> Certainly there's nothing to prevent a single application 
> task/process/thread from having bundles delivered to it at two 
> different BP endpoints (i.e., speaking two upper-layer protocols), 
> both of which are located at the same node (i.e., in both of which 
> this node is registered).  In the operational scenarios I'm looking
at 
> it probably makes more sense for one report-handling application 
> process to be examining each status report and dispatching them in 
> various ways depending on (say) the source/destination service
numbers 
> of the bundles to which they apply.
>
> I haven't thought much about bundlePing and don't know exactly how 
> best to support it, but I suspect there's a fairly straightforward 
> way.  I need to read up more on how IP ping works.
>
>> Requiring the source and destination service numbers of
CBHE-compressed
>> bundles to be identical is somewhat problematic.  This would make it
>> difficult, for example, to differentiate between a server and client
>> application running on the same machine.
>
> Actually I think there might be a quite easy way to do this: the 
> messages from the client to the server would be assigned one service 
> number ("XXX queries") and the responses from the server to the
client 
> would be assigned another service number ("XXX responses").
Thinking about this some more since last night, though, I can see a 
valid counter-argument.

DTN endpoint IDs are supposed to be sufficient in themselves for both 
routing and demultiplexing purposes.  In this sense, bundle protocol 
combines into a single protocol the capabilities of IP (routing) and
UDP 
(multiplexing); if you squint and look at the UDP header as a secondary

IP header rather than a distinct layer of protocol, then you can think 
of UDP/IP as covering the same sort of territory as BP.

IP doesn't need a demux token because that token is provided by 
protocols at the layer above it -- UDP and TCP port numbers -- and in 
working out CBHE I was following that model: for the CBHE-based DTN 
traffic I was looking at, demux tokens would indeed be provided by 
protocols at the layer above BP -- CFDP entity IDs, AMS node numbers.  
But of course that's kind of layerist; sticking to that model would 
require that there always be some sort of additional layer of protocol 
above BP for de-muxing when you use CBHE (or at best you'd need an 
extension block for generalized demux tokens).  That wouldn't really be

in the spirit of the bundle protocol design.

So okay, recognizing that it's useful to enable service numbers to
serve 
the same sort of function as port numbers, let's change CBHE around.  I

still want to stick to doing no more than redefining the semantics of 
those eight DSNVs in the primary block (to make it easy for 
convergence-layer adapters to handle both compressed and non-compressed

bundles), so the best approach seems to be this:

1.   Use just one SDNV for scheme number, which must be common to all 
four EIDs rather than just to the source and reply-to.  (This is the
way 
CBHE was defined before version 5 of BP anyway.)  Bundles can still
flow 
readily between endpoints whose IDs have different schemes -- they just

can't be compressed.  Since there has to date been zero inter-scheme 
traffic in all DTN testing that I can think of, this should impose no 
great hardship; CBHE helps to optimize intra-scheme traffic and doesn't

inhibit (non-existent) inter-scheme traffic, so the focus seems
appropriate.

2.   That frees up two SDNVs for service numbers, so we can carry 
distinct service numbers for the destination, source, and report-to 
endpoints; the service number for the current custodian endpoint
remains 
a constant zero.

So now (a) the destination and source service numbers can be different,

acting as port numbers where this is useful, and (b) the report-to 
service number can be a number other than zero, which may be helpful
for 
applications like bundlePing.

Scott

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] an Internet Draft for CBHE
Date: Wed, 27 Dec 2006 16:21:47 -0500
From: "Scott, Keith L." <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "DTNRG" <[email-masked]>
Sender: [email-masked]

Sorry, I quickly skimmed and thought this morning's post was just an
errant repost of last night's.  I like what you have here a lot better.
I think that allowing for different service numbers in the various EIDs
makes the approach a lot more flexible.

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
Sent: Wednesday, December 27, 2006 11:41 AM
To: DTNRG
Subject: Re: [dtn-interest] an Internet Draft for CBHE

Scott Burleigh wrote:
> Scott, Keith L. wrote:
>> Page 4 of the intro: you state that:
>>
>>   "By convention, service number is a numeric value that is
>> functionally
>>    similar to the protocol number in an IP packet, characterizing
>> bundle
>>    payload."
>>
>> I suspect you really intend for the service number in CBHE bundles
to
>> be functionally similar to the port number in a transport layer
(e.g.
>> TCP, UDP) packet.  The protocol number in an IP packet identifies
the
>> next protocol, which is typically one of (TCP,UDP,IPSEC ESP).  The
>> protocol number does not provide (much) direct information about the
>> application being used.
>
> Thanks, Keith, a very reasonable question.  Actually I do
specifically 
> mean protocol number, because I look at BP as being functionally 
> similar to IP rather than to TCP or UDP.  For example, in space 
> mission operations I would expect to use just one service number for 
> all CFDP traffic.
>
> Certainly the well-known port numbers (e.g., 80) function as 
> next-protocol identifiers at the transport layer in the same way that

> protocol numbers function as next-protocol identifiers at the network

> layer.  But not all TCP and UDP port numbers are well-known, and I 
> suspect that in operations it will turn out that all CBHE service 
> numbers will indeed need to be well-known; I think they will act more

> like protocol identifiers.
>
> However, it doesn't really matter.  The service number is an 
> intra-node disambiguator and de-multiplexor that you can use in 
> whatever way makes sense for whatever protocol(s) live directly on
top 
> of DTN, and we can think of it in whatever way is most comfortable
for 
> us.
>
>> Does the restriction that the service number of the report-to EIDs
be
>> zero mean that there's no chance for application interaction with
the
>> reports?  That is, since there's not a defined bundle protocol
action
>> on receipt of a bundle status report, what would requesting such
>> reports effect?  I suppose it means that one could still obtain
>> diagnostic information by snooping the wire at the report-to element
>> number, but the parts of bundlePing that print out status report
>> information would stop working.
>
> The reasoning here is that, if service number is a protocol 
> identifier, then the only application that can possibly interact with

> the reports is the one that handles status reports.  The analogy is 
> that status reports are to BP as SNMP messages are to IP.
> Certainly there's nothing to prevent a single application 
> task/process/thread from having bundles delivered to it at two 
> different BP endpoints (i.e., speaking two upper-layer protocols), 
> both of which are located at the same node (i.e., in both of which 
> this node is registered).  In the operational scenarios I'm looking
at 
> it probably makes more sense for one report-handling application 
> process to be examining each status report and dispatching them in 
> various ways depending on (say) the source/destination service
numbers 
> of the bundles to which they apply.
>
> I haven't thought much about bundlePing and don't know exactly how 
> best to support it, but I suspect there's a fairly straightforward 
> way.  I need to read up more on how IP ping works.
>
>> Requiring the source and destination service numbers of
CBHE-compressed
>> bundles to be identical is somewhat problematic.  This would make it
>> difficult, for example, to differentiate between a server and client
>> application running on the same machine.
>
> Actually I think there might be a quite easy way to do this: the 
> messages from the client to the server would be assigned one service 
> number ("XXX queries") and the responses from the server to the
client 
> would be assigned another service number ("XXX responses").
Thinking about this some more since last night, though, I can see a 
valid counter-argument.

DTN endpoint IDs are supposed to be sufficient in themselves for both 
routing and demultiplexing purposes.  In this sense, bundle protocol 
combines into a single protocol the capabilities of IP (routing) and
UDP 
(multiplexing); if you squint and look at the UDP header as a secondary

IP header rather than a distinct layer of protocol, then you can think 
of UDP/IP as covering the same sort of territory as BP.

IP doesn't need a demux token because that token is provided by 
protocols at the layer above it -- UDP and TCP port numbers -- and in 
working out CBHE I was following that model: for the CBHE-based DTN 
traffic I was looking at, demux tokens would indeed be provided by 
protocols at the layer above BP -- CFDP entity IDs, AMS node numbers.  
But of course that's kind of layerist; sticking to that model would 
require that there always be some sort of additional layer of protocol 
above BP for de-muxing when you use CBHE (or at best you'd need an 
extension block for generalized demux tokens).  That wouldn't really be

in the spirit of the bundle protocol design.

So okay, recognizing that it's useful to enable service numbers to
serve 
the same sort of function as port numbers, let's change CBHE around.  I

still want to stick to doing no more than redefining the semantics of 
those eight DSNVs in the primary block (to make it easy for 
convergence-layer adapters to handle both compressed and non-compressed

bundles), so the best approach seems to be this:

1.   Use just one SDNV for scheme number, which must be common to all 
four EIDs rather than just to the source and reply-to.  (This is the
way 
CBHE was defined before version 5 of BP anyway.)  Bundles can still
flow 
readily between endpoints whose IDs have different schemes -- they just

can't be compressed.  Since there has to date been zero inter-scheme 
traffic in all DTN testing that I can think of, this should impose no 
great hardship; CBHE helps to optimize intra-scheme traffic and doesn't

inhibit (non-existent) inter-scheme traffic, so the focus seems
appropriate.

2.   That frees up two SDNVs for service numbers, so we can carry 
distinct service numbers for the destination, source, and report-to 
endpoints; the service number for the current custodian endpoint
remains 
a constant zero.

So now (a) the destination and source service numbers can be different,

acting as port numbers where this is useful, and (b) the report-to 
service number can be a number other than zero, which may be helpful
for 
applications like bundlePing.

Scott

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] an Internet Draft for CBHE
Date: Wed, 27 Dec 2006 15:53:41 -0500
From: "Scott, Keith L." <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "DTNRG" <[email-masked]>
Sender: [email-masked]

Scott,

Regardless of the layer with which one chooses to associate the bundle
protocol, the service number is,  I think, used to identify a
particular application within a node, right?  Unless and until somebody
builds a transport protocol over the bundle layer?  To my mind that
makes the service number more akin to a port number rather than a
protocol number (there are lots of port numbers, few(er) protocol
numbers).  I think that using one service number for CFDP bears this
out (unless you view CFDP as a transport protocol, which might be
reasonable).  I do agree on your description of the function.

The point with status reports was that applications are the entities
that request such reports, and there's no BP-layer defined action on
their receipt.  But I see now that you envision a common status report
handling application (at least common to all applications on a given
node).  If that's an assertion, that's fine; it maps to policy that
forces the report-to EIDs to all map to the zero service number.
Applications that aren't expecting this (and I suspect this would
include most diagnostic applications written for DTN) would get
confused in a CBHE environment.

I have always thought of custody transfer indications and the status
reports as being very different beasts, since in my model the status
reports as being consumed by the applications that requested them (or
their surrogates, if the report-to EID is different from the source
EID).  I suppose applications could register on service number zero to
get the reports of all applications, along with copies of all the
custody transfer indications.  This may make sense in CBHE environments
where there is a greater degree of administrative control.

As to restricting the service numbers to be the same for the source and
destination, yes, using two different service numbers will
differentiate the directions, but it restricts you to a single instance
of an application per node (unless you require the applications to add
their own demux information).  Again, for space or other
highly-constrained environments where you have strong administrative
control over all the nodes, this may be OK.

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
Sent: Tuesday, December 26, 2006 10:20 PM
To: DTNRG
Subject: Re: [dtn-interest] an Internet Draft for CBHE

Scott, Keith L. wrote:
> Page 4 of the intro: you state that:
> 
>   "By convention, service number is a numeric value that is
> functionally
>    similar to the protocol number in an IP packet, characterizing
> bundle
>    payload."
> 
> I suspect you really intend for the service number in CBHE bundles to
> be functionally similar to the port number in a transport layer (e.g.
> TCP, UDP) packet.  The protocol number in an IP packet identifies the
> next protocol, which is typically one of (TCP,UDP,IPSEC ESP).  The
> protocol number does not provide (much) direct information about the
> application being used.

Thanks, Keith, a very reasonable question.  Actually I do specifically
mean protocol number, because I look at BP as being functionally
similar to IP rather than to TCP or UDP.  For example, in space mission
operations I would expect to use just one service number for all CFDP
traffic.

Certainly the well-known port numbers (e.g., 80) function as
next-protocol identifiers at the transport layer in the same way that
protocol numbers function as next-protocol identifiers at the network
layer.  But not all TCP and UDP port numbers are well-known, and I
suspect that in operations it will turn out that all CBHE service
numbers will indeed need to be well-known; I think they will act more
like protocol identifiers.

However, it doesn't really matter.  The service number is an intra-node
disambiguator and de-multiplexor that you can use in whatever way makes
sense for whatever protocol(s) live directly on top of DTN, and we can
think of it in whatever way is most comfortable for us.

> Does the restriction that the service number of the report-to EIDs be
> zero mean that there's no chance for application interaction with the
> reports?  That is, since there's not a defined bundle protocol action
> on receipt of a bundle status report, what would requesting such
> reports effect?  I suppose it means that one could still obtain
> diagnostic information by snooping the wire at the report-to element
> number, but the parts of bundlePing that print out status report
> information would stop working.

The reasoning here is that, if service number is a protocol identifier,
then the only application that can possibly interact with the reports
is the one that handles status reports.  The analogy is that status
reports are to BP as SNMP messages are to IP. 

Certainly there's nothing to prevent a single application
task/process/thread from having bundles delivered to it at two
different BP endpoints (i.e., speaking two upper-layer protocols), both
of which are located at the same node (i.e., in both of which this node
is registered).  In the operational scenarios I'm looking at it
probably makes more sense for one report-handling application process
to be examining each status report and dispatching them in various ways
depending on (say) the source/destination service numbers of the
bundles to which they apply.

I haven't thought much about bundlePing and don't know exactly how best
to support it, but I suspect there's a fairly straightforward way.  I
need to read up more on how IP ping works.

> Requiring the source and destination service numbers of
CBHE-compressed
> bundles to be identical is somewhat problematic.  This would make it
> difficult, for example, to differentiate between a server and client
> application running on the same machine.

Actually I think there might be a quite easy way to do this: the
messages from the client to the server would be assigned one service
number ("XXX queries") and the responses from the server to the client
would be assigned another service number ("XXX responses").

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Scott
> Burleigh
> Sent: Thursday, December 21, 2006 7:32 PM
> To: DTNRG
> Subject: [dtn-interest] an Internet Draft for CBHE
> 
> Hi.  Here's my first cut at an Internet draft for the Compressed
Bundle
> 
> Header Encoding conventions I'm using in the ION implementation of
the 
> Bundle Protocol, updated per version 5 of the protocol.  (I haven't
yet
> 
> modified the code to catch up to these changes [i.e., using 8 SDNVs
in 
> the primary block] but hope to get that done by the end of next
month.)
> 
> I'd like to submit it to IETF some time in January; any comments?
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Date: Wed, 27 Dec 2006 08:40:50 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Scott Burleigh wrote:
> Scott, Keith L. wrote:
>> Page 4 of the intro: you state that:
>>
>>   "By convention, service number is a numeric value that is
>> functionally
>>    similar to the protocol number in an IP packet, characterizing
>> bundle
>>    payload."
>>
>> I suspect you really intend for the service number in CBHE bundles to
>> be functionally similar to the port number in a transport layer (e.g.
>> TCP, UDP) packet.  The protocol number in an IP packet identifies the
>> next protocol, which is typically one of (TCP,UDP,IPSEC ESP).  The
>> protocol number does not provide (much) direct information about the
>> application being used.
>
> Thanks, Keith, a very reasonable question.  Actually I do specifically 
> mean protocol number, because I look at BP as being functionally 
> similar to IP rather than to TCP or UDP.  For example, in space 
> mission operations I would expect to use just one service number for 
> all CFDP traffic.
>
> Certainly the well-known port numbers (e.g., 80) function as 
> next-protocol identifiers at the transport layer in the same way that 
> protocol numbers function as next-protocol identifiers at the network 
> layer.  But not all TCP and UDP port numbers are well-known, and I 
> suspect that in operations it will turn out that all CBHE service 
> numbers will indeed need to be well-known; I think they will act more 
> like protocol identifiers.
>
> However, it doesn't really matter.  The service number is an 
> intra-node disambiguator and de-multiplexor that you can use in 
> whatever way makes sense for whatever protocol(s) live directly on top 
> of DTN, and we can think of it in whatever way is most comfortable for 
> us.
>
>> Does the restriction that the service number of the report-to EIDs be
>> zero mean that there's no chance for application interaction with the
>> reports?  That is, since there's not a defined bundle protocol action
>> on receipt of a bundle status report, what would requesting such
>> reports effect?  I suppose it means that one could still obtain
>> diagnostic information by snooping the wire at the report-to element
>> number, but the parts of bundlePing that print out status report
>> information would stop working.
>
> The reasoning here is that, if service number is a protocol 
> identifier, then the only application that can possibly interact with 
> the reports is the one that handles status reports.  The analogy is 
> that status reports are to BP as SNMP messages are to IP.
> Certainly there's nothing to prevent a single application 
> task/process/thread from having bundles delivered to it at two 
> different BP endpoints (i.e., speaking two upper-layer protocols), 
> both of which are located at the same node (i.e., in both of which 
> this node is registered).  In the operational scenarios I'm looking at 
> it probably makes more sense for one report-handling application 
> process to be examining each status report and dispatching them in 
> various ways depending on (say) the source/destination service numbers 
> of the bundles to which they apply.
>
> I haven't thought much about bundlePing and don't know exactly how 
> best to support it, but I suspect there's a fairly straightforward 
> way.  I need to read up more on how IP ping works.
>
>> Requiring the source and destination service numbers of CBHE-compressed
>> bundles to be identical is somewhat problematic.  This would make it
>> difficult, for example, to differentiate between a server and client
>> application running on the same machine.
>
> Actually I think there might be a quite easy way to do this: the 
> messages from the client to the server would be assigned one service 
> number ("XXX queries") and the responses from the server to the client 
> would be assigned another service number ("XXX responses").
Thinking about this some more since last night, though, I can see a 
valid counter-argument.

DTN endpoint IDs are supposed to be sufficient in themselves for both 
routing and demultiplexing purposes.  In this sense, bundle protocol 
combines into a single protocol the capabilities of IP (routing) and UDP 
(multiplexing); if you squint and look at the UDP header as a secondary 
IP header rather than a distinct layer of protocol, then you can think 
of UDP/IP as covering the same sort of territory as BP.

IP doesn't need a demux token because that token is provided by 
protocols at the layer above it -- UDP and TCP port numbers -- and in 
working out CBHE I was following that model: for the CBHE-based DTN 
traffic I was looking at, demux tokens would indeed be provided by 
protocols at the layer above BP -- CFDP entity IDs, AMS node numbers.  
But of course that's kind of layerist; sticking to that model would 
require that there always be some sort of additional layer of protocol 
above BP for de-muxing when you use CBHE (or at best you'd need an 
extension block for generalized demux tokens).  That wouldn't really be 
in the spirit of the bundle protocol design.

So okay, recognizing that it's useful to enable service numbers to serve 
the same sort of function as port numbers, let's change CBHE around.  I 
still want to stick to doing no more than redefining the semantics of 
those eight DSNVs in the primary block (to make it easy for 
convergence-layer adapters to handle both compressed and non-compressed 
bundles), so the best approach seems to be this:

1.   Use just one SDNV for scheme number, which must be common to all 
four EIDs rather than just to the source and reply-to.  (This is the way 
CBHE was defined before version 5 of BP anyway.)  Bundles can still flow 
readily between endpoints whose IDs have different schemes -- they just 
can't be compressed.  Since there has to date been zero inter-scheme 
traffic in all DTN testing that I can think of, this should impose no 
great hardship; CBHE helps to optimize intra-scheme traffic and doesn't 
inhibit (non-existent) inter-scheme traffic, so the focus seems appropriate.

2.   That frees up two SDNVs for service numbers, so we can carry 
distinct service numbers for the destination, source, and report-to 
endpoints; the service number for the current custodian endpoint remains 
a constant zero.

So now (a) the destination and source service numbers can be different, 
acting as port numbers where this is useful, and (b) the report-to 
service number can be a number other than zero, which may be helpful for 
applications like bundlePing.

Scott

Date: Wed, 27 Dec 2006 14:03:08 +0000
From: Stephen Farrell <[email-masked]>
To: Sally Floyd <[email-masked]>
CC: DTN <[email-masked]>
Subject: [dtn-interest] Re: [IRSG] Looking for reviewers for dtnrg's bundle protocol spec...
Sender: [email-masked]

Thanks Sally!

I can answer your "intended status" question: this, as, I
believe, all IRTF protocol specs, is targeted at becoming
an experimental RFC. So, not on the standards-track, but
it is apropriate to use MUST/SHOULD etc.

Cc'ing the dtn-interest list, so DTNRG get to see your good
comments,

Stephen.

Sally Floyd wrote:
> My review for draft-irtf-dtnrg-bundle-spec-08 is below.
> 
> - Sally
> http://www.icir.org/floyd/
> 
> Review of Bundle Protocol Specification,
> draft-irtf-dtnrg-bundle-spec-08.txt.
> 
> I read the Bundle Protocol Specification, and it seems ok to me.
> My feedback below is mostly about presentation.
> 
> IRTF and standards documents:
> It is a little odd to read an IRTF document that is so clearly a
> protocol specification, instead of a description of an architecture
> as in draft-irtf-dtnrg-arch.  (E.g., the document specifies block
> headers, and uses occasional RFC-2119 language (RECOMMENDED,
> OPTIONAL).) I assume the IRTF guidelines are that this is ok?
> Is this intended for Informational, or something else?
> 
> Presentation:
> Compared to draft-irtf-dtnrg-arch, this is not an easy-to-read
> document.  The writing is not the clearest - it strikes me as overly
> formal.  It would be worth considering whether the suggestions in
> RFC 4101 on "Writing Protocol Models" would be useful to make the
> document more readable.  (I understand that draft-irtf-dtnrg-bundle-spec
> builds on the general presentation in draft-irtf-dtnrg-arch, but
> even so, it is possible that more could be done.)  An example of a
> section written in part in response to RFC 4101 is the Overview
> (Section 4) of RFC 4340.
> 
> 
> Example Suggestions about Presentation:
> Some examples about presentation are given below.
> 
> I would have found a paragraph at the end of Section 1 useful
> saying "Section 2 will do this" and "Section 3 will do that".
> I kept waiting for the discussion of the protocol, and it isn't
> really there.
> 
> In Section 2.1, when it says that a bundle consists of two or more
> blocks, it would be good to add a reference to Section 3.
> 
> Section 2.1:
> "utilizes" -> "uses"
> 
> "The application agent in turn has two elements, an
> administrative element and an application-specific element." ->
> "The application agent has an
> administrative element and possibly an application-specific element."
> 
> In the definition of a registration, I would say in the first
> sentence that a registration is either active or passive.
> E.g., "A registration characterizes a node's membership in a
> bundle endpoint, and at any time is either Active or Passive."
> 
> Section 2.1, last sentence:
> You might want to say here that a bundle has at most one custodian.
> 
> Section 3.2, first sentence:
> A pointer to Section 3.6 for the discussion of the primary bundle
> block would be useful.
> 
> Section 3.3:
> "The significance of the values in all currently defined positions of
> this bit string, in order from least-significant position (labeled
> '1') to most-significant (labeled '21'), are described here." ->
> "The Bundle Processing Control Flags field is described here
> (starting with the least-significant bit position, labeled '1') ."
> 
> Even better would be a graphic:
> 
>    0                          1                             2
>    1  2  3  4  5  6  7  8  9  0  1  2  3  4  5  6  7  8  9  0  1
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
>   |  General flags     |  Class of Service  |   Status Report    |
>   |                    |                    |   Request Flags    |
>   +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
> 
> (Or for better formatting:  
> 
> (Though the graphic could look better labeling the
> least significant bit as '0' instead of '1'.)
> 
> Section 3.6:
> Why not say the following:
> "All of fields that are SDNVs are of variable-length.  The field
> sizes shown here for SDNVs are for convenience in representation."
> Instead of having to say it again for every field.
> 
> In some places Bundle Protocol is capitalized, but in other places
> it isn't.  "bundle protocol agent" -> "Bundle Protocol agent" or
> "BP agent"?  (From someone who is used to "TCP agent".)
> 
> In Section 4, 4.6 on "Bundle reception" could come earlier,
> (before "Bungle expiration", for example).
> 
> Section 6:  For the convergence layer, a short example of what
> is done in the convergence layer for TCP would be useful.
> 
> 
> Nits: The references need to be updated (for the ones that are
> internet-drafts).

Date: Tue, 26 Dec 2006 19:19:39 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

Scott, Keith L. wrote:
> Page 4 of the intro: you state that:
> 
>   "By convention, service number is a numeric value that is
> functionally
>    similar to the protocol number in an IP packet, characterizing
> bundle
>    payload."
> 
> I suspect you really intend for the service number in CBHE bundles to
> be functionally similar to the port number in a transport layer (e.g.
> TCP, UDP) packet.  The protocol number in an IP packet identifies the
> next protocol, which is typically one of (TCP,UDP,IPSEC ESP).  The
> protocol number does not provide (much) direct information about the
> application being used.

Thanks, Keith, a very reasonable question.  Actually I do specifically mean protocol number, because I look at BP as being functionally similar to IP rather than to TCP or UDP.  For example, in space mission operations I would expect to use just one service number for all CFDP traffic.

Certainly the well-known port numbers (e.g., 80) function as next-protocol identifiers at the transport layer in the same way that protocol numbers function as next-protocol identifiers at the network layer.  But not all TCP and UDP port numbers are well-known, and I suspect that in operations it will turn out that all CBHE service numbers will indeed need to be well-known; I think they will act more like protocol identifiers.

However, it doesn't really matter.  The service number is an intra-node disambiguator and de-multiplexor that you can use in whatever way makes sense for whatever protocol(s) live directly on top of DTN, and we can think of it in whatever way is most comfortable for us.

> Does the restriction that the service number of the report-to EIDs be
> zero mean that there's no chance for application interaction with the
> reports?  That is, since there's not a defined bundle protocol action
> on receipt of a bundle status report, what would requesting such
> reports effect?  I suppose it means that one could still obtain
> diagnostic information by snooping the wire at the report-to element
> number, but the parts of bundlePing that print out status report
> information would stop working.

The reasoning here is that, if service number is a protocol identifier, then the only application that can possibly interact with the reports is the one that handles status reports.  The analogy is that status reports are to BP as SNMP messages are to IP. 

Certainly there's nothing to prevent a single application task/process/thread from having bundles delivered to it at two different BP endpoints (i.e., speaking two upper-layer protocols), both of which are located at the same node (i.e., in both of which this node is registered).  In the operational scenarios I'm looking at it probably makes more sense for one report-handling application process to be examining each status report and dispatching them in various ways depending on (say) the source/destination service numbers of the bundles to which they apply.

I haven't thought much about bundlePing and don't know exactly how best to support it, but I suspect there's a fairly straightforward way.  I need to read up more on how IP ping works.

> Requiring the source and destination service numbers of CBHE-compressed
> bundles to be identical is somewhat problematic.  This would make it
> difficult, for example, to differentiate between a server and client
> application running on the same machine.

Actually I think there might be a quite easy way to do this: the messages from the client to the server would be assigned one service number ("XXX queries") and the responses from the server to the client would be assigned another service number ("XXX responses").

Scott

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Scott
> Burleigh
> Sent: Thursday, December 21, 2006 7:32 PM
> To: DTNRG
> Subject: [dtn-interest] an Internet Draft for CBHE
> 
> Hi.  Here's my first cut at an Internet draft for the Compressed Bundle
> 
> Header Encoding conventions I'm using in the ION implementation of the 
> Bundle Protocol, updated per version 5 of the protocol.  (I haven't yet
> 
> modified the code to catch up to these changes [i.e., using 8 SDNVs in 
> the primary block] but hope to get that done by the end of next month.)
> 
> I'd like to submit it to IETF some time in January; any comments?
> 
> Scott
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] an Internet Draft for CBHE
Date: Tue, 26 Dec 2006 12:22:47 -0500
From: "Scott, Keith L." <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, "DTNRG" <[email-masked]>
Sender: [email-masked]

Page 4 of the intro: you state that:

  "By convention, service number is a numeric value that is
functionally
   similar to the protocol number in an IP packet, characterizing
bundle
   payload."

I suspect you really intend for the service number in CBHE bundles to
be functionally similar to the port number in a transport layer (e.g.
TCP, UDP) packet.  The protocol number in an IP packet identifies the
next protocol, which is typically one of (TCP,UDP,IPSEC ESP).  The
protocol number does not provide (much) direct information about the
application being used.

Does the restriction that the service number of the report-to EIDs be
zero mean that there's no chance for application interaction with the
reports?  That is, since there's not a defined bundle protocol action
on receipt of a bundle status report, what would requesting such
reports effect?  I suppose it means that one could still obtain
diagnostic information by snooping the wire at the report-to element
number, but the parts of bundlePing that print out status report
information would stop working.

Requiring the source and destination service numbers of CBHE-compressed
bundles to be identical is somewhat problematic.  This would make it
difficult, for example, to differentiate between a server and client
application running on the same machine.

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott
Burleigh
Sent: Thursday, December 21, 2006 7:32 PM
To: DTNRG
Subject: [dtn-interest] an Internet Draft for CBHE

Hi.  Here's my first cut at an Internet draft for the Compressed Bundle

Header Encoding conventions I'm using in the ION implementation of the 
Bundle Protocol, updated per version 5 of the protocol.  (I haven't yet

modified the code to catch up to these changes [i.e., using 8 SDNVs in 
the primary block] but hope to get that done by the end of next month.)

I'd like to submit it to IETF some time in January; any comments?

Scott

Date: Thu, 21 Dec 2006 16:31:30 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] an Internet Draft for CBHE
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------090300080901090306080001
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi.  Here's my first cut at an Internet draft for the Compressed Bundle 
Header Encoding conventions I'm using in the ION implementation of the 
Bundle Protocol, updated per version 5 of the protocol.  (I haven't yet 
modified the code to catch up to these changes [i.e., using 8 SDNVs in 
the primary block] but hope to get that done by the end of next month.)  
I'd like to submit it to IETF some time in January; any comments?

Scott

--------------090300080901090306080001
Content-Type: text/plain;
 name="cbhe.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="cbhe.txt"

Delay-Tolerant Networking Research                           S. Burleigh
Group                                         Jet Propulsion Laboratory,
Internet-Draft                                  California Institute of
Intended status: Experimental                                 Technology
Expires: June 24, 2007                                 December 21, 2006

                Compressed Bundle Header Encoding (CBHE)
                           draft-irtf-cbhe-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on June 24, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document describes a convention for representing Delay-Tolerant
   Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a
   compressed manner within the primary blocks of bundles.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",

Burleigh                  Expires June 24, 2007                 [Page 1]

Internet-Draft                    CBHE                     December 2006

   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Compression convention  . . . . . . . . . . . . . . . . . . . . 3
   3.  Specification . . . . . . . . . . . . . . . . . . . . . . . . . 5
     3.1.  Transmission  . . . . . . . . . . . . . . . . . . . . . . . 6
     3.2.  Reception . . . . . . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

Burleigh                  Expires June 24, 2007                 [Page 2]

Internet-Draft                    CBHE                     December 2006

1.  Introduction

   This document describes a convention for representing Delay-Tolerant
   Networking (DTN) Bundle Protocol (BP) endpoint identifiers in a
   compressed manner within the primary blocks of bundles.

   Each DTN bundle's primary block contains four BP endpoint identifiers
   (EIDs), of which any two, any three, or even all four may be
   lexically identical: the endpoint identifiers of the source, the
   destination, the report-to endpoint, and the current custodian.  Each
   EID is a Uniform Record Identifier (URI), an ASCII string of the form
   "scheme_name:scheme_specific_part".

   A degree of block compression is provided by the design of the
   primary block: the scheme names and scheme-specific parts of the four
   endpoints' IDs - up to eight NULL-terminated strings - are
   concatenated at the end of the block in a variable-length character
   array called a "dictionary", enabling each EID to be represented by a
   pair of integers indicating the offsets (within the dictionary) of
   the EID's scheme name and scheme-specific part.  Duplicate strings
   may be omitted from the dictionary, so the actual number of
   concatenated NULL-terminated strings in the dictionary may be less
   than eight and two or more of the scheme name or scheme-specific part
   offsets in the block may have the same value.  Moreover, the eight
   offsets in the primary block are encoded as self-delimiting numeric
   values (SDNVs), which shrink to fit the encoded values; when the
   total length of the dictionary is less than 127 bytes, all eight
   offsets can be encoded into just eight bytes.

   However, these strategems do not prevent the scheme names and scheme-
   specific parts themselves from being arbitrary lengthy strings of
   ASCII text.  It is therefore still possible for the length of a
   bundle's primary header to be a very large fraction of the total
   length of the bundle when the bundle's payload is relatively small,
   as is anticipated for a number of DTN applications such as space
   flight operations.

   The Compressed Bundle Header Encoding (CBHE) convention was developed
   to improve DTN transmission efficiency for such applications by
   further reducing the number of bytes used to express EIDs in the
   primary blocks of bundles.

2.  Compression convention

   Compressed Bundle Header Encoding (CBHE) is possible only when the
   scheme names of all four endpoint IDs in the primary block of a given
   bundle identify schemes that are universally understood (within the

Burleigh                  Expires June 24, 2007                 [Page 3]

Internet-Draft                    CBHE                     December 2006

   network) to be "CBHE-conformant".

   All CBHE-conformant schemes are numbered and are identifiable by
   their numbers as well as their names.  A one-to-one correspondence
   between scheme numbers and the names of CBHE-conformant schemes is
   assumed to be well-known throughout the network (either by management
   or, as the scope of the network grows, by means of a protocol yet to
   be developed).

   The scheme-specific part of each entity-identifying URI whose scheme
   name identifies a CBHE-conformant scheme must be of the form
   "element_number.service_number".

   By convention, element number is a numeric value that can be thought
   of as a BP node identifier, such as a spacecraft identifier.  Element
   number zero is used to indicate the null endpoint; any EID whose
   scheme name identifies a CBHE-conformant scheme and whose element
   number is zero, regardless of service number, is interpreted within
   the CBHE convention as an alternative representation of the standard
   null endpoint ID "dtn:none".

   By convention, service number is a numeric value that is functionally
   similar to the protocol number in an IP packet, characterizing bundle
   payload.  Service numbers enable inbound bundles' application data
   units to be de-multiplexed to elements of application functionality
   that are designed to process them, so that symmetrical peer-to-peer
   communication relationships can be developed between bundle producers
   and consumers.  Service number zero is reserved for BP administrative
   record traffic (custody signals and status reports).

   Conversion of an EID in URI form - where the URI's scheme is CBHE-
   conformant - to and from a tuple of three integers is therefore
   straightforward.  This ease of conversion enables an array of
   integers to serve the same function as a dictionary of EID ASCII
   strings.

   CBHE representation of EIDs in a given bundle's primary block is
   further constrained as follows:

   o  Service number for both the Report-to EID and the Current
      Custodian EID must be zero, indicating administrative traffic.

   o  The scheme names for the bundle's Source and Report-to EIDs must
      be the same.

   o  The service numbers for the bundle's Source and Destination EIDs
      must be the same.

Burleigh                  Expires June 24, 2007                 [Page 4]

Internet-Draft                    CBHE                     December 2006

   When all these conditions are met, the CBHE block compression
   convention can be applied.  In a CBHE-compressed primary block, the
   eight SDNVs that normally contain EIDs' offsets within the dictionary
   are instead used to contain the eight integer values listed below, in
   the order shown; the dictionary is omitted from the primary block,
   and the primary block's dictionary length is set to zero.

   1.  The scheme number of the bundle's destination endpoint ID.

   2.  The element number of the destination endpoint ID.

   3.  The scheme number that is common to the source and report-to
       endpoint IDs.

   4.  The element number of the source endpoint ID.

   5.  The element number of the report-to endpoint ID.

   6.  The scheme number of the current custodian endpoint ID.

   7.  The element number of the current custodian endpoint ID.

   8.  The service number that is common to the destination and source
       endpoint IDs.

   This compression convention is applied at the convergence layer: the
   transmitting convergence-layer adaptation compresses the primary
   block as shown above, and upon reception the receiving convergence-
   layer adaptation de-compresses the block by simply reversing the
   process.

   Service numbers' semantic significance is generally scoped by scheme:
   definitions of all valid service numbers except zero (which is always
   reserved for administrative record traffic) are encompassed by the
   definition of any CBHE-conformant scheme.  For this reason, the
   source and destination endpoint IDs of a given bundle will typically
   be formed under the same scheme.  However, this is not mandatory: the
   source and destination endpoint IDs of a given bundle may be formed
   under different schemes so long as the indicated service number has
   the same semantic significance in both schemes.

3.  Specification

   CBHE compression is a convergence-layer adaptation.  It is opaque to
   bundle processing.  It therefore has no impact on the
   interoperability of different Bundle Protocol implementations, but
   instead affects only the interoperability of different convergence

Burleigh                  Expires June 24, 2007                 [Page 5]

Internet-Draft                    CBHE                     December 2006

   layer adaptation implementations.

3.1.  Transmission

   When and only when required by the bundle protocol agent to transmit
   a bundle whose source, destination, report-to, and custodian
   endpoints' IDs are either null ("dtn:none") or characterized by CBHE-
   conformant schemes, and whose report-to endpoint's ID is
   characterized by the same scheme as the source's ID, the convergence
   layer adapter should encode the primary block of the bundle in
   accordance with the CBHE compression convention described above, with
   these provisos:

   o  If and only if the scheme number that is common to the source and
      report-to endpoint IDs is the same as the scheme number of the
      destination endpoint ID, the source/report-to scheme number may
      instead be encoded as zero.

   o  If and only if the scheme number of the current custodian endpoint
      ID is the same as the scheme number of the destination endpoint
      ID, the current custodian scheme number may instead be encoded as
      zero.

3.2.  Reception

   Upon receiving a bundle whose dictionary length is zero (and only in
   this circumstance), the convergence layer adapter shall decode the
   primary block of the bundle in accordance with the CBHE compression
   convention described above, with the following provisos, before
   delivering it to the bundle protocol agent.

   o  If and only if the encoded source/report-to scheme number is zero,
      the source/report-to scheme number shall be decoded as the scheme
      number of the destination endpoint ID.

   o  If and only if the encoded current custodian scheme number is
      zero, the current custodian scheme number shall be decoded as the
      scheme number of the destination endpoint ID.

4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

Burleigh                  Expires June 24, 2007                 [Page 6]

Internet-Draft                    CBHE                     December 2006

5.  Security Considerations

   CBHE introduces no new security considerations beyond those discussed
   in the DTN Bundle Protocol and Bundle Security Protocol
   specifications.

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Author's Address

   Scott Burleigh
   Jet Propulsion Laboratory, California Institute of Technology
   4800 Oak Grove Drive, m/s 301-490
   Pasadena>, CA  91109
   USA

Burleigh                  Expires June 24, 2007                 [Page 7]

Internet-Draft                    CBHE                     December 2006

Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Burleigh                  Expires June 24, 2007                 [Page 8]


--------------090300080901090306080001--

Date: Tue, 19 Dec 2006 11:54:34 +0000
From: Stephen Farrell <[email-masked]>
To: Michael Welzl <[email-masked]>
CC: "Henderson, Thomas R" <[email-masked]>, Mark Allman <[email-masked]>, Internet Steering Group <[email-masked]>, [email-masked], Aaron Falk <[email-masked]>
Subject: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE JAN 9
Sender: [email-masked]

Thanks  for the prompt response Michael!

I'll hassle the authors on those points for an -09
version:-)

Cheers,
Stephen.

Michael Welzl wrote:
> Hi,
> 
> I think that this document is now ready to go forward.
> 
> Two comments:
> 
> * I'm glad to see that the document now explicitly states
>   that reports such as "Report When Bundle Deleted" are
>   meant for diagnostic purposes. I'm not saying that this
>   is an absolute necessity, but I think it would be
>   appropriate to also mention that the diagnostic reports
>   and delivery options should be used with care, as they
>   can open the door for attacks (e.g. DoS,   if e.g. a
>   custody is supposed to receive deletion reports
>   from bundles that were multicast)
> 
> * a nit: on page 18, in the sentence:
> 
> While G is transmitting a large bundle to S1, a reliable transport layer
> protocol below the bundle layer at each indicates the transmission has
> terminated, but that half the transfer has completed successfully.
> 
> it seems that there is missing something after "at each", like "hop", or
> "side".. (or there isn't, and it's just my lack of English skills -
> could be?)
> 
> Good job!
> 
> Cheers,
> Michael
> 
> 
> 
>> On Tue, 2006-12-19 at 12:43, Stephen Farrell wrote:
>> Hi all,
>>
>> The DTN architecture document has been updated [1] as a
>> result of the recent IRSG poll comments.
>>
>> Can the people who commented on this please check that the
>> new version resolves their comments, say before Jan 9th?
>> (That's the set of folks on the To: list of this message.)
>>
>> Having done a quick check, the highlights of the diffs [2] vs.
>> the comments that I believe are holding the document are:
>>
>> - Michael Welzl had concerns about reporting - those features
>> are now called out as optional and its explained how they are
>> for diagnostic purposes (I note in passing that they were
>> found to be useful for this during the interop in San Diego!)
>>
>> - Thomas Henderson had some problems with the EID term (and
>> terminology in general). There were some editorial changes
>> made, and it was pointed out that there is a terminology
>> section in the bundle specification draft [3], (which will
>> be starting its poll real soon now, btw).
>>
>> Let me know if there're others that I missed (I believe Mark
>> Allman's non-overlapping comments were not "holding" ones,
>> since he said that himself:-)
>>
>> Thanks,
>> Stephen.
>>
>>
>> [1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
>> [2] 
>> http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-irtf-dtnrg-arch-08.txt&url2=http://tools.ietf.org/id/draft-irtf-dtnrg-arch-07.txt
>> [3] http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-spec-08.txt
> 
> 

From: Michael Welzl <[email-masked]>
To: Stephen Farrell <[email-masked]>
Cc: "Henderson, Thomas R" <[email-masked]>, Mark Allman <[email-masked]>, Internet Steering Group <[email-masked]>, [email-masked], Aaron Falk <[email-masked]>
Organization: University of Innsbruck
Date: 19 Dec 2006 12:49:05 +0100
Subject: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE JAN 9
Sender: [email-masked]

Hi,

I think that this document is now ready to go forward.

Two comments:

* I'm glad to see that the document now explicitly states
  that reports such as "Report When Bundle Deleted" are
  meant for diagnostic purposes. I'm not saying that this
  is an absolute necessity, but I think it would be
  appropriate to also mention that the diagnostic reports
  and delivery options should be used with care, as they
  can open the door for attacks (e.g. DoS,   if e.g. a
  custody is supposed to receive deletion reports
  from bundles that were multicast)

* a nit: on page 18, in the sentence:

While G is transmitting a large bundle to S1, a reliable transport layer
protocol below the bundle layer at each indicates the transmission has
terminated, but that half the transfer has completed successfully.

it seems that there is missing something after "at each", like "hop", or
"side".. (or there isn't, and it's just my lack of English skills -
could be?)

Good job!

Cheers,
Michael

> On Tue, 2006-12-19 at 12:43, Stephen Farrell wrote:
> Hi all,
> 
> The DTN architecture document has been updated [1] as a
> result of the recent IRSG poll comments.
> 
> Can the people who commented on this please check that the
> new version resolves their comments, say before Jan 9th?
> (That's the set of folks on the To: list of this message.)
> 
> Having done a quick check, the highlights of the diffs [2] vs.
> the comments that I believe are holding the document are:
> 
> - Michael Welzl had concerns about reporting - those features
> are now called out as optional and its explained how they are
> for diagnostic purposes (I note in passing that they were
> found to be useful for this during the interop in San Diego!)
> 
> - Thomas Henderson had some problems with the EID term (and
> terminology in general). There were some editorial changes
> made, and it was pointed out that there is a terminology
> section in the bundle specification draft [3], (which will
> be starting its poll real soon now, btw).
> 
> Let me know if there're others that I missed (I believe Mark
> Allman's non-overlapping comments were not "holding" ones,
> since he said that himself:-)
> 
> Thanks,
> Stephen.
> 
> 
> [1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
> [2] 
> http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-irtf-dtnrg-arch-08.txt&url2=http://tools.ietf.org/id/draft-irtf-dtnrg-arch-07.txt
> [3] http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-spec-08.txt

Date: Tue, 19 Dec 2006 11:43:13 +0000
From: Stephen Farrell <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>, Michael Welzl <[email-masked]>, Mark Allman <[email-masked]>
CC: Internet Steering Group <[email-masked]>, [email-masked], Aaron Falk <[email-masked]>
Subject: [dtn-interest] Re: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE JAN 9
Sender: [email-masked]

Hi all,

The DTN architecture document has been updated [1] as a
result of the recent IRSG poll comments.

Can the people who commented on this please check that the
new version resolves their comments, say before Jan 9th?
(That's the set of folks on the To: list of this message.)

Having done a quick check, the highlights of the diffs [2] vs.
the comments that I believe are holding the document are:

- Michael Welzl had concerns about reporting - those features
are now called out as optional and its explained how they are
for diagnostic purposes (I note in passing that they were
found to be useful for this during the interop in San Diego!)

- Thomas Henderson had some problems with the EID term (and
terminology in general). There were some editorial changes
made, and it was pointed out that there is a terminology
section in the bundle specification draft [3], (which will
be starting its poll real soon now, btw).

Let me know if there're others that I missed (I believe Mark
Allman's non-overlapping comments were not "holding" ones,
since he said that himself:-)

Thanks,
Stephen.

[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt
[2] 
http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-irtf-dtnrg-arch-08.txt&url2=http://tools.ietf.org/id/draft-irtf-dtnrg-arch-07.txt
[3] http://tools.ietf.org/id/draft-irtf-dtnrg-bundle-spec-08.txt

From: Michael Demmer <[email-masked]>
Date: Mon, 18 Dec 2006 15:20:51 -0800
To: dtn-interest <[email-masked]>
Subject: [dtn-interest] DTN2 reference implementation release 2.3.0
Sender: [email-masked]

Hi all,

I'm pleased to announce a new release of the DTN2 reference  
implementation. The most recent excerpt from the RELEASE-NOTES is  
included below.

As always, this release is available at http://www.dtnrg.org/wiki/Code.

Happy bundling!
-mike

---

2.3.0 (December 2006)
---------------------

- Rewritten and documented TCP convergence layer, with support for
   bidirectional communication over a single socket.

- Default port used by TCP & UDP convergence layers is now 4556, newly
   registered with IANA.

- Improvements to the Bluetooth convergence layer (by Jeff Wilson) to
   use the same common stream based convergence layer base class as is
   used by TCP.

- Refactored bundle protocol handling code into separate block
   processing modules allowing for easier integration of security and
   other extension blocks.

- Integrated full support for extension blocks.

- External router interface (by MITRE) using XML to communicate
   between the router and the daemon.

- Initial support for a neighborhood discovery mechanism (by Jeff
   Wilson) using either UDP multicast/broadcast or Bluetooth's builtin
   service discovery protocols.

- Major enhancements to the Prophet router implementation (by Jeff
   Wilson).

- Added dtntunnel and dtncat applications. Reworked and enhanced the
   dtnping application.

- Modified the core for 64-bit compatibility.

- Various stability and performance improvements.

- Resurrection of the dtnsim simulator (by Seguti Gutierrez-Nolasco)
   for simple bundle transmission.

- Switched most of the code from the Intel Open Source License to the
   Apache License.

Reply-To: <[email-masked]>
From: "Kevin Fall" <[email-masked]>
To: <[email-masked]>
Date: Mon, 18 Dec 2006 08:58:16 -0800
Organization: Intel Research Berkeley
Subject: [dtn-interest] in case you didn't see it - DTN architecture -08
Sender: [email-masked]

A new revision [-08] of the DTN architecture document has been posted:

http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-arch-08.txt

- Kevin

Date: Wed, 06 Dec 2006 13:39:06 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] revised CBHE
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030107030601090607090502
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Since in version 5 of the Bundle Protocol spec we have now revised the 
representation of the values in the bundle primary block (lots of 
SDNVs), I am tweaking the proposed Compressed Bundle Header Encoding 
spec accordingly.  See attached.

This actually works out pretty nicely: having eight SDNVs to work with 
rather than a fixed array of 16 bytes opens the possibility of the 
source, destination, and/or custodian EIDs being in different schemes 
without having to go outside of CBHE, and it also removes all arbitrary 
upper limits on scheme numbers, element numbers, and service numbers.  
Taken together, these changes remove the constraints on the scalability 
of CBHE that always sort of bothered me.

At the same time, using SDNVs makes it possible to shrink CBHE-encoded 
primary bundle headers from 34 bytes down to as few as 23 bytes for an 
extremely small DTN, which interplanetary space is likely to remain for 
the next decade or so.

I'll be starting on turning this into an Internet Draft later this 
month.  Any comments?

Scott

--------------030107030601090607090502
Content-Type: application/msword;
 name="cbhe2.doc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
 filename="cbhe2.doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZAAAAAAA
AAAAEAAAZgAAAAEAAAD+////AAAAAGMAAAD/////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
--------------030107030601090607090502--

Subject: Re: [dtn-interest] RG finished with bundle spec?
From: Rajesh Krishnan <[email-masked]>
Reply-To: [email-masked]
To: DTN <[email-masked]>
Cc: [email-masked], [email-masked], Steve Polit <[email-masked]>
Organization: BBN Technologies
Date: Wed, 06 Dec 2006 16:31:22 -0500
Sender: [email-masked]

The specifications looks good to us.  Ship it soon.

-Rajesh, on behalf of the BBN SPINDLE team

On Wed, 2006-12-06 at 07:18 -0800, Scott Burleigh wrote:
> Stephen Farrell wrote:
> >
> > Hi all,
> >
> > Following recent minor(-ish) changes and the successful interop
> > in San Diego, Scott and Keith have posted a new version of the
> > bundle spec [1].
> >
> > In San Diego I asked whether we should now start the process
> > of making this an RFC and there was consensus in the room
> > that we should. That involves me getting an IRSG review of
> > the document and handling any comments etc.
> >
> > But, before I do that, I'd like to get a few positive acks
> > that we generally agree that the document is ready to
> > progress.
> >
> > So, if you do think that, can you respond to this on the
> > list saying so?

From: "Peter Lovell" <[email-masked]>
To: "Scott, Keith L." <[email-masked]>, DTN <[email-masked]>
Cc: "Scott Burleigh" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Subject: Re(2): [dtn-interest] RG finished with bundle spec?
Date: Wed, 6 Dec 2006 10:21:50 -0500
Sender: [email-masked]

>OK, here's a version -08 that should be better.  Editorial changes
>only.  I'll submit this later today unless somebody finds
>something......else.......wrong...
>
>		--keith

Hi Keith,

this is indeed better. 

Thanks.....Peter

Date: Wed, 06 Dec 2006 07:18:35 -0800
From: Scott Burleigh <[email-masked]>
To: DTN <[email-masked]>
Subject: Re: [dtn-interest] RG finished with bundle spec?
Sender: [email-masked]

Stephen Farrell wrote:
>
> Hi all,
>
> Following recent minor(-ish) changes and the successful interop
> in San Diego, Scott and Keith have posted a new version of the
> bundle spec [1].
>
> In San Diego I asked whether we should now start the process
> of making this an RFC and there was consensus in the room
> that we should. That involves me getting an IRSG review of
> the document and handling any comments etc.
>
> But, before I do that, I'd like to get a few positive acks
> that we generally agree that the document is ready to
> progress.
>
> So, if you do think that, can you respond to this on the
> list saying so?
I think it's ready, Stephen.  Thanks for wrangling this.

Scott

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] RG finished with bundle spec?
Date: Wed, 6 Dec 2006 09:53:13 -0500
From: "Weiss, Howard" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Sender: [email-masked]

Yes,

Howie

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Stephen
Farrell
Sent: Wednesday, December 06, 2006 7:30 AM
To: DTN
Subject: [dtn-interest] RG finished with bundle spec?

Hi all,

Following recent minor(-ish) changes and the successful interop
in San Diego, Scott and Keith have posted a new version of the
bundle spec [1].

In San Diego I asked whether we should now start the process
of making this an RFC and there was consensus in the room
that we should. That involves me getting an IRSG review of
the document and handling any comments etc.

But, before I do that, I'd like to get a few positive acks
that we generally agree that the document is ready to
progress.

So, if you do think that, can you respond to this on the
list saying so? (Please don't start discussing things in
this thread, if there's something you want to discuss,
start a new thread, e.g. there are still some formatting
things to fix, but that's ok for now.)

And FWIW, I do think this is very ready to be an RFC.

Thanks,
Stephen.

[1]
http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-07.txt

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] RG finished with bundle spec?
Date: Wed, 6 Dec 2006 09:51:46 -0500
From: "Scott, Keith L." <[email-masked]>
To: "DTN" <[email-masked]>
Cc: "Peter Lovell" <[email-masked]>, "Scott Burleigh" <[email-masked]>, "Stephen Farrell" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C71946.0F958723
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

OK, here's a version -08 that should be better.  Editorial changes
only.  I'll submit this later today unless somebody finds
something......else.......wrong...

		--keith

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Scott, Keith
L.
Sent: Wednesday, December 06, 2006 8:34 AM
To: Peter Lovell; Stephen Farrell; DTN
Subject: RE: [dtn-interest] RG finished with bundle spec?

OK, now I see.  And they don't show up 'wrong' under, say, wordpad,
since it's happy to use the same extended character set as MS word.
I'll submit a -08 version today to (hopefully) kill this.

Anybody with formatting issues, please send to me ASAP.

		--keith=20

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter Lovell
Sent: Wednesday, December 06, 2006 8:23 AM
To: Stephen Farrell; DTN
Subject: Re: [dtn-interest] RG finished with bundle spec?

>... I do think this is very ready to be an RFC.

The funky characters are still there, though (artifacts of MS Word). I
a
browser they show up as question marks inside a black diamond.

Cheers.....Peter

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

------_=_NextPart_001_01C71946.0F958723
Content-Type: text/plain;
	name="draft-irtf-dtnrg-bundle-spec-08.txt"
Content-Transfer-Encoding: base64
Content-Description: draft-irtf-dtnrg-bundle-spec-08.txt
Content-Disposition: attachment;
	filename="draft-irtf-dtnrg-bundle-spec-08.txt"

------_=_NextPart_001_01C71946.0F958723--

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] RG finished with bundle spec?
Date: Wed, 6 Dec 2006 09:47:58 -0500
From: "Durst, Robert C." <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Sender: [email-masked]

Yes.  Do.  Quickly.   

Durst.

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of 
>Stephen Farrell
>Sent: Wednesday, December 06, 2006 7:30 AM
>To: DTN
>Subject: [dtn-interest] RG finished with bundle spec?
>
>
>Hi all,
>
>Following recent minor(-ish) changes and the successful interop
>in San Diego, Scott and Keith have posted a new version of the
>bundle spec [1].
>
>In San Diego I asked whether we should now start the process
>of making this an RFC and there was consensus in the room
>that we should. That involves me getting an IRSG review of
>the document and handling any comments etc.
>
>But, before I do that, I'd like to get a few positive acks
>that we generally agree that the document is ready to
>progress.
>
>So, if you do think that, can you respond to this on the
>list saying so? (Please don't start discussing things in
>this thread, if there's something you want to discuss,
>start a new thread, e.g. there are still some formatting
>things to fix, but that's ok for now.)
>
>And FWIW, I do think this is very ready to be an RFC.
>
>Thanks,
>Stephen.
>
>
>[1] 
>http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-07.tx
t
>
>_______________________________________________
>dtn-interest mailing list
>[email-masked]
>http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

Date: Wed, 06 Dec 2006 13:52:04 +0000
From: Stephen Farrell <[email-masked]>
To: "Scott, Keith L." <[email-masked]>
Cc: Peter Lovell <[email-masked]>, DTN <[email-masked]>
Subject: BP spec formatting (was: Re: [dtn-interest] RG finished with bundle spec?)
Sender: [email-masked]

Changing the subject.

There are also some non-indented lines (diagrams, near the
end).

But, there'll be plenty of time to fix formatting, there's
no need to rush with that IMO,

S.

Scott, Keith L. wrote:
> OK, now I see.  And they don't show up 'wrong' under, say, wordpad,
> since it's happy to use the same extended character set as MS word.
> I'll submit a -08 version today to (hopefully) kill this.
> 
> Anybody with formatting issues, please send to me ASAP.
> 
> 		--keith 
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Peter Lovell
> Sent: Wednesday, December 06, 2006 8:23 AM
> To: Stephen Farrell; DTN
> Subject: Re: [dtn-interest] RG finished with bundle spec?
> 
>> ... I do think this is very ready to be an RFC.
> 
> The funky characters are still there, though (artifacts of MS Word). I
> a
> browser they show up as question marks inside a black diamond.
> 
> Cheers.....Peter
> 
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
> 

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] RG finished with bundle spec?
Date: Wed, 6 Dec 2006 08:34:15 -0500
From: "Scott, Keith L." <[email-masked]>
To: "Peter Lovell" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "DTN" <[email-masked]>
Sender: [email-masked]

OK, now I see.  And they don't show up 'wrong' under, say, wordpad,
since it's happy to use the same extended character set as MS word.
I'll submit a -08 version today to (hopefully) kill this.

Anybody with formatting issues, please send to me ASAP.

		--keith 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter Lovell
Sent: Wednesday, December 06, 2006 8:23 AM
To: Stephen Farrell; DTN
Subject: Re: [dtn-interest] RG finished with bundle spec?

>... I do think this is very ready to be an RFC.

The funky characters are still there, though (artifacts of MS Word). I
a
browser they show up as question marks inside a black diamond.

Cheers.....Peter

_______________________________________________
dtn-interest mailing list
[email-masked]
http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, DTN <[email-masked]>
Subject: Re: [dtn-interest] RG finished with bundle spec?
Date: Wed, 6 Dec 2006 08:22:51 -0500
Sender: [email-masked]

>... I do think this is very ready to be an RFC.

The funky characters are still there, though (artifacts of MS Word). I a
browser they show up as question marks inside a black diamond.

Cheers.....Peter

Date: Wed, 06 Dec 2006 12:29:51 +0000
From: Stephen Farrell <[email-masked]>
To: DTN <[email-masked]>
Subject: [dtn-interest] RG finished with bundle spec?
Sender: [email-masked]

Hi all,

Following recent minor(-ish) changes and the successful interop
in San Diego, Scott and Keith have posted a new version of the
bundle spec [1].

In San Diego I asked whether we should now start the process
of making this an RFC and there was consensus in the room
that we should. That involves me getting an IRSG review of
the document and handling any comments etc.

But, before I do that, I'd like to get a few positive acks
that we generally agree that the document is ready to
progress.

So, if you do think that, can you respond to this on the
list saying so? (Please don't start discussing things in
this thread, if there's something you want to discuss,
start a new thread, e.g. there are still some formatting
things to fix, but that's ok for now.)

And FWIW, I do think this is very ready to be an RFC.

Thanks,
Stephen.

[1] http://www.ietf.org/internet-drafts/draft-irtf-dtnrg-bundle-spec-07.txt

From: "Peter Lovell" <[email-masked]>
To: Susan <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(2): [dtn-interest] multicast?
Date: Tue, 5 Dec 2006 10:43:12 -0500
Sender: [email-masked]

Hi Susan,

>We absolutely need the multiple-nodes-in-an-endpoint concepts to
>support reliable multicast, and as such we don't want to see them
>footnoted as experimental or likely to change. 

Perhaps my comment was a little harsh - I wasn't suggesting that this be
removed  etc.

However, I think we all realize that the multiple-nodes-in-an-endpoint
idea is not as fully developed as other parts of dtn, especially as it
relates to security. 

As an example, who is supposed to know that a particular endpoint is
multi-node? Is it the originator, or perhaps it is the first forwarder
which has awareness of the multiple membership? At present it has to be
the source endpoint since the flag for it is immutable (included in PSB
mutable canonicalization). I dislike that though because the knowledge
of group membership must then be available throughout the dtn universe.

Similarly, the issue I raised about sequence numbers not really being
sequence numbers in a multi-node source endpoint is one which has come
up before but for which we're still searching for answers. The
description in the specification would lead a reader to expect an
ordering of bundles but that is unrealistic in a multi-node source
endpoint with multiple BPAs.

This is all my comment was intended to convey -- that we need more
thought and work in this area.

Cheers.....Peter

Content-class: urn:content-classes:message
Subject: RE: [dtn-interest] multicast?
Date: Mon, 4 Dec 2006 12:21:58 -0500
From: "Symington, Susan F." <[email-masked]>
To: "ryan m" <[email-masked]>, "DTNRG" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C717C8.B5111F96
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

In DTN, an endpoint is a set of nodes. If an endpoint has only one node
in it (and can only ever have one node in it), it is a singleton
endpoint. A bundle that is sent to that endpoint is intended to reach
the single node in that endpoint. The sending of such a bundle is what
we tend to think of as unicasting, though this isn't defined per se in
the Bundle Protocol.
=20
If an endpoint may have more than one node in it (and bundles sent to
that endpoint are intended to reach every node in the endpoint) the
endpoint is what we think of as a multicast endpoint. Sending of a
bundle to such a multicast endpoint is what we tend to think of as
multicasting.=20
=20
We absolutely need the multiple-nodes-in-an-endpoint concepts to
support reliable multicast, and as such we don't want to see them
footnoted as experimental or likely to change.  Our specification of
reliable multicast doesn't require any changes to the multi-node
endpoint concepts as currently defined in the bundle protocol.
=20
I'm not sure what you mean by "multi-node midpoint". Perhaps you are
thinking that a forwarding table can forward to several next hop nodes
and that the set of these could be defined as a single endpoint. Yes.
=20
-susan
=20
*****************************************************************
Susan Symington
The MITRE Corporation
[email-masked]
703-983-7209 (voice)
703-983-7142 (fax)
******************************************************************
=20

________________________________

	From: [email-masked]
[mailto:[email-masked]] On Behalf Of ryan m
	Sent: Monday, December 04, 2006 12:01 PM
	To: DTNRG
	Subject: [dtn-interest] multicast?
=09
=09
	I apologize if this has been asked before, I don't have a
chance to read everything that flows past dtn-interest, but are
multi-node endpoints the same concept as dtn multicasting?, with the
obvious difference of being able to have a multi-node midpoint, but a
singleton end point.=20
=09
	Thank you,
	Ryan Metzger
	Lehigh University
=09
=09
	On 12/4/06, Peter Lovell <[email-masked] > wrote:=20

		Hi Scott,
	=09
		>... since there's so much about non-singleton
endpoints that we don't=20
		>understand yet.
		>
		>Scott
	=09
		I couldn't agree more.
	=09
		Personally, I'd be happier if <all> the
multiple-nodes-in-an-endpoint
		things were footnoted as "experimental" or "likely to
change". I don't=20
		want to preclude them but I feel that their inclusion
at this stage
		greatly complicates almost everything we do.
	=09
		Cheers.....Peter
	=09
		_______________________________________________
		dtn-interest mailing list=20
		[email-masked]
		http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
	=09

------_=_NextPart_001_01C717C8.B5111F96
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2995" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>In DTN, an endpoint is&nbsp;a set of nodes. If =
an endpoint=20
has only one node in it (and can only ever have one node in it), it is a =

singleton endpoint. A bundle that is sent to that endpoint is intended =
to reach=20
the single node in that endpoint. The sending of such a bundle is what =
we tend=20
to think of as unicasting, though this isn't defined per se in the =
Bundle=20
Protocol.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>If an endpoint may have more than one node in =
it (and=20
bundles sent to that endpoint are intended to reach every node in the=20
endpoint)&nbsp;the endpoint&nbsp;is what we think of as a multicast =
endpoint.=20
Sending of a bundle to such a multicast endpoint is what we tend to =
think of as=20
multicasting. </FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>We absolutely need the =
multiple-nodes-in-an-endpoint=20
concepts to support reliable multicast, and as such we don't want to see =
them=20
footnoted as experimental or likely to change.&nbsp; Our specification =
of=20
reliable multicast doesn't require any changes to the multi-node =
endpoint=20
concepts as currently defined in the bundle =
protocol.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I'm not sure what you mean by "multi-node =
midpoint".=20
Perhaps you are thinking that a forwarding table can forward to several =
next hop=20
nodes and that the set of these could be defined as a single endpoint.=20
Yes.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D229441217-04122006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>-susan</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
*</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">Susan =
Symington</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">The MITRE =
Corporation</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier =
New">[email-masked]</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7209 =
(voice)</FONT></DIV>
<DIV align=3Dleft><FONT face=3D"Courier New">703-983-7142 =
(fax)</FONT></DIV>
<DIV align=3Dleft><FONT face=3DArial=20
size=3D2>****************************************************************=
**</FONT></DIV>
<DIV>&nbsp;</DIV><BR>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> =
[email-masked]=20
  [mailto:[email-masked]] <B>On Behalf Of </B>ryan =

  m<BR><B>Sent:</B> Monday, December 04, 2006 12:01 PM<BR><B>To:</B>=20
  DTNRG<BR><B>Subject:</B> [dtn-interest] =
multicast?<BR></FONT><BR></DIV>
  <DIV></DIV>I apologize if this has been asked before, I don't have a =
chance to=20
  read everything that flows past dtn-interest, but are multi-node =
endpoints the=20
  same concept as dtn multicasting?, with the obvious difference of =
being able=20
  to have a multi-node midpoint, but a singleton end point. =
<BR><BR>Thank=20
  you,<BR>Ryan Metzger<BR>Lehigh University<BR><BR>
  <DIV><SPAN class=3Dgmail_quote>On 12/4/06, <B =
class=3Dgmail_sendername>Peter=20
  Lovell</B> &lt;<A=20
  href=3D"mailto:[email-masked]">[email-masked]</A> =
&gt;=20
  wrote:</SPAN>
  <BLOCKQUOTE class=3Dgmail_quote=20
  style=3D"PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: =
rgb(204,204,204) 1px solid">Hi=20
    Scott,<BR><BR>&gt;... since there's so much about non-singleton =
endpoints=20
    that we don't <BR>&gt;understand yet.<BR>&gt;<BR>&gt;Scott<BR><BR>I =
couldn't=20
    agree more.<BR><BR>Personally, I'd be happier if &lt;all&gt; the=20
    multiple-nodes-in-an-endpoint<BR>things were footnoted as =
"experimental" or=20
    "likely to change". I don't <BR>want to preclude them but I feel =
that their=20
    inclusion at this stage<BR>greatly complicates almost everything we=20
    =
do.<BR><BR>Cheers.....Peter<BR><BR>______________________________________=
_________<BR>dtn-interest=20
    mailing list <BR><A=20
    =
href=3D"mailto:[email-masked]">[email-masked]=
.org</A><BR><A=20
    =
href=3D"http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://ma=
ilman.dtnrg.org/mailman/listinfo/dtn-interest</A><BR></BLOCKQUOTE></DIV><=
BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C717C8.B5111F96--

Date: Mon, 4 Dec 2006 12:00:30 -0500
From: "ryan m" <[email-masked]>
To: DTNRG <[email-masked]>
Subject: [dtn-interest] multicast?
Sender: [email-masked]

------=_Part_31065_9579655.1165251630103
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I apologize if this has been asked before, I don't have a chance to read
everything that flows past dtn-interest, but are multi-node endpoints the
same concept as dtn multicasting?, with the obvious difference of being able
to have a multi-node midpoint, but a singleton end point.

Thank you,
Ryan Metzger
Lehigh University

On 12/4/06, Peter Lovell <[email-masked]> wrote:
>
> Hi Scott,
>
> >... since there's so much about non-singleton endpoints that we don't
> >understand yet.
> >
> >Scott
>
> I couldn't agree more.
>
> Personally, I'd be happier if <all> the multiple-nodes-in-an-endpoint
> things were footnoted as "experimental" or "likely to change". I don't
> want to preclude them but I feel that their inclusion at this stage
> greatly complicates almost everything we do.
>
> Cheers.....Peter
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest
>

------=_Part_31065_9579655.1165251630103
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

I apologize if this has been asked before, I don't have a chance to read everything that flows past dtn-interest, but are multi-node endpoints the same concept as dtn multicasting?, with the obvious difference of being able to have a multi-node midpoint, but a singleton end point.
<br><br>Thank you,<br>Ryan Metzger<br>Lehigh University<br><br><div><span class="gmail_quote">On 12/4/06, <b class="gmail_sendername">Peter Lovell</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>
&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Scott,<br><br>&gt;... since there's so much about non-singleton endpoints that we don't
<br>&gt;understand yet.<br>&gt;<br>&gt;Scott<br><br>I couldn't agree more.<br><br>Personally, I'd be happier if &lt;all&gt; the multiple-nodes-in-an-endpoint<br>things were footnoted as &quot;experimental&quot; or &quot;likely to change&quot;. I don't
<br>want to preclude them but I feel that their inclusion at this stage<br>greatly complicates almost everything we do.<br><br>Cheers.....Peter<br><br>_______________________________________________<br>dtn-interest mailing list
<br><a href="mailto:[email-masked]">[email-masked]</a><br><a href="http://mailman.dtnrg.org/mailman/listinfo/dtn-interest">http://mailman.dtnrg.org/mailman/listinfo/dtn-interest</a><br></blockquote>
</div><br>

------=_Part_31065_9579655.1165251630103--

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, DTNRG <[email-masked]>
Subject: Re(2): [dtn-interest] bundle protocol spec, one more time
Date: Mon, 4 Dec 2006 11:11:03 -0500
Sender: [email-masked]

Hi Scott,

>... since there's so much about non-singleton endpoints that we don't 
>understand yet.
>
>Scott

I couldn't agree more.

Personally, I'd be happier if <all> the multiple-nodes-in-an-endpoint
things were footnoted as "experimental" or "likely to change". I don't
want to preclude them but I feel that their inclusion at this stage
greatly complicates almost everything we do.

Cheers.....Peter

Date: Sun, 03 Dec 2006 11:13:27 -0500
From: Hongwei Zhang <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [dtn-interest] Ph.D. positions in wireless sensor networks
Sender: [email-masked]

To Prospective Students:

I am an Assistant Professor in the Department of Computer Science at 
Wayne State University (a Research-I university, the highest rating 
issued by the Carnegie Foundation), USA. I am looking for talented 
students to join my research program, and I am writing to announce the 
Ph.D. positions currently available in my research group.

Our research focuses on foundational and systems issues in designing 
dependable services for dynamic and large scale systems (such as 
wireless sensor networks and the Internet). Examples of our work include 
application-adaptive messaging, reliable and real-time communication, 
and scalable dependability for wireless sensor networks. Presently, we 
are especially interested in the modeling and algorithmic issues in 
building dependable sensornet systems. Our work has provided dependable 
messaging services for several large scale sensor networks (including 
the one where more than 1,400 sensor nodes were deployed, the largest 
sensor network ever deployed so far), as a part of our effort in 
building the foundations and services for dependable sensornets. For 
more information about our research, please visit my webpage at 
http://www.cs.wayne.edu/~hzhang/.

By focusing on high-quality research, and by collaborating with other 
research groups in academia (e.g., The Ohio State University) and 
industry labs (e.g., Motorola Labs), my research program provides 
students with access to world-class facilities, real-world experience, 
and ample opportunities of contributing to the research community. 
Students in my research group will be supported financially in various 
forms, such as Fellowship, Graduate Research Assistantship, and Graduate 
Teaching Assistantship. Being in a strong department at an urban 
research university, you will also have a great life experience on 
campus here at the cultural center of Detroit, Michigan. (On a related 
note, The Scientist has recently ranked WSU as one of the best academic 
institutions to work in USA.)

As a part of my research effort, I am currently looking for talented 
students to join my research program as Ph.D. students. If you plan to 
apply for a Ph.D. position in my group, I will expect you to have strong 
academic background, to be self-motivated and goal-oriented, and to take 
initiative in executing research plans. Experience in systems building 
and mathematical modeling, experience in original research, and/or a 
Master degree in related fields (e.g., Computer Science, Computer 
Engineering)  are big pluses.

If you are interested in working with me as a Ph.D. student to conduct 
high-quality research, please feel free to contact me and share with me 
your background, career plan, and expectations for Ph.D. study. I will 
call or email you if there is a good match between us.

Thanks and best wishes.

Hongwei Zhang, Ph.D.
Assistant Professor
Department of Computer Science
Wayne State University, USA
Tel: +1 313 577 0731
E-mail: [email-masked]
Web: http://www.cs.wayne.edu/~hzhang/

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>
Cc: "Michael Demmer" <[email-masked]>, "Stephen Farrell" <[email-masked]>, "dtn interest" <[email-masked]>
Subject: Re(4): [dtn-interest] bundle protocol spec, one more time
Date: Fri, 1 Dec 2006 16:29:44 -0500
Sender: [email-masked]

>Here's a final edit of the bundle protocol spec that reflects all the 
>changes we've reached consensus on over the past few weeks, through this 
>morning.
>
>Scott

One additional observation -- not a problem.

Now that creation timestamp and sequence numbers are SDNVs, they could
_each_ be up to 64 bits (8 bytes). Previously the limit was 8 bytes in total.

I note this as we'll have to pay attention in the various parts of the
implementation.

Cheers.....Peter

Cc: Stephen Farrell <[email-masked]>, Scott Burleigh <[email-masked]>, DTNRG <[email-masked]>
From: Michael Demmer <[email-masked]>
Subject: Re: Re(2): [dtn-interest] bundle protocol spec, one more time
Date: Fri, 1 Dec 2006 10:43:17 -0800
To: Peter Lovell <[email-masked]>
Sender: [email-masked]

Personally, I'd rather bump the version number since we're changing  
the protocol.

-m

On Dec 1, 2006, at 8:53 AM, Peter Lovell wrote:

>>> We could.  It seems kind of academic to me since there's no  
>>> currently
>>> extant formal standard that we have to be backward-compatible  
>>> with.  My
>>> inclination would be not to bother, but there's probably still  
>>> time to
>>> tweak this before Keith sends it to IETF.
>>
>> I guess the interop used 0x04, so just in case someone wants to
>> retain compatibility with that to do some test again...
>>
>> But, I think the coders should make that call so long as they're
>> quick:-)
>>
>> S.
>
>
> It's true that there's no formal standard yet but there are some
> implementations in pilot or test. We're not interoperable (and I
> certainly don't want to think about dual-version code) so I was just
> trying to avoid lots of crashes when there's a mixture of old and new.
>
> Cheers.....Peter
>
> p.s. I'm not coding that part so I have no investment either way :)
>
>
> _______________________________________________
> dtn-interest mailing list
> [email-masked]
> http://mailman.dtnrg.org/mailman/listinfo/dtn-interest

From: "Peter Lovell" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>, "Scott Burleigh" <[email-masked]>
Cc: DTNRG <[email-masked]>
Subject: Re(2): [dtn-interest] bundle protocol spec, one more time
Date: Fri, 1 Dec 2006 11:53:35 -0500
Sender: [email-masked]

>> We could.  It seems kind of academic to me since there's no currently 
>> extant formal standard that we have to be backward-compatible with.  My 
>> inclination would be not to bother, but there's probably still time to 
>> tweak this before Keith sends it to IETF.
>
>I guess the interop used 0x04, so just in case someone wants to
>retain compatibility with that to do some test again...
>
>But, I think the coders should make that call so long as they're
>quick:-)
>
>S.

It's true that there's no formal standard yet but there are some
implementations in pilot or test. We're not interoperable (and I
certainly don't want to think about dual-version code) so I was just
trying to avoid lots of crashes when there's a mixture of old and new.

Cheers.....Peter

p.s. I'm not coding that part so I have no investment either way :)

Date: Fri, 01 Dec 2006 16:44:12 +0000
From: Stephen Farrell <[email-masked]>
To: Scott Burleigh <[email-masked]>
CC: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] bundle protocol spec, one more time
Sender: [email-masked]

Scott Burleigh wrote:
> Peter Lovell wrote:
>>> Here's a final edit of the bundle protocol spec that reflects all the 
>>> changes we've reached consensus on over the past few weeks, through this 
>>> morning.
>>>
>>> Scott
>>>     
>> Hi Scott,
>>
>> looks good. I have a couple of questions ...
>>
>> 1. section 2.4.1  Should we change the version to 0x05
>>    since we have changed the format?
>>   
> We could.  It seems kind of academic to me since there's no currently 
> extant formal standard that we have to be backward-compatible with.  My 
> inclination would be not to bother, but there's probably still time to 
> tweak this before Keith sends it to IETF.

I guess the interop used 0x04, so just in case someone wants to
retain compatibility with that to do some test again...

But, I think the coders should make that call so long as they're
quick:-)

S.

Date: Fri, 01 Dec 2006 08:39:17 -0800
From: Scott Burleigh <[email-masked]>
To: DTNRG <[email-masked]>
Subject: Re: [dtn-interest] bundle protocol spec, one more time
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------070205070704090405050105
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Peter Lovell wrote:
>> Here's a final edit of the bundle protocol spec that reflects all the 
>> changes we've reached consensus on over the past few weeks, through this 
>> morning.
>>
>> Scott
>>     
> Hi Scott,
>
> looks good. I have a couple of questions ...
>
> 1. section 2.4.1  Should we change the version to 0x05
>    since we have changed the format?
>   
We could.  It seems kind of academic to me since there's no currently 
extant formal standard that we have to be backward-compatible with.  My 
inclination would be not to bother, but there's probably still time to 
tweak this before Keith sends it to IETF.
> 2. section 2.4.1 - Creation timestamp. We haven't addressed the
>    issue of multi-node endpoints with a BPA on each node. They
>    all have the same EID. There's nothing to stop them all
>    using the same sequence numbers and thereby breaking the 
>    uniqueness characteristic of EID + timestamp. We could change 
>    it  to cover this case ...
>
>    "The source Bundle Protocol Agents on the nodes comprising an 
>    endpoint must never create two distinct bundles with the same 
>    source endpoint ID and bundle creation timestamp."
>   
Interesting point, and a simple fix.  Another way to prevent this would 
be to say that the source endpoint ID for a bundle must identify a 
singleton endpoint (which makes sense to me, and which I vaguely 
remember us considering long, long ago).  Or we could just let it go for 
now since there's so much about non-singleton endpoints that we don't 
understand yet.

Scott

--------------070205070704090405050105
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Lovell wrote:
<blockquote cite="[email-masked]"
 type="cite">
  <blockquote type="cite">
    <pre wrap="">Here's a final edit of the bundle protocol spec that reflects all the 
changes we've reached consensus on over the past few weeks, through this 
morning.

Scott
    </pre>
  </blockquote>
  <pre wrap=""><!---->Hi Scott,

looks good. I have a couple of questions ...

1. section 2.4.1  Should we change the version to 0x05
   since we have changed the format?
  </pre>
</blockquote>
We could.&nbsp; It seems kind of academic to me since there's no currently
extant formal standard that we have to be backward-compatible with.&nbsp; My
inclination would be not to bother, but there's probably still time to
tweak this before Keith sends it to IETF.<br>
<blockquote cite="[email-masked]"
 type="cite">
  <pre wrap="">
2. section 2.4.1 - Creation timestamp. We haven't addressed the
   issue of multi-node endpoints with a BPA on each node. They
   all have the same EID. There's nothing to stop them all
   using the same sequence numbers and thereby breaking the 
   uniqueness characteristic of EID + timestamp. We could change 
   it  to cover this case ...

   "The source Bundle Protocol Agents on the nodes comprising an 
   endpoint must never create two distinct bundles with the same 
   source endpoint ID and bundle creation timestamp."
  </pre>
</blockquote>
Interesting point, and a simple fix.&nbsp; Another way to prevent this would
be to say that the source endpoint ID for a bundle must identify a
singleton endpoint (which makes sense to me, and which I vaguely
remember us considering long, long ago).&nbsp; Or we could just let it go
for now since there's so much about non-singleton endpoints that we
don't understand yet.<br>
<br>
Scott<br>
</body>
</html>

--------------070205070704090405050105--

From: "Peter Lovell" <[email-masked]>
To: "Scott Burleigh" <[email-masked]>, DTNRG <[email-masked]>
Subject: Re: [dtn-interest] bundle protocol spec, one more time
Date: Fri, 1 Dec 2006 10:50:53 -0500
Sender: [email-masked]

>Here's a final edit of the bundle protocol spec that reflects all the 
>changes we've reached consensus on over the past few weeks, through this 
>morning.
>
>Scott

Hi Scott,

looks good. I have a couple of questions ...

1. section 2.4.1  Should we change the version to 0x05
   since we have changed the format?

2. section 2.4.1 - Creation timestamp. We haven't addressed the
   issue of multi-node endpoints with a BPA on each node. They
   all have the same EID. There's nothing to stop them all
   using the same sequence numbers and thereby breaking the 
   uniqueness characteristic of EID + timestamp. We could change 
   it  to cover this case ...

   "The source Bundle Protocol Agents on the nodes comprising an 
   endpoint must never create two distinct bundles with the same 
   source endpoint ID and bundle creation timestamp."

Cheers.....Peter