-
Notifications
You must be signed in to change notification settings - Fork 2.1k
RFC: network layer API #5704
Description
I finally came to write down some of my thoughts about how to re-arrange IPv6 (or more general the network layer), to make the going-ons in routing/NDP/6Lo-ND (I generalize all of them as "routing protocol" in the following) more tracable. The base-idea comes from this paper.
The base idea is that there are 3 interfaces of that there can be multiple implementations (and multiple instances) at runtime:
The send function of the network layer has direct access to the forwarding engines. Other accesses are depending on the actual routing protocol.
The concept of interfaces is encoded in the Addr type, which could e.g. contain a type (e.g. IPv6, need not be gnrc_nettype necessarily), a data field (the IPv6 address), an interface identifier, and maybe the addresses length (e.g. for link-layer addresses).
I've played through some well-known use-cases and found that all of them work-out quite well and clear with this API. Here are a two examples:
- Create default router list:
- IP6RouterDiscoveryEngine::init() on initialized interface
- send MAX_RS every RS_INTERVAL after rand([0 sec, MAX_RS_DELAY])
- RA received
- ND module executes RTR_FOUND with IP6RouterDiscoveryEngine::event() with RA as context and the router's link-local address as tgt
- tgt + info from RA are stored in default router list
- IP6RouterDiscoveryEngine::init() on initialized interface
- Send packet to non-existent neighbor:
- execute FIND_NEIGHBOR with **IP6AddressResolutionEngine::event() (packet as ctx, requested neighbor's IPv6 address as tgt)
- create INCOMPLETE NCE for tgt if NCE does not exists
- queue packet
- send NS to neighbor
- NA received
- ND module executes NEIGHBOR_FOUND with IP6AddressResolutionEngine::event() with NA as context and neighbor's address as tgt
- Update neighbor cache and timers
Likewise should basically any timer event be executed as a RoutingEngine::event().
Open questions:
- Should IPv6 interfaces be associated with RoutingEngines? If yes, how?
- Should the handler of timer events be the network layer thread (as it is currently the case) or an external event handler (a version of the dreaded libevent e.g.)?
