Dear IBR-DTN maintainers,
I have just received the answer below from Scott
Burleigh, regarding ipn syntax and
interoperability between IBR-DTN and ION via TCP-CL.
I will remail it on this mailing list.
In the meantime I have also tested routing rules
with ipn scheme in IBR-DTN and I am happy to
inform you all that all tests passed!
This means that full interoperability with ION
can be achieved with the (I suppose not too
difficult) fix suggested below. I have not tested BSP security yet.
Of course, I am willing to provide you with
further details or explanations if useful.
I look forward to hearing from you.
Yours,
Carlo
>Hi, Carlo. I'm sorry, the last couple of weeks
>have been quite difficult and I am only now
>catching up on the emails. Some remarks in-line below.
>
>Scott
>
>-----Original Message-----
>From: Carlo Caini [<mailto:carlo.caini@unibo.it>mailto:carlo.caini@unibo.it]
>Sent: Sunday, April 24, 2016 3:40 AM
>To: ibr-dtn(a)ibr.cs.tu-bs.de
>Cc: Burleigh, Scott C (312B) <scott.c.burleigh(a)jpl.nasa.gov>
>Subject: TCP CL & interoperability with ION
>
>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").
>
> > Right. When ION initiates the
> connection, it does so under the guidance of
> the "egress plans" that identify its
> neighbors. Each egress plan associates a node
> ID with a convergence-layer endpoint ID, e.g.,
> a socket name; since node IDs are formed as DTN
> endpoint IDs, the ION node's egress plan for
> the IBR-DTN node associated the EID "ipn:1.0"
> with that node's socket name. When the
> answering contact header says that the
> neighboring node identifies itself as "ipn:1"
> instead, ION detects that the node it has
> connected to is not the one it was trying to
> connect to, so for safety it drops the connection.
>
>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.
>
> > Yes. In this case, ION has no idea who
> the connecting node is, so the EID in the
> IBR-DTN node's contact header can't be
> validated against anything; it is simply accepted.
>
>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.
>
> > Actually the service number is simply
> mandatory; the registered definition for the
> "ipn" URI scheme requires it. The definition
> also reserves service number 0 for
> "administration" or something like that, as I recall.
>
>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.
>
> > Nope, you are correct.
>
>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ÃEUR DI BOLOGNA
>Codice Fiscale: 80007010376
>
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI BOLOGNA
Codice Fiscale: 80007010376
