You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: pkg/fw/README.md
+49Lines changed: 49 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -38,3 +38,52 @@ The main differences from a full forwarder include:
38
38
* Forwarding hint is not stripped even if it matches a configured node name.
39
39
40
40
These are subject to change.
41
+
42
+
## Prefix Registration / Readvertisement
43
+
44
+
Unlike many other NDN libraries, NDNts does not hard-wire prefix registration toward a particular forwarder.
45
+
Instead, the prefix registration functionality is structured more like a router:
46
+
47
+
*`FwFace` can *announce* a prefix into the NDNts logical forwarder.
48
+
* The logical forwarder can then *readvertise* the prefix into a *destination* such as a remote forwarder.
49
+
50
+
NDNts includes several `ReadvertiseDestination` implementation compatible with other forwarders:
51
+
52
+
*`@ndn/nfdmgmt` implements the NFD Management protocol, compatible with NFD and NDNd.
53
+
*`@ndn/dpdkmgmt` implements the NDN-DPDK GraphQL protocol, compatible with NDN-DPDK.
54
+
55
+
After loading either package and attaching to the logical forwarder, prefix registration commands would be transmitted toward the connected forwarder.
56
+
In contrast, if no `ReadvertiseDestination` is attached to a logical forwarder, the producer prefixes from a `FwFace` are visible within the logical forwarder and no prefix registration commands would be sent.
57
+
58
+
A `FwFace` may prevent its prefixes from being readvertised by setting `advertiseFrom: false` attribute.
59
+
If this attribute is set, the prefixes announced by this `FwFace` are only visible within the logical forwarder but ignored by `Readvertise` module.
60
+
This attribute is normally set on a `FwFace` that represents an uplink to a remote forwarder, so that its prefixes (often the default route `/`) do not leak to another uplink that you may be connecting.
61
+
In contrast, having `advertiseFrom: true` attribute (the default) does not magically enable prefix registration commands if you do not have a `ReadvertiseDestination` attached.
62
+
63
+
### Readvertise Module Architecture
64
+
65
+
The readvertise module consists of:
66
+
67
+
* One `Readvertise` class instance integrated with the logical forwarder.
68
+
* One or more `ReadvertiseDestination` subclass instances attached to the `Readvertise` instance.
69
+
70
+
The `Readvertise` class is responsible for:
71
+
72
+
* When a prefix is announced by the first `FwFace`, send an advertise (register) command to each destination.
73
+
* When a prefix is unannounced by the last `FwFace`, send a withdraw (unregister) command to each destination.
74
+
* If the same prefix is announced by multiple `FwFace`s or by the same `FwFace` more than once, it is deduplicated automatically and would not cause duplicate advertise commands or premature withdraw commands.
75
+
76
+
The `ReadvertiseDestination` base class is responsible for:
77
+
78
+
* Maintain a queue of pending advertise and withdraw commands to be processed by the subclass.
79
+
* Maintain a state of each prefix, with one of four statuses: ADVERTISING, ADVERTISED, WITHDRAWING, WITHDRAWN.
80
+
* If an advertise or withdraw command fails, automatically retry the command.
81
+
* If the prefix is withdrawn while an advertise command is being executed, immediately send a withdraw command afterward, to ensure state consistency.
82
+
83
+
Each `ReadvertiseDestination` subclass is responsible for:
84
+
85
+
* Implement the prefix registration protocol understood by the connected forwarder.
86
+
* Actually transmit the advertise and withdraw commands, and inform the base class of the success/failure outcome.
87
+
* If the commands require NDN signatures, manage the signing and certificate publishing.
88
+
* Refresh the advertised prefixes (i.e. schedule resending advertise commands) in case of connectivity change.
89
+
* For example, if `TcpTransport` reconnects to NFD, it would be seen by NFD as a new face, so that every prefix must be registered again to maintain connectivity.
0 commit comments