[dtn-interest] DTN2 - issues with discovery and ProPHET protocol

"I-Rajagopalan, Vijayasarathy" <vijayasarathy.rajagopalan@boeing.com> Mon, 05 December 2016 09:30 UTC

Return-Path: <vijayasarathy.rajagopalan@boeing.com>
X-Original-To: dtn-interest@ietfa.amsl.com
Delivered-To: dtn-interest@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D8B12940D for <dtn-interest@ietfa.amsl.com>; Mon, 5 Dec 2016 01:30:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1v7s4j3pPfvP for <dtn-interest@ietfa.amsl.com>; Mon, 5 Dec 2016 01:30:27 -0800 (PST)
Received: from ewa-mbsout-02.mbs.boeing.net (ewa-mbsout-02.mbs.boeing.net [130.76.20.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3812C12940F for <dtn-interest@irtf.org>; Mon, 5 Dec 2016 01:30:26 -0800 (PST)
Received: from ewa-mbsout-02.mbs.boeing.net (localhost [127.0.0.1]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with ESMTP id uB59UPP1028902 for <dtn-interest@irtf.org>; Mon, 5 Dec 2016 01:30:26 -0800
Received: from XCH15-08-05.nw.nos.boeing.com (xch15-08-05.nw.nos.boeing.com [137.137.100.68]) by ewa-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id uB59UPUD028899 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK) for <dtn-interest@irtf.org>; Mon, 5 Dec 2016 01:30:25 -0800
Received: from XCH15-08-03.nw.nos.boeing.com (2002:8989:642e::8989:642e) by XCH15-08-05.nw.nos.boeing.com (2002:8989:6444::8989:6444) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 5 Dec 2016 01:30:24 -0800
Received: from XCH15-08-03.nw.nos.boeing.com ([137.137.100.46]) by XCH15-08-03.nw.nos.boeing.com ([137.137.100.46]) with mapi id 15.00.1178.000; Mon, 5 Dec 2016 01:30:24 -0800
From: "I-Rajagopalan, Vijayasarathy" <vijayasarathy.rajagopalan@boeing.com>
To: "dtn-interest@irtf.org" <dtn-interest@irtf.org>
Thread-Topic: DTN2 - issues with discovery and ProPHET protocol
Thread-Index: AdJO2f63miERZiWpQAq3hdMVXAbawQ==
Date: Mon, 05 Dec 2016 09:30:24 +0000
Message-ID: <8e0f19517606499ea910bb31411ffe9a@XCH15-08-03.nw.nos.boeing.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.137.12.6]
Content-Type: multipart/mixed; boundary="_004_8e0f19517606499ea910bb31411ffe9aXCH150803nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dtn-interest/pJWOJ-cPulPrJx23VYrOt-MNYoI>
Subject: [dtn-interest] DTN2 - issues with discovery and ProPHET protocol
X-BeenThere: dtn-interest@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "The Delay-Tolerant Networking Research Group \(DTNRG\) - Announce." <dtn-interest.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dtn-interest/>
List-Post: <mailto:dtn-interest@irtf.org>
List-Help: <mailto:dtn-interest-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/dtn-interest>, <mailto:dtn-interest-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2016 09:30:30 -0000

Hi all,
I am currently experimenting with the DTN2 implementation for analyzing various routing protocols which can be configured with DTN2. I have certain issues with the DTN2 implementation.
I am emulating a simple 2-node network to analyse opportunistic contact and use of various routing protocols between them (the ultimate goal is to run a multi-node emulation of mobile nodes with multiple routes between them). The emulation is done on the Common Open Research Emulator (CORE), which will let nodes to be moved in a canvas to emulate in-contact/out-of-contact scenarios for radio communication. I am having issues with two aspects of DTN2 - discovery and prophet protocol at the moment, as explained below:
a) I am running a simple discovery between the two nodes. The nodes are out-of-contact at the beginning, and one node is manually moved to the other node's proximity for them to become in-contact. The configuration file is same for both nodes (except for the discovery IP), and is the following (removed comments and blank lines for convenience):
 ---------------------------------------------------------------------------------
