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
- to perform filtering in the process of forwarding
e.g.,
--> A --> B
A sends all traffic NOT coming from
B's interface and IP to B
A <-- B
B sends some subset of the traffic
it receives to A, and dumps the rest
<--A
A uses a different table to forward
all traffic received from B
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. It never corresponds 1:1 to a
subnet link unless the link is unicast.
Full multihop reachability is common in link layers that are complete.
Again, it'd be useful to show something the RFCs haven't already
described. Otherwise this would be better served by a collection of
existing approaches.
I think that's the only draft that describes the hidden terminal problem
in wifi environments.
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.
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.
...
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.
Joe
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
