Project

General

Profile

Actions
Copy link

Feature #3352

open

Set transport state UP/DOWN based on the state of the underlying network interface

Added by Davide Pesavento almost 9 years ago. Updated about 2 years ago.

Status:
In Progress
Priority:
Normal
Assignee:
-
Category:
Faces
Target version:
-
Start date:
Due date:
% Done:

10%

Estimated time:
12.00 h

Description

#2989 implemented a minimal permanent UDP face that is always UP, i.e. does not perform any UP/DOWN transitions. We'd like to implement these state transitions based on the state of the "lower layer", for example:

  • wlan0 goes down or is unplugged -> set all faces using wlan0 to DOWN.
  • eth0 loses an IP address -> set face using that address as its local endpoint to DOWN.
  • eth0 reacquires an IP address -> set face back UP.

The implementation should rely on ndn::net::NetworkMonitor signals to detect changes in the host network configuration.

Related issues 5 (3 open — 2 closed)

Related to NFD - Feature #3521: Netdev-bound facesIn Progress

Actions
Related to NFD - Feature #3420: best-route: return Nack if nexthops are DOWNNew

Actions
Blocked by ndn-cxx - Feature #3353: NetworkMonitor: emit fine-grained signals when the state of a network interface changesClosedDavide Pesavento

Actions
Blocked by NFD - Feature #4021: FaceSystem: use NetworkMonitor::listNetworkInterfaces()ClosedJunxiao Shi

Actions
Blocks NLSR - Task #3937: NLSR should react to Face event notificationsNewSaurab Dulal05/23/2017

Actions
Actions
Copy link
 #1

Updated by Junxiao Shi almost 9 years ago

  • Blocked by Feature #3353: NetworkMonitor: emit fine-grained signals when the state of a network interface changes added
Actions
Copy link
 #2

Updated by Junxiao Shi almost 9 years ago

Question: how to determine which UDP faces are on wlan0?

Actions
Copy link
 #3

Updated by Junxiao Shi almost 9 years ago

  • Category set to Faces
Actions
Copy link
 #4

Updated by Davide Pesavento almost 9 years ago

Junxiao Shi wrote:

Question: how to determine which UDP faces are on wlan0?

We're still working out the details of that mechanism, but the idea is that FaceManager maintains a mapping from NICs to faces. Andrea will post a more detailed design once we get there.

Actions
Copy link
 #5

Updated by Davide Pesavento almost 9 years ago

  • Subject changed from Setting transport state UP/DOWN based on the state of the underlying network interface to Set transport state UP/DOWN based on the state of the underlying network interface
Actions
Copy link
 #6

Updated by Andrea Tosatto almost 9 years ago

  • Status changed from New to In Progress
Actions
Copy link
 #7

Updated by Andrea Tosatto over 8 years ago

We've some design questions regarding permanent unicast faces, in particular how they behave when their face local address is removed from the interface. For example, when the permanent face local address is removed from the interface there could be the possibility to communicate with the face remote endpoint using a different local address. Is it the behavior we want for a permanent face?

Our proposed solution, that fits well our scenario, is to choose an address from the same interface when the face local address has been removed. If no other address is available the face will stick around until an address becomes available on that interface. Is this a good behavior for a permanent face? It could be strange if a user specify a local address when creating the permanent face(#3471).

Actions
Copy link
 #8

Updated by Davide Pesavento over 8 years ago

Actions
Copy link
 #9

Updated by Davide Pesavento over 8 years ago

  • Status changed from In Progress to Feedback
  • Assignee deleted (Andrea Tosatto)

Andrea's internship with us is over. He already wrote most of the implementation of this feature in a local branch. I will polish the code and submit it for merging when/if time allows, most likely after the summer.

Actions
Copy link
 #10

Updated by Davide Pesavento about 8 years ago

  • Target version changed from v0.5 to v0.6
Actions
Copy link
 #11

Updated by Junxiao Shi over 7 years ago

  • Blocked by Feature #4021: FaceSystem: use NetworkMonitor::listNetworkInterfaces() added
Actions
Copy link
 #12

Updated by Junxiao Shi over 7 years ago

  • Blocks Feature #3420: best-route: return Nack if nexthops are DOWN added
Actions
Copy link
 #13

Updated by Davide Pesavento about 7 years ago

  • Description updated (diff)
Actions
Copy link
 #14

Updated by Davide Pesavento about 7 years ago

  • Target version changed from v0.6 to v0.7
Actions
Copy link
 #15

Updated by Ashlesh Gawande over 6 years ago

  • Blocks Task #3937: NLSR should react to Face event notifications added
Actions
Copy link
 #16

Updated by Junxiao Shi almost 6 years ago

  • Status changed from Feedback to In Progress
  • Assignee set to Junxiao Shi
  • Estimated time set to 12.00 h

I'll work on state transition of Ethernet faces. I do not see a clear implementation path to other unicast faces.

Actions
Copy link
 #17

Updated by Junxiao Shi almost 6 years ago

  • % Done changed from 0 to 10
Actions
Copy link
 #18

Updated by Junxiao Shi almost 6 years ago

  • Blocks deleted (Feature #3420: best-route: return Nack if nexthops are DOWN)
Actions
Copy link
 #19

Updated by Junxiao Shi almost 6 years ago

  • Related to Feature #3420: best-route: return Nack if nexthops are DOWN added
Actions
Copy link
 #20

Updated by Junxiao Shi almost 6 years ago

  • Assignee deleted (Junxiao Shi)

As I indicated, I don't know how to implement for non-Ethernet faces, so I'm releasing this issue to whoever interested.

#3420 can now proceed. Strategy can return Nack to a point-to-point downstream when upstream is Ethernet that is DOWN.
#3937 is still blocked because NLSR mainly uses UDP unicast faces.

Actions
Copy link
 #21

Updated by Davide Pesavento about 5 years ago

  • Target version changed from v0.7 to 22.02
Actions
Copy link
 #22

Updated by Davide Pesavento over 3 years ago

  • Target version changed from 22.02 to 22.12
Actions
Copy link
 #23

Updated by Davide Pesavento about 2 years ago

  • Target version deleted (22.12)
Actions
Copy link

Also available in: Atom PDF