Le 26/01/2015 19:31, Joe Touch a écrit :
On 1/26/2015 9:17 AM, Dearlove, Christopher (UK) wrote:
Joe Touch
802.11 has a problem when *L2* reachability signals don't
translate to L3 reachability. RFC6130 gets around that by using
control messages that are sent inside L3.
Actually that's not the whole story for IEEE 802.11.
Let me be more clear.
The whole story for IP (L3) is:
(A)- an L2 subnet is *defined* as a L2 network in which every
endpoint can reach every other one (directly or indirectly)
(B)- any group of L2 nodes that does not have property (A) is a set
of one or more L2 subnets.
(C) - Those subnets can be internetworked using L3 (routers) ONLY
where they overlap (i.e., share a node).
Unless you have some sort of filter in place, if HELLO in IP
gets there then IP gets there.
Nor is that. If you care (but this is an aside from the point
here) I'd Google about the 802.11 "grey zone" problem.
But in the general case, ignore that.
Agreed; that problem is one where the routing protocol doesn't
fate-share the regular IP datagram path, and that's also a
well-known problem.
Maybe we should document what is fate-sharing with routing protocols
(ref.) and tell how MANET routing protocols don't really do
fate-sharing when applied in a WiFi ad-hoc mode network.
Some routing protocols assume bidirectional communication,
i.e., if you can send an IP datagram to me then I can send one
to you. But that's only a subset of routing protocols; routing
protocols that support unidirectional links have also been
around for a long time.
In a MANET, they are definitely not the easiest things to do with
any degree of reliability.
Routing protocols don't need reliable links. The reliability of
E2E paths does depend on a variety of properties, and certainly
maintaining E2E reliability with wildly fluctuating links is a
problem, but it is addressed by using a different routing protocol
(at best).
I agree routing protocols dont need reliable links. When a link
flaps a routing protocol declares it as off.
There are some gray zones in which links are characterized by their
bandwidth instead of on/off (OSPF). But there are no metrics which
characterize wifi links as this draft characterizes them.
E.g. a metric 'link ends kind' could value 1 if both its ends where
hidden terminals, 0 otherwise.
Joe Touch
You find them using local broadcast.
The PILC doc explains why this is a bad idea unless L2 is known
to support broadcast. The L2 you're describing fails that
assumption.
Which L2 I'm describing? I haven't described an L2. (I made an
aside about 802.11, which actually does support local broadcast,
so you can't mean that.)
(I should have said "the L2 described in the draft")
The RFC implies that control reachability implies IP
reachability.
No, it really doesn't for routing purposes (e.g. RFC 7181 - RFC
6130 is not itself a routing protocol).
It does as described in RFC6130. That doc makes no mention of the
802.11 gray zone issue of using a different encoding.
Again, it's well-understood that routing protocols need to
fate-share reachability of IP data packets. That's the assumption
behind the section I cited (HELLOs go in IP packets; if the HELLO
gets there, an IP packet got there).
Because A can locally broadcast and it reaches B, who A may not
even know exists, does not make a unicast link A to B useful.
I said "The RFC implies that control reachability implies IP
reachability." I didn't say that resulted in bidirectional
reachability - that's for a routing protocol to determine based on
unicast discovery.
(though RFC6130 isn't quite a full routing protocol; it's just the
discovery portion)
It does not imply that unidirectional reachability implies
bidirectional reachability. When B receives a HELLO from A,
then B knows it can get IP datagrams from A (that's a leap that
the doc makes because it HELLOs are sent inside IP datagrams).
It knows it can get locally broadcast IP datagrams from A. Not
sufficient.
Agreed - 6130 isn't a full routing protocol; the full protocol is
required to take the *unidirectional* reachability of 6130 and
determine bidirectional reachability.
It might help us understand what you want to do if you just say
it:
You realise I'm not an author of the current document? I'm just
pointing out you're missing things when you're attempting to say
"nothing new here, all completely understood". We have experience
that's not so.
So far, "your" experience (you, the authors, the MANET community)
keeps asserting that there's something magic about that environment
that the Internet architecture and protocols haven't considered.
I work in these environments. I know they are different than wired,
even though maybe not magic.
The problem with MANET routing protocols is that they try to
accommodate all possible kinds of networks made of wireless links,
with purely arbitrary mouvement patterns.
Whereas most wireless links are designed with particular topologies
and use-cases in mind. There's not a single 'universal' wireless
link. Some apps are possible on some links and other apps on other
links.
That said, I still think a draft about the peculiar behaviour of
WiFi, especially in ad-hoc mode, is worth documenting, because it has
implications on other protocols.
