Good question, and (unfortunately) it requires a complex answer.
Typically a routing protocol doesn't care about the link SNR, because routing is done at IP level, and it should be device-independent.
Said so, if your routing protocol is meant to be used for a specific interface type (let's say WiFi), it makes sense to use also the link quality information. As a matter of fact, many routing protocols for LLNs (i.e., 802.15.4 and similar) use something like that - it's just called differently: Link Quality (LQI).
Now, as far as I know WiFi (I'm assuming you want to use WiFi) doesn't forward that info in the normal data path. The WifiPhy/MonitorSnifferRx trace does provide this info, but pairing it with a packet at UDP level will be a serious pain, you'd have to receive the packet twice (one on the trace, one on the UDP socket), then discard everything you don't need (and they're a *lot* of packets), then... a real pain.
My suggestion is to open an issue on our tracker. Adding a SNR tag to the packets forwarded up in the stack should be fairly doable (by the Wifi module maintainers), and you'll have a much cleaner solution. My only real suggestion is to call it Link Quality instead of SNR, and to have it generic, i.e., something like [0...255] where 255 is exceptionally good, and 0 is really bad. That should be more than enough for routing decisions, and your protocol will be more flexible. As a hint. LrWpan uses a LqiTag, defined as "The LQI is the total packet success rate scaled to 0-255."