RE: fixed wireless mesh

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is just one of the several problems related to mobility (and not only) that require an approach that is not limited 'by charter' to a specific layer. I think that it is a positive evolution that standard bodies like IETF, IEEE and other allow for the best minds to gather, and perform the cross-layer analysis that is required, as well as suggest solutions that may cross the traditional layer and standards organization boundaries. We can just hope that solutions will be found for this kind of cooperation to be enhanced in the future, whenever needed. The times when the IETF was trying to solve all the world networking problems at IP layer and higher, while the IEEE was trying to do the same at link layer and lower are hopefully gone. 

Dan
 

> -----Original Message-----
> From: Vernon Schryver [mailto:vjs@calcite.rhyolite.com]
> Sent: 07 August, 2003 1:40 AM
> To: ietf@ietf.org
> Subject: Re: fixed wireless mesh
> 
> 
> > From: Iljitsch van Beijnum <iljitsch@muada.com>
> 
> > > xactly what in http://www.ieee802.org/16/docs/03/C80216-03_07.pdf
> > > could possibly be a reasonable topic for the IETF to consider?
> >
> > I look forward to seeing the IEEE reinvent the network 
> layer and put it 
> > _below_ the link layer. This should be fun.
> 
> How is the IEEE reinventing the network layer this time?  They really
> have tried in some previous efforts, but I don't see that this time.
> 
> ARQ and FEC can be quite desirable in some link layers, particularly
> those that would otherwise have error rates higher than the quite
> low error rates that TCP readily tolerates.
> 
> 
> > (What else than a network layer would you call something 
> that resolves 
> > "end-to-end" addresses into next hop addresses, which is 
> necessary to 
> > navigate across the mesh. 
> 
> What end-to-end addresses in the IP sense are you talking about?
> 
> >                           This would also need some sort of routing 
> > protocol and a hop limit field.)
> 
> I agree they'll need some sort of routing protocol, but despite my
> religious affliation with the Churches of RIP and IP, I do not see
> that a "hop limit field" is a requirement.  They will need to prevent
> or deal with loops, but IP-style decrementing TTL or RIP-style
> incrementing metric fields are not the only way.  For example, perhaps
> they could make timestamps work.  Or perhaps they can somehow 
> guarantee
> that loops are impossible.
> 
> Do you really think that the rest a path through the Internet would
> benefit from the route flapping and apparently random decrementing
> of the IP TTL field if they were to use the IP TTL field to deal
> with loops?
> 
> Regardless of the technical issues, do you really think that only the
> IETF is allowed to think about routing protocols?  It's decades late
> to worry about the IEEE crossing the trade union lines by looking at
> routing given the existence of link layer routing protocols including
> Spanning Tree.
> 
> Do you think that the IETF should be in charge of add-drop protocols
> for link layers that have those?  After all, those protocols involve
> addresses and a kind of routing and those link layers often carry IP
> packets.
> 
> 
> > Obviously having wireless mesh nodes route IP would be much 
> too simple.
> 
> That statement is not obvious to me, except in standards committee
> turf war terms.  My intuition does suggest that none of RIP, IGRP,
> EGP, BGP, HELO, or any other IP routing protocol would work well for
> what they're trying to do.
> 
> Besides, could it be that they want to carry data that don't look
> like IP packets?  Do you think the IETF should outlaw such heresies?
> 
> 
> Vernon Schryver    vjs@rhyolite.com
> 
> 



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]