Re: [dtn-interest] FW: [IRSG] POLL: draft-irtf-dtnrg-arch-07 -- DUE30 Oct

[Scott Burleigh <[e-mail]>]

Henderson, Thomas R wrote:
>> -----Original Message-----
>> From: Scott Burleigh [mailto:[e-mail]] 
>> Sent: Saturday, November 04, 2006 6:17 PM
>> To: Henderson, Thomas R
>> Cc: [e-mail]
>> Subject: Re: [dtn-interest] FW: [IRSG] POLL: 
>> draft-irtf-dtnrg-arch-07 -- DUE30 Oct
>>
>>     
> (snip)
>   
>> My preference would be not to start all over again with 
>> terminology wrangling.  One thing I would like to clarify: 
>> bundle protocol EIDs are not addresses, because they do not 
>> necessarily have any topological significance at all (unlike 
>> the subnet number structure of IP addresses, the street 
>> number structure of postal addresses, etc.).  You route on 
>> them but nominally you do so only indirectly: EIDs are names 
>> that you use to look up or infer (somehow) the topological 
>> relationships you need to make routing decisions.
>>     
>
> The DTN terminology seems to be related to the Nimrod (RFC1992)
> terminology, with a few differences.
>
> In DTN, the endpoint defines a "region"; a set of DTN nodes.
More precisely, the endpoint ID identifies an endpoint, which is a set 
of zero or more DTN nodes.  The term "region" has been pretty strongly 
deprecated over the last year or so.
> In Nimrod,
> a node denotes a "region"; a set of endpoints.  Nimrod EIDs do not span
> multiple endpoints.  Maybe this might be clarified somehow.  It might be
> worth a read of RFC1992 and describing the similarities and differences.
>   
I agree.
>>> It is not clear whether ADUs or bundles are passed to the DTN stack
>>> across the service access point (SAP).  In 3.1 and 3.3.1, it says that applications send ADUs, but in other places, it describes bundles being the unit of data passed.  But it says in 3.1 that ADUs may be fragmented into bundles; who does this fragmentation?
>>>       
>> It's only ADUs that are passed across the service access 
>> point, and only ADUs are fragmented.  This may be a little 
>> more explicit in the Bundle Protocol spec.
> OK, I think what confused me in this document is in 3.6.1, the definition of
> delivery options, where it appears that applications are seeing the results
> of bundle operations in the DTN (but they are passing ADUs and not bundles);
> e.g.:
>
>    "- Report When Bundle Received - requests a Bundle Reception Status 
>       Report be generated when the subject bundle arrives at a DTN node.
> "
>
> All of these services are defined in terms of bundles, while the
> applications are supposed to be dealing with ADUs.
>   
Good point.  What is tricky here,  which I think justifies this 
language, is that the application that sees these results is -- in a 
sense -- DTN itself.  Management of bundle traffic is the application, 
so exposing bundles to the application is unavoidable.  It's analogous 
to exposing IP packet activity to ICMP, I think.

Scott