[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)
- [dtn-interest] DTN2 - issues with discovery and P… I-Rajagopalan, Vijayasarathy