On 1/22/2015 4:10 AM, Alexandru Petrescu wrote:
Le 20/01/2015 19:23, Joe Touch a écrit :
...
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.
Section 5.2.1.2 indicates that forwarding selects next-hop IP address,
THEN selects outgoing interface for that IP address. Because an
interface can access multiple IP addresses, the number of interfaces
does not limit forwarding.
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.
Using a single interface works fine; it may not be efficient, but it
does allow the router to provide a function that might not be possible
at other routers (e.g., filtering).
So there's no one "best" way, but yes, it's not bandwidth-efficient to
ever forward using a single interface.
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.
Yes. The best way is to have each wifi subnet connected by a router.
This, of course, assumes relatively stable mouvement patterns, i.e.
devices stay within the planned ranges.
Certainly; IP doesn't react well to change ;-)
Not surprisingly, staying stable within planned range is a
characteristic found in many deployments. Devices just dont move
haphazardly.
Yes, but when that interferes with the definition of a subnet, that is
an L2 problem. L3 expects a relatively stable L2.
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.
Exchange points can be anywhere. Wifi subnets can be anywhere.
...
[...]
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.
They really aren't. L3 thinks every next-hop IP address is (by
definition) one L3 hop away. How many L2 - or L1 - hops that takes is
not relevant or visible, except as a cost metric added by a network
operator.
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.
L3 protocols are just algorithms. Whether they're appropriate for a
given L2 depends on the properties of the algorithm and the L2. E.g.,
TRILL extends ethernet L2 to allow use of IS-IS routing - the extension
is needed because IS-IS doesn't avoid transient forwarding loops, and
ethernet does not react well to those.
It is however better to assume that a subnet is built and maintained by
MAC protocols, rather than by IP protocols.
I'm not sure I follow. L3 assumes L2 works; it doesn't fix deficiencies
in a broken L2.
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.
That's true for all L2s.
...
...
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.
It may be, but the WIFI people need to read it, and they read the IEEE
specs.
But there are many recent RFCs that do L2 matters.
L2 interactions with L3. That's not the case here. What you're
describing is an L2 that nobody - even L2 - can't really use. You can't
have a native L2 protocol that used a WIFI network that had a hidden
terminal issue, could you?
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.
All, AFAICT, relate to necessary interactions between L2 and L3. What
you're describing is how to build an L2 that isn't inherently broken.
That seems out of scope IMO.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
