Project

General

Profile

Actions

Feature #3948

open

Multiple network support

Added by Ashlesh Gawande almost 8 years ago. Updated almost 4 years ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Start date:
05/30/2017
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)

Description

Do not forward LSA interests to routers not in the same network. Multiple networks should not interfere with each other.

Currently, if two routers are working on different network prefixes, e.g. /ndn/ and /ccn, LSAs distributed will leak into the other network, and cause interruptions.

  • (1) On a single computer, multiple NLSR processes could run simultaneously without interfering with each other.
  • (2) LSAs distributed for one network would not clutter other networks.

This is a CI-NEW grant (NDN-CRI) goal for year two.


Subtasks 1 (0 open1 closed)

Bug #4101: Use network name in sync prefixClosedAshlesh Gawande05/30/2017

Actions

Related issues 1 (1 open0 closed)

Related to NLSR - Feature #3277: NLSR messages should include process IDNew10/20/2015

Actions
Actions #1

Updated by Nicholas Gordon over 7 years ago

  • Priority changed from Normal to Low
Actions #2

Updated by Nicholas Gordon over 7 years ago

  • Priority changed from Low to Normal
Actions #3

Updated by Nicholas Gordon over 7 years ago

  • Related to Feature #3277: NLSR messages should include process ID added
Actions #4

Updated by Nicholas Gordon over 7 years ago

  • Tracker changed from Task to Feature
  • Subject changed from Support multiple NLSR domains in a large network and multiple NLSR processes on a border router to Multiple network support
  • Description updated (diff)
  • Target version set to v0.5.0
Actions #5

Updated by Nicholas Gordon over 7 years ago

  • Description updated (diff)

To further specify this issue, the goal is: given two NLSR processes on one computer, condition (1) means that the two processes will not forward anything to each other.

Some of the problems can be addressed by namespacing (e.g. sync and LSAs, which can be given with a multi-component prefix to avoid collisions, in theory).

Other problems are not clear. It seems that NLSR should already be able to support multiple processes per node, considering the case where neighbors are specified with full URIs, disambiguating two processes should be possible, say with a port number specification.

For example, consider the case where we are running three NLSR processes on each node. In a conventional UDP-tunneled overlay, we could specify the URIs like this:

  • udp4://10.0.0.1:8000 (in the first nlsr.conf)
  • udp4://10.0.0.1:8001 (in the second)
  • udp4://10.0.0.1:8002 (in the third)

Then, this should be enough to differentiate the processes. If we then differentiate the broadcast-type connections (Hello procotol, LSA, and sync) by setting good network names, a cursory evaluation suggests that NLSR should already do this.

Unless someone else knows of a situation in which this fails, we may need to construct an experiment to determine whether this happens in practice.

Actions #6

Updated by Nicholas Gordon over 7 years ago

  • Description updated (diff)
Actions #7

Updated by Nicholas Gordon almost 7 years ago

  • Assignee set to Laqin Fan
Actions #8

Updated by Ashlesh Gawande about 6 years ago

  • Target version changed from v0.5.0 to v0.6.0
Actions #9

Updated by Saurab Dulal almost 4 years ago

  • Target version changed from v0.6.0 to Minor Release v0.6.1
Actions

Also available in: Atom PDF