1. Route Readvertise Junxiao Shi, 20160907 1

2. Introduction This document proposes a program to readvertise routes from one route origin to another. The initial use case of this program is a deployment on the NDN testbed to readvertise a route registered by NFD-RIB auto prefix propagation into NLSR routing protocol. 2

3. External relations 3 NFD-RIBNLSR readvertise prefix registration (auto prefix propagation) route change notificationNLSR prefix update command LSA

4. Basic workflow 1.End host auto prefix propagator sends a prefix registration command to router NFD-RIB. 2.NFD-RIB posts a route change notification. 3.Route readvertise program receives notification, and invokes NLSR prefix update command. 4.NLSR advertises or withdraws the name prefix in routing system. 4

5. Internal architecture 5 RIB monitor policy evaluator readvertised route table NLSR communicator configure parser

6. NFD-RIB route notifications NFD-RIB should provide a route change notification stream, and post a notification whenever: a route is added a route is removed a route is updated (cost or inheritance flags) This one is not directly needed by route readvertise Dispatcher limitation on notification stream: Dispatcher currently disallows notification stream when multiple top prefixes (such as /localhost/nfd and /localhop/nfd) are enabled. This limitation needs to be lifted. 6

7. RIB monitor RIB monitor receives notifications about route additions, updates, removals from NFD-RIB. RIB monitor can also periodically request RIB dataset to workaround missed notifications. 7

8. Policy evaluator Policy evaluator determines: whether a route should be readvertised what name prefix should be readvertised (e.g. it may aggregate multiple RIB routes as one shorter prefix into the routing protocol) which routing protocols should the name prefix be readvertised into 8

9. Policy evaluator – initial policy All routes with auto prefix propagator origin should be readvertised as the same prefix into NLSR. Unless, the route has same prefix as a name prefix already advertised by NLSR through static configuration. Until #2856, NFD-RIB does not confine registered prefix within identity of signing certificate. Without this rule, a malicious user can register a prefix equal to a statically configured prefix then unregister it, and cause route readvertise program to withdraw the name prefix in NLSR. 9

10. Readvertised route table Readvertised route table is a container of readvertised routes. Each entry contains: RIB routes that caused the readvertising name prefix being readvertised destination routing protocol Multiple entries are created if the same name prefix is readvertised into multiple routing protocols. Example: ndn:/example/alice and ndn:/example/bob have caused ndn:/example to be readvertised into NLSR 10

11. Readvertised route table Each entry also contains a state field indicating whether the last readvertising command was successful, and when the next retry should occur. The state transitions are similar to NFD-RIB auto prefix propagator. Readvertised route table is responsible for triggering retries, if the previous readvertising has failed. 11

12. Routing protocol communicator Each routing protocol communicator handles communication with a specific routing protocol. The communicator is only responsible for sending a single advertise or withdraw command. Retrying should be triggered from readvertised route table. NLSR communicator uses NLSR management protocol to advertise and withdraw routes in NLSR. 12