Incremental Deployment of HNCP and IGPs in home networks
Halle
06114
Germany
cyrus@openwrt.org
Internet
Homenet Working Group
IPv6
Homenet
DNCP
HNCP
This document describes an incremental approach towards deploying
HNCP and routing protocols
in home networks. Its aim is to provide a minimal, forward-compatible
transitional extension to HNCP to promote testing, deployment and
adoption of homenet technology while the IGP decision and standardization
process is not yet finalized.
While it is expected that the average number of routers and their
hardware and software capabilities in a typical home network will
grow over time, this trend has historically been gradual.
Thus it can be expected that in the near future there will most
likely be not more than a handful of routers in a home and their
capabilities for operating in a fully-routed mode are limited.
It is also hard to predict which types of other networks the homenet
technology will be used in and what attributes these networks will have
(e.g. number of routers, links, link-types, topologies, suitable methods
for detecting link-layer status and deriving metric). Furthermore the
standardization of autoconfiguring and source-dest-routing capable
protocols is not expected to be finalized soon and there is currently a
shortage of widely testable or deployable implementations fulfilling
these criteria.
These issues and a general lack of consensus over an all-purpose
routing protocol support a transitional forward-compatible extension
to HNCP implementations
in order to advance homenet progress and to promote adoption. This draft
describes a solution sufficient for small networks allowing gradual
adoption of homenet principles into existing networks while ensuring
an easy transition to a future standardized version.
Each homenet router runs an incremental connectivity algorithm
at all times on each network interface it is running HNCP on and can
optionally additionally run one or more routing protocols.
A router running a routing protocol alongside the incremental
connectivity algorithm must strictly prefer all routes of the routing
protocol over all routes generated by the incremental connectivity
algorithm, except for those having destinations not already known
to the routing protocol but that lie within one of the designated
prefixes of the homenet (i.e. prefixes assigned by a homenet router
that does not speak the respective routing protocol).
In case of routers running more than one routing protocol alongside the
incremental connectivity algorithm, all such routers in the homenet
ensure that in doing so they do not cause routing loops, e.g. by
agreeing upon a network-wide order in which routes of the protocols
are considered.
This algorithm is designed to provide connectivity in small home
networks that would not benefit from exploiting link characteristics
or metrics. It is intentionally kept simple to require no additional
TLV-information by reusing existing topology and address assignment
information provided by HNCP and only requires minimal implementation
overhead.
Each homenet router traverses the HNCP neighbor graph using
a breadth-first search starting with its own node's immediate neighbors.
Neighbors of a node are traversed in ascending order of their
node identifier. During traversal the router determines the path to each
other router (R), the next-hop neighbor N(R) and the number of hops to it D(R).
The router then creates routes based on the following rules:
Create a route
To
From
Via
Metric
For each Prefix (A) in an Assigned Prefix TLV of any Router (R)
A
any
N(R)
D(R)
For each IPv6 prefix (P) in a
Delegated Prefix TLV of any Router (R)
::/0
P
N(R)
D(R)
For the first Router (R) traversed that
announces an IPv4 Delegated Prefix TLV
0.0.0.0/0
any
N(R)
D(R)
This process is repeated every time the router detects a change in the
neighbor graph or prefix assignment information in the network.
The mechanism described in this document is based on HNCP,
thus security considerations for this document are already covered
by .
This document has no actions for IANA.
Thanks to Pierre Pfister and Markus Stenberg for comments and suggestions.