In these days I have carried out some interoperability tests between IBR-DTN and ION with TCP as CL (RFC7242, June 2014). When the TCP connection is established, the TCP CL sends a message, called contact header, including the local EID. Each end-node sends its contact header to the corresponding pair. What happens then is largely left to the implementation. Let me assume that you have two nodes, 1 and 2, with IBR-DTN on 1 and ION on 2. When the TCP connection is started by ION, we have a failure because IBR-DTN advertises itself back as ipn:1 instead of ipn:1.0. In other words, ION performs a check on the EID of the corresponding node, and this check fails because of the lack of the last part of the EID (".0"). If the connection is started from IBR-DTN it succeeds, maybe because ION does not perform a similar check in input, but I am not sure. The details of my test (Test3) are below. I have noticed that in other logs IBR-DTN makes use of a "shothened" ipn EID to identify a node, as below: Sat Apr 23 20:52:51 2016 NOTICE ConnectionEvent: connection up ipn:2 Sat Apr 23 20:52:51 2016 NOTICE NodeEvent: Node ipn:2 available Sat Apr 23 20:52:51 2016 NOTICE ConnectionEvent: connection down ipn:2 From the man of ipnadmin (see below) it seems that an ipn EID always includes a service number, and in practice that "0" is used as default. If this is correct, I suppose that IBR-DTN should always use ipn:1.0 instead of ipn:1. However, I could also be wrong. I have also successfully performed an analogue test (Test 4) with the dtn scheme. In this case the EID given back by IBR-DTN is dtn://vm1.dtn, which is the same EID expected by ION; note that in ION configuration, in the line a plan //vm1.dtn x tcp/10.0.1.1 "//vm1.dtn" is the name of the node, equivalent to "1" in ipn. In brief, in the dtn scheme it seems not necessary to include a demux token as in ipn. As ipn and dtn syntaxes are often challenging also to people that are familiar with DTN, I send this mail in cc also to Scott Burleigh, which is the ION and ipn scheme designer in order to have confirmation of the ipn syntax. Yours, Carlo
Test 3) Failed. The TCP CL of IBR DTN gives ipn:1 where ipn:1.0 is expected by ION (syn from ION) From vm1 ibrdtn.conf
# the local eid of the dtn node # default is the hostname local_uri = ipn:1.0
From vm2 ION configuration file #Outduct to Vm1 a outduct tcp 10.0.1.1 '' a plan 1 x tcp/10.0.1.1
From vm2 logs [2016/04/23-19:01:10] [i] Connected to TCP socket: 10.0.1.1:4556 [2016/04/23-19:01:10] [?] expected tcpcl EID: ipn:1.0 [2016/04/23-19:01:10] [?] received tcpcl EID: ipn:1 [2016/04/23-19:01:10] [i] tcpcli got no valid contact header: ipn:1.0
Test 4) Passed The TCP CL of IBR DTN gives dtn://vm1 as expected by ION (syn from ION) From vm1 ibrdtn.conf # the local eid of the dtn node # default is the hostname local_uri = dtn://vm1.dtn
From vm2 ION configuration #Outduct to Vm1 a outduct tcp 10.0.1.1 '' a plan //vm1.dtn x tcp/10.0.1.1
From the man of ipnadmin (ION) ipnadmin configures the local ION node's routing of bundles to endpoints whose IDs conform to the ipn endpoint ID scheme. ipn is a CBHE-conformant scheme; that is, every endpoint ID in the ipn scheme is a string of the form "ipn:node_number.service_number" where node_number is a CBHE "node number" and service_number identifies a specific application processing point.
5x1000 AI GIOVANI RICERCATORI DELL'UNIVERSITÀ DI BOLOGNA Codice Fiscale: 80007010376