log /dtnd info "dtnd parsing configuration..."
console set stdio true
set shorthostname [lindex [split [info hostname] .] 0]
console set prompt "$shorthostname dtn% "
storage set type berkeleydb
storage set server_port 62345
storage set schema /etc/DS.xsd
append dbdir $::env(SESSION_DIR) "/" [info hostname] ".conf/dtn2/"
if {$dbdir == ""} {
    puts stderr "Must create /var/dtn or /var/tmp/dtn storage directory"
    exit 1
}
append local_payloaddir $dbdir "/bundles"
append local_dbdir $dbdir "/db"
storage set payloaddir $local_payloaddir
storage set dbname     DTN
storage set dbdir      $local_dbdir
route local_eid "dtn://[info hostname].dtn"
interface add udp0 udp
discovery add udp0d ip port=9556
discovery announce udp0 udp0d udp interval=4 cl_addr=10.0.0.2
log /dtnd info "dtnd configuration parsing complete"

When DTN2 is started on the two nodes, and the nodes are moved nearer to become in-contact, I see that the link state goes from UNAVAILABLE to OPENING, and remains in the OPENING state forever. The nodes do not seem to be dtnpinging each other. A link dump on one of the nodes results in the following:
 -------------------------------------------------------------------------
n2 dtn% link dump
Active links:
link-0 [10.0.0.1:4556 dtn://n1.dtn OPPORTUNISTIC udp state=OPENING]

Previously active links:

-------------------------------------------------------------------------

However, a link stats on link-0 gives the following statistic:

-------------------------------------------------------------------------
n2 dtn% link stats link-0
1 contact_attempts -- 0 contacts -- 0 bundles_transmitted -- 0 bytes_transmitted -- 0 bundles_queued -- 0 bytes_queued -- 0 bundles_inflight -- 0 bytes_inflight -- 0 bundles_cancelled -- 187 uptime -- 0 throughput_bps -- 0 bundles_deferred
-------------------------------------------------------------------------

We can see that the bundles_cancelled number keeps increasing.
 However, when the nodes start in-contact, the link automatically goes to the OPEN state, and the nodes are able to dtnping each other, and bundles get queued when they are moved farther away as expected.
b) I am running ProPHET routing protocol over UDP CL discovery in the same network as above. The configuration for both the nodes is as follows:
 ----------------------------------------------------------------------------
log /dtnd info "dtnd parsing configuration..."
console set stdio true
set shorthostname [lindex [split [info hostname] .] 0]
console set prompt "$shorthostname dtn% "
storage set type berkeleydb
storage set server_port 62345
storage set schema /etc/DS.xsd
append dbdir $::env(SESSION_DIR) "/" [info hostname] ".conf/dtn2/"
if {$dbdir == ""} {
    puts stderr "Must create /var/dtn or /var/tmp/dtn storage directory"
    exit 1
}
append local_payloaddir $dbdir "/bundles"
append local_dbdir $dbdir "/db"
storage set payloaddir $local_payloaddir
storage set dbname     DTN
storage set dbdir      $local_dbdir
route local_eid "dtn://[info hostname].dtn"
route set type prophet
interface add udp0 udp
discovery add udp0d ip port=9556
discovery announce udp0 udp0d udp interval=4 cl_addr=10.0.0.2
log /dtnd info "dtnd configuration parsing complete"
----------------------------------------------------------------------------
 Since ProPHET relies on the underlying discovery, the following is seen:
               1. When nodes start from out-of-contact and move closer to each other, ProPHET does not seem to begin because of discovery failure.
               2. When nodes start from in-contact, discovery succeeds as mentioned above, and hence one of the nodes initiates a HELLO tlv (as mentioned in ProPHET I-D). However, the node which receives the HELLO tlv crashes with an assert failure, with the below message:
 -------------------------------------------------------------------------
n2 dtn% ASSERTION FAILED (e->link_ != NULL) at routing/ProphetRouter.cc:190
STACK TRACE: 0x6414a3 0x4d70b5 0x44d06d 0x4d678b 0x43d1a5 0x43d13a 0x43e420 0x66bd77 0x66bc26 0x7f2a72152184 0x7f2a7165f37d
./setdtn2dirs: line 12:    99 Aborted                 (core dumped) dtnd -c dtn2/conf/${HOSTNAME}.conf -l debug -o dtn2/log/${HOSTNAME}.log -t
-------------------------------------------------------------------------
 I am attaching a zip file with this email, which contains the following documents:
 a) Folder by the name "discovery_issues", which contains the configuration of one of the nodes and the DTN2 log for the node.
b) Folder by the name "prophet_issues", which contains the configuration of both nodes (in folders n1 and n2), and their respective logs.

Any assistance on the above is much appreciated.

Thanks and regards,
Vijayasarathy (Vijay)