Skip to content

RFC: network layer API #5704

@miri64

Description

@miri64

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:

network-layer

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:

  1. 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
  2. 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.)?

Metadata

Metadata

Labels

Area: networkArea: NetworkingDiscussion: RFCThe issue/PR is used as a discussion starting point about the item of the issue/PRType: cleanupThe issue proposes a clean-up / The PR cleans-up parts of the codebase / documentation

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions