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"). 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
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] Sent: Sunday, April 24, 2016 3:40 AM To: ibr-dtn@ibr.cs.tu-bs.de Cc: Burleigh, Scott C (312B) scott.c.burleigh@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À DI BOLOGNA Codice Fiscale: 80007010376
participants (2)
-
Burleigh, Scott C (312B) -
Carlo Caini