New subject: local EID, Timestamp and sequence number

29 Apr 2016

      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.itmailto: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ÃEUR DI BOLOGNA
Codice Fiscale: 80007010376
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI BOLOGNA
Codice Fiscale: 80007010376

Fwd: RE: TCP CL & interoperability with ION

Carlo Caini

Johannes Morgenroth

Carlo Caini

Carlo Caini

tags (0)

participants (2)