Message info
 
To:Teco Boot From:John Dowdell Subject:Re: [manet] DLEP and multi-hop neighbours Date:Fri, 30 Mar 2012 16:58:20 +0100
 

For me, routing traffic over DLEP-based networks should get away from
min-hop strategies, but should be based on the attributes of the
connections between nodes (however many hops that takes).

However, when you want to manage the bandwidth across your network, you
need to understand the topology of the network.

An example: A, B and C are network nodes, each with a router and radio.

A ------ B -------- C, and C has no direct connection to A because of
obstruction or insufficient range.

Suppose the bandwidth A to B is 10 units, and the bandwidth B to C is 5
units.

Suppose radios A, B and C reported all N-hop neighbours without
reporting hop count or the address of the node they were relaying
through. The DLEP reports at A might show to B as 10 units and to C as 5
units. IMHO I would like to see neighbours reported with relay
address(es) rather than hop counts. Oops, this starts to look like a
routing table .... is that the job we are trying to do here?

When policing traffic bandwidth at A towards B, the policer will believe
there are 10 units available. Towards C, the policer will believe 5
units are available, without understanding that the 5 units to C are
part of the 10 units between A and B.

Reporting latency without hop count is not a problem, because the values
are additive, but for bandwidth there is an issue. Link Quality and
Resources metrics have their own issues.

John

-----Original Message-----
From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
Of Teco Boot
Sent: 30 March 2012 15:30
To: Rick Taylor
Cc: manet@ietf.org; sratliff@cisco.com
Subject: Re: [manet] DLEP and multi-hop neighbours


Op 30 mrt. 2012, om 16:07 heeft Rick Taylor het volgende geschreven:

> Nelson,
>
> Okay, "problem" might be too strong, I agree with "feature".
>
> I do understand why radios might behave in this manner, and don't want
> to see it actively prevented, but a slightly simple/basic radio
mesh-net
> (such as we have seen with the kit we are using) reporting all
> neighbours as fully connected although the reality is traffic is
routed
> via an elected cluster-head can result in routers subjecting the
> cluster-head to a massive burst of traffic, which the routers were
> actively trying to avoid doing.
>
> In summary, I would like to see some kind of notification TLV if the
> reported neighbour is on the far end of a 'dog-leg' via another
reported
> neighbour, i.e. the route to the neighbour is not 'direct' (for a
> relatively loose definition of direct). I was suggesting a hop-count
TLV
> as a mechanism, but if you or anyone else on the radio-side of DLEP
has
> a better suggestion, go for it!

Yes, we try to get rid of min-hop based routing. That is where
DLEP comes in. I understand the sub-IP layer multi-hop routing,
but I think you should push getting useful info from such "modems".

Another example would be a 2-hop satcom link, where hub is 1-hop
and other spokes are 2-hop (seen from a spoke).

Let's try to get the link metrics already defined in dlep-02 from
these devices. Hop-count in a heterogenous network gets messy easily.

Teco


>
> Rick Taylor
>
> -----Original Message-----
> From: Powell lll, Nelson [mailto:npowell@harris.com]
> Sent: 30 March 2012 14:32
> To: Rick Taylor; manet@ietf.org
> Cc: sratliff@cisco.com
> Subject: RE: DLEP and multi-hop neighbours
>
> Rick,
> I'm not sure it is a "problem" so much as it is a feature. Allowing a
> radio to behave as a "neighbor" allows for more intelligent waveforms
to
> handle the routing internally. If a hop-count were added, I would
> imagine that should be more an optional TLV, as intelligent waveforms
> may use latency in a similar manner.
>
> Nelson
>
>
> -----Original Message-----
> From: manet-bounces@ietf.org [mailto:manet-bounces@ietf.org] On Behalf
> Of Rick Taylor
> Sent: Friday, March 30, 2012 6:35 AM
> To: manet@ietf.org
> Cc: sratliff@cisco.com
> Subject: [manet] DLEP and multi-hop neighbours
>
> As part of our on-going work with DLEP, we have discovered a problem
> with the definition of a neighbour on a DLEP session.
>
> In a smart meshing radio network, each DLEP radio could report all its
> multi-hop link-neighbours as DLEP neighbours. This is valid according
> to the wording of draft-02, but is misleading to any router attempting
> to discover the topology of the actual radio network.
>
> A proposed resolution to this problem is rather than force only 1-hop
> neighbours to be reported via DLEP, add an extra 'hop-count' TLV to
the
> NeighbourUp message. Of course adding an extra TLV just for a single
> octet seems like a lot of extra data, perhaps the RFC5444 gurus can
> suggest a more elegant method? Or perhaps the absence of the hop-count
> TLV implies a 1-hop neighbour?
>
> Rick Taylor
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet@ietf.org
https://www.ietf.org/mailman/listinfo/manet