Le 20/01/2015 19:23, Joe Touch a écrit :
On 1/20/2015 10:04 AM, Alexandru Petrescu wrote:
Le 20/01/2015 18:33, Joe Touch a écrit :
On 1/20/2015 9:18 AM, Alexandru Petrescu wrote:
Le 19/01/2015 22:45, Joe Touch a écrit :
+1
A link layer that cannot reach all its members isn't a link
layer - it's multiple link layers that need interconnection.
That's what routers are for.
I agree.
But we have no document that tells that a Router must have two
interfaces,
That's because that requirement does not exist.
A router can exist with one interface, e.g.:
- to forward between devices on the same subnet forwarding involves
both outgoing interface AND destination IP
That leads to undetermined and 'disconnected' subnets as long each
machine in it IP routes.And prefixes are off-link (RFC number).
Please see RFC1812.
This RFC1812 "reqs for Routers" does not talk explicitely 1-interface
routers, although it does mention logical and physical interfaces.
I agree that a Router can forward between two logical interfaces, both
attached to a sole physical interface. And that it can run forward
between a sole physical interface, absent logical interfaces.
But it is not a good way for WiFi subnets.
The best way for wifi adhoc subnets is to separate subnets guided by
power their range, with a different channel on each subnet, and a
different on-link prefix, and use 2-physical-interface routers. And
each router to route between 2 physical interfaces.
This, of course, assumes relatively stable mouvement patterns, i.e.
devices stay within the planned ranges.
Not surprisingly, staying stable within planned range is a
characteristic found in many deployments. Devices just dont move
haphazardly.
This method is used in exchange points, among other places.
I guess that means deep in the core network, whereas here we are at the
edge.
...
[...]
and hence Routers with 1 interface are built and hence the
confusion of 'multi-hop' which needs a clarification in the form
of the statement you put above.
In L3, hop is always to an IP address.
YEs, but the problem is when L3 and L2 are mixed by 1-interface routers
making up L2 subnets: two nodes in range are 1-hop away from each other,
be it a MAC hop or an IP hop.
Link layer hops don't necessarily have anything to do with L3 hops.
I agree, but they are mixed together when using 1-interface routers.
But when out of range they're 2 IP-hops
from each other, although they're still 1 MAC-hop away.
That's an issue for L2.
I agree.
But I still do not know whether IP routing protocols should be used at
MAC level.
It is however better to assume that a subnet is built and maintained by
MAC protocols, rather than by IP protocols.
With 802.15.4 networks, one rather assumes the subnet is maintained by
that MAC, and run IP over it as if it were one single hop, rather than
running RPL.
Hidden terminal in Wifi is an L2 issue. The L3 issue is broadcast
reachability. PILC already discusses the hazards when a subnet
doesn't support (true) broadcast.
I.e., in a wifi net with hidden terminal issues, you no longer have
true broadcast, and shouldn't assume so. But that's also why most of
our protocols have shifted from use of broadcast to multicast --
which would work fine with hidden terminal IF the subnet layer
managed it properly.
Hmm, I agree with the first part. But if true broadcast is absent in
hidden-terminal wifi networks, multicast would be difficult to ensure as
well.
In that case, multicast support would be provided by unicast
reachability in L3.
The draft also describes radio range limitations which are common
in WiFi, but have no related description in other RFC. I don't
mean the problem has no wired counterpart problem, but that they
are not described in existing RFCs.
You would then be describing the impact of existing RFCs in terms of
Wifi. That might be useful, but I don't think it warrants creating
new mechanisms or solutions unless you can demonstrate they don't
exist elsewhere.
However, limited radio range has been an issue for Internet
protocols since the ARPAnet days.
Uh? I guess when they came up with IP routing to offer range extension
the notion of IP subnet did not exist?
IP subnets have been around a very long time, but not all mechanisms are
developed in the context of what has already been done before. That's
what I'm suggesting should be avoided in this case.
Ok.
...
This WiFi range problem is described only in this draft.
This Ethernet length problem is not described in any RFC.
Right. The point is that there's a reason we don't bother with the
ethernet range issue in an RFC, and that same reason may apply here
to your wifi observations.
Maybe we need to explain in this draft this: why it would be good to
give less consideration to range issues, in wifi. Or to explain that
range is dictated by regulated power and spectrum sharing agreements. I
dont know?
These all sound like L2 (or maybe even L1) issues, and out of scope for
RFCs AFAICT.
Some times I think that is a very good advice.
But there are many recent RFCs that do L2 matters.
In the not so distant past, only PPP and ARP were famous for doing L2 in
an RFC. But recently there are very many RFCs doing L2 matters,
especially in the field of IoT.
Alex
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
