Re: [dtn-interest] Comments on RFC 4838

[Michael Noisternig <[e-mail]>]

Thanks, Scott, for the additional clarification!

I may need to bend my head around it one more time but it does give me a 
clearer picture!

Michael

Am 20.06.2013 17:28, schrieb Burleigh, Scott C (313B):
> You're right, Michael, the relationships are not as clear as they ought to be.  One thing to bear in mind is that RFC 4838 was written quite a while before RFC 5050, and in that interim the DTNRG engaged in some fairly spirited negotiations of protocol details; RFC 5050 is the product of those negotiations, and it's a normative protocol specification rather than an informative architecture overview, so wherever you see a conflict between the documents it is safer to go with the text in RFC 5050.
>
> Among the decisions that came out of the RFC 5050 negotiations was an intentional generalization of the concept of a BP "application".  There are no application IDs anywhere in DTN; formally, bundles are never addressed to applications.  From the BP perspective, "applications" are merely the constituents of the "application-specific element" of the "application agent" of a node.  An "application" might be hardware or software.  It constructs, requests transmission of, accepts delivery of, and processes application data units (ADUs), somehow; the manner by which it asks the node's protocol agent to transmit application data in bundles and deliver application data that was received in bundles is left entirely to the implementation.  So there's no formally defined relationship between applications and endpoints at all.  An endpoint is simply a set of nodes, which any given node can join or withdraw from at any time; formally, it has nothing to do with applications.
>
> In practice, of course, every implementation provides a concrete, specific way for an application to ask for transmission of data in a bundle whose source EID is a specified string and to ask for delivery of data received in bundles whose destination EID is a specified string.  Every CBHE-compatible implementation, in particular, lets you construct an EID comprising a numeric node ID (MAC address would be a good choice) and a numeric service (port-like) ID; it lets an application request transmission of a bundle whose payload is some ADU and whose source EID was constructed in this way; and it lets an application request delivery of ADUs that are the payloads of received bundles whose destination EID was formed in this way.  But these are implementation mechanisms, not Bundle Protocol requirements.
>
> Scott
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Noisternig
> Sent: Thursday, June 20, 2013 2:41 AM
> To: [e-mail]
> Subject: Re: [dtn-interest] Comments on RFC 4838
>
> Thanks, Scott.
>
> The reason why I have difficulties understanding the details is because EIDs are solely being described as referring to one or more (RFC 4838) (or zero or more (RFC 5050)) DTN nodes, but what we want to address in the BP are applications connected to/running on these nodes and not the nodes themselves.
>
> RFC 4838 states that "to initiate a registration and thereby establish application registration state, an application specifies an Endpoint ID for which it wishes to receive ADUs", so may I take it that there is (more or less) a 1-1 relationship between EIDs and applications? The application uses the node it connects to as a means to get data destined for a particular EID to be sent to that node, which then forwards it to the application? So the EID the application selects should be globally unique, and _may_ be compiled by combining the node's MAC with a local service/port id (which would avoid the problem of disseminating the node-to-EID registration information in the network)?
>
> I'm sorry that this is not being obvious to me. Thank you for further clarifications,
>
> Michael
>
> Am 20.06.2013 02:07, schrieb Burleigh, Scott C (313B):
>> Hi, Michael.  A couple of remarks on your comments -- and Sebastian's -- in-line below.
>>
>> Scott
>> ________________________________________
>> From: [e-mail] [[e-mail]] on
>> behalf of Michael Noisternig [[e-mail]]
>> Sent: Wednesday, June 19, 2013 5:21 AM
>> To: [e-mail]
>> Subject: Re: [dtn-interest] Comments on RFC 4838
>>
>> Hi Sebastian,
>>
>> thank your for your comments. See my replies inline.
>>
>>> maybe 4838 is a bit aged and does not reflect all the things people
>>> have come up with, since. And yes, while it says "_DTN_ Architecture"
>>> it is tied quite strongly to the BP. So maybe it isn"t 100% what it
>>> says on the can, but writing a short/concise RFC for everything that
>>> can be called a DTN would probably be impossible. Or, to put it into
>>> a more positive perspective: Partly the intention for the BP WAS to
>>> be something for "all kinds of" DTNs. Like TCP/IP it aims for
>>> generality,  but this implies tradeoffs. (and functionality-wise BP
>>> includes "more stuff" than IP, which makes this balance harder)
>>
>> Obviously, my expectations were a bit different, but I understand your
>> perspective.
>>
>>>> However, homogeneous resource-constrained networks are unlikely to
>>>> benefit from the bundle overlay protocol, even when compressed
>>>> headers (CBHE) are used and the protocol is directly implemented at
>>>> L3. As such
>>>
>>>
>>> Ah, a good opportunity for a shameless plug! In fact we DO use the BP as L3 protocol on Contiki based WSN nodes over IEEE 802.15.4. There are two papers and a GIT to "prove it":
>>
>> In fact, I am aware of your group's work on ibr-dtn and mudtn. This is
>> why I said that even with compression (CBHE) the overhead of the BP
>> would probably still be too high for our scenario... addresses in
>> EUI-48 format, high volume of messages with very small payloads. We
>> are more concerned about network overhead than computing resources.
>> Still, we will look into your work in more detail.
>>
>>>> 3.2 and 3.3:
>>>> What wasn't really clear to me in both RFC 4838 and 5050 was the whole node-to-EID registration process. A node registers to an EID, and an application somehow gets associated/registered with a node (via some socket API?). (So there seem to be two separate registration processes.) Then if all applications connect to the same node (e.g., a daemon) how do the applications get multiplexed on the channel? Or is there a 1-1 relationship between applications and nodes? If an application selects the EID to register to how can we assure a unique "singleton" EID for each node? How do these EIDs get registered within the network?
>>> In THEORY BP has a "an EID can be anything" concept: A node, many nodes, one name amongst many for a node, an interest, a haiku...   in PRACTICE, when using DTN2 or IBR-DTN implementations (and probably others), it mostly comes back to the more mundane: An EID is a node identifier, the path is used for multiplexing like Port numbers: dtn://node1/myApp  -> Boring, but that is what is mostly  used. "Colliding" EIDs may, or may not be a problem also depending on the employed routing. 4838 or 5050 do not offer any solution for generating unique EIDs (but putting some sort of Mac Address into an EID is straight-forward)
>>
>>>>>    Not quite, I would say.  An EID is a string that identified a BP endpoint, full stop.  And RFC 5050 states pretty unambiguously what a BP endpoint is: it's a set of zero or more BP nodes.  An EID might be a haiku, but an endpoint can't.  In practice, I think DTN2 EIDs (formed in the "dtn" URI scheme) typically include a DNS name that identifies a virtual or physical CPU that is coterminous with some BP node, followed by a string token for demultiplexing bundles sent to that node.  EIDs formed in the "ipn" URI scheme more formally always include a numeric node ID (which may or may not correspond to a CPU) and a numeric service ID (for demultiplexing).
>>>>> It is true that using MAC address as node ID, in an EID scheme that supports the concept of node IDs, is a good way to prevent EID collisions.
>>
>> Thank you, that sheds a bit more light on the issue. Let me make sure
>> I understand this correctly... Whereas an EID may represent a single
>> node or multiple nodes (or interests or whatnot), there is (more or
>> less) a
>> 1-1 relationship between applications and nodes, i.e., each node
>> represents an application, right?
>>
>>>>> No, that's not the case.  Each node encompasses a single bundle protocol agent, which can send and receive bundles on behalf of any number of applications.  Applications and nodes are orthogonal.
>>
>>>> 3.3.2:
>>>> Late binding is a nice concept, but of course it conflicts with routing under mobility where identities do not necessarily represent locations. How is this issue going to be resolved? I'm not sure leaving this as an implementation matter is the appropriate "solution".
>>> Routing. A can of worms. Like in the WSN community, some "standard" approaches exist that work so-so, often application specific solutions seems to be the key. . Others might disagree, but it really depends much on the application, with scheduled IPNs the one extreme and completely undeterministic, opportunistic networks at the other.
>>>>
>>>> Related to this, can (or how can) DTN nodes from different networks (with different schemes) register to the same EID?
>>> I am not sure if I understand this correctly, but different schemes,
>>> imply it is a different EID (it may be the same node), i.e.
>>> ipn://23.1 is not the same EID as dtn://23.1
>>
>> Right... I was thinking of an EID as an identifier, so obviously that
>> doesn't work.
>>
>>>>> Bu EIDs really are identifiers; they identify endpoints, not nodes.  Any number of nodes can register as members of a given endpoint, but the mechanism for advertising those registrations is not defined.  There's nothing whatsoever preventing a given node (which is a functional construct, not a string) from registering in any number of endpoints (sets of nodes) that are identified by strings formed in any number of URI schemes.  There's no reason a given node can't register in both the endpoint identified by "dtn://bills.macbook/chat" and "ipn: 391635.31".
>>
>>>
>>>
>>>
>>> Sebastian
>>
>> Thanks,
>> Michael
>> _______________________________________________
>> dtn-interest mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>> _______________________________________________
>> dtn-interest mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/dtn-interest
>>
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
> _______________________________________________
> dtn-interest mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/dtn-interest
>