Subject: [manet] Neighbor addresses in OLSR HELLO messages

From: [email-masked]
Date: Wed, 09 Apr 2003 10:14:00 -0700

In the latest OLSR draft, it is not clear whether HELLO 
messages contain the "main addresses" or the interface 
addresses of neighbors. Previous versions of OLSR used 
the term "Neighbor Interface Address" to describe these 
addresses, but the current version changed this to 
"Neighbor Address", defined as "An address of a neighbor node".

What does "an address" mean?  Interface address or main address?

On page 27 it is stated that the neighbor *interface* addresses
(L_neighbor_iface_addr) are advertised in a HELLO.

However, page 33 says the following, which implies that the
neighbor addresses in a HELLO are *main* addresses:

     1    for each address (henceforth: 2-hop neighbor address), listed
          in the HELLO message with Neighbor Type equal to SYM_NEIGH or
          MPR_NEIGH:

          1.1  if 2-hop neighbor address = main address of receiving
                node:

This seems inconsistent to me, but I could be missing something.
I was assuming that OLSR uses interface addresses in HELLOs
(there was a previous discussion about why it is important for 
HELLOs to advertise interface addresses in wireless networks),
but there must be some reason for the above changes.

Regards,
Richard

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 9 Apr 2003 21:38:22 +0200

Richard,

Your observation is correct, this is slightly inconsistant in the
text. HELLO messages do advertice interface adresses, so your
understanding is correct, it seems. We've already clarified this in
the version which we will submit to the IETF shortly (within this
week).

Thanks for being alert :)

--thomas

On Wed, 09 Apr 2003 10:14:00 -0700
[email-masked] wrote:

>           in the HELLO message with Neighbor Type equal to
>           SYM_NEIGH or MPR_NEIGH:
> 

-- 

-------------------------------------------
  Thomas Heide Clausen
  Civilingeniør i Datateknik (cand.polyt)
  M.Sc in Computer Engineering

  E-Mail: [email-masked]
  WWW:    http://www.cs.auc.dk/~voop
-------------------------------------------
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Sat, 12 Apr 2003 09:25:31 -0700

> the version which we will submit to the IETF shortly (within this

I was hoping you would explain *why* these changes
were made that led to the inconsistency.

It looks like you want to use neighbor interface addresses
for the purpose of discovering 1-hop neighbors (and neighbor
interfaces), but you want to use main node addresses (RIDs) 
for the purpose of discovering 2-hop neighbors, since the
main addresses of 2-hop neighbors are useful for computing
MPRs.  (You want MPRs to cover all 2-hop neighbor nodes, 
not all 2-hop neighbor interfaces.)

I guess you could have it both ways, i.e., a HELLO would
include neighbor interface addresses ONLY for neighbors
that have multiple interfaces that use the same channel
(e.g., for multiple beams of a directional antenna).
Nodes with this property would set a bit in their HELLOs 
to indicate this.

This is one advantage of protocols (e.g., TBRPF and OSPF)
that do not use HELLOs for discovering 2-hop neighbors 
(so the above problem does not occur).  TBRPF and OSPF use 
topology updates for that purpose, which contain RIDs.  
Another advantage is modularity, e.g., so that the same HELLO 
protocol can be used by other routing protocols that do not 
need 2-hop neighbor information. 

I should mention that our TBRPF update (to be submitted in the 
next few days) uses only neighbor interface addresses (instead 
of neighbor RIDs) in HELLOs. The need for using neighbor interface 
addresses in wireless networks was discussed previously 
on the manet list, and Philippe Jacquet recently reminded
me of this, which convinced me to make the change.
The problem is that a node with a directional antenna can
have multiple interfaces that use the same channel, corresponding 
to different beams.
Thus, two different local interfaces could be used to reached 
the same neighbor interface. If HELLOs do not contain neighbor
interface addresses, a node may not know which local interface 
is actually heard by the neighbor.

Note that OSPF (v2 and v3) uses only neighbor RIDs in HELLOs, 
so it cannot support directional antennas.

Regards,
Richard

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 12 Apr 2003 20:16:18 +0200

Dear Richard,

Thanks for your email. I will clarify below in the text.

On Sat, 12 Apr 2003 09:25:31 -0700
[email-masked] wrote:

> > understanding is correct, it seems. We've already clarified this
> > in the version which we will submit to the IETF shortly (within
> > this week).
> 

<SNIP> 

> need 2-hop neighbor information. 

Well, if you understand well OLSR, the modularity is there as well.
Basically, there are four seperate activities:

	- link sensing,
	- neighborhood discovery (or "discovering two-hop neighbors", as you
	  call it),
	- MPR selection signalling,
	- global link-state diffusion.

Since the three first (link sensing, neighborhood discovery and MPR
selection signalling) "are locally scoped", i.e. involves a node and
its neighborhood, a common signalling mechanism is employed: periodic
exchange of HELLO messages.

You could - of course - employ one message type for each activity if
you really want to emphasize "modularity". Algorithmically, this is
no change from what we do in OLSR. However you would potentially end
up transmitting exactly the same address in three different messages
- i.e. you would just generate more protocol overhead that way.

So we've choosen to propose the same mechanism for the three "locally
scoped" activities in order to not generate a lot of "unnecessesary"
control messages.

Now, as to why the inconsistancy in the text appeared: between v7 and
v8, we did a large editorial change to simplify the description of
multiple interfaces. The inconsistancy simply slipped in during the
editorial process.

I do believe, that keeping interface addresses in the HELLO messages
is the right thing for OLSR: it allows fine-grained control of which
actual links exists between neighbor nodes, even in the case where a
node has directional antennas operating within the same frequency
range or other such oddities :) 

> is actually heard by the neighbor.

I am not sure what exactly you are saying in the above: will TBRPF
choose not to support nodes with multiple interfaces? Or will there
be a future version of the TBRPF-specification, which supports this?

> so it cannot support directional antennas.

I believe that if OSPF (any version) was directly appliable in
MANETs, then the MANET wg would not exist :) So it's only natural
that we need to, occationally, design beyond what is in OSPF.

--thomas

--

---

From: [email-masked]
Date: Sat, 12 Apr 2003 12:35:10 -0700

Thomas,

> you really want to emphasize "modularity". Algorithmically, this is

I thought the working group consensus was that modularity
*should* be emphasized.

> - i.e. you would just generate more protocol overhead that way.

TBRPF has managed to avoid most of this redundancy, by using 
only differential HELLOs, and reporting neighbors periodically
only in topology updates.  I realize that OLSR could do the same,
so my point is that maybe OLSR (or the final proactive protocol)
should do something like this to achieve better modularity.

> be a future version of the TBRPF-specification, which supports this?

TBRPF has supported multiple interfaces for a long time, but
the inclusion of neighbor interface addresses in HELLOs
(which as I said will be in the version to be submitted in
a few days) will allow the support of directional antennas.

> that we need to, occationally, design beyond what is in OSPF.

Really?  Then maybe we haven't been wasting our time developing OLSR 
and TBRPF. :)  Actually, I meant more specifically that the use of
RIDs in OSPF HELLOs prevents it from supporting directional antennas.
I'm not sure whether Fred Baker considered this in his proposed
modifications to OSPF.

Regards,
Richard

---

From: Thomas Heide Clausen <[email-masked]>
Date: Sat, 12 Apr 2003 22:40:28 +0200

Dear Richard,

On Sat, 12 Apr 2003 12:35:10 -0700
[email-masked] wrote:

> > > > Your observation is correct, this is slightly inconsistant in
> > > > the text. HELLO messages do advertice interface adresses, so
> > > > your understanding is correct, it seems. We've already
> > > > clarified this in the version which we will submit to the
> > > > IETF shortly (within this week).
> > > 
> > Well, if you understand well OLSR, the modularity is there as
> > well. Basically, there are four seperate activities:
> > 
> > 	- link sensing,
> > Since the three first (link sensing, neighborhood discovery and
> > MPR selection signalling) "are locally scoped", i.e. involves a
> > node and its neighborhood, a common signalling mechanism is
> > employed: periodic exchange of HELLO messages.
> > 
> > You could - of course - employ one message type for each activity
> > if you really want to emphasize "modularity". Algorithmically,
> > this is
> 

I think that there was some discussion on "designing independant
modules/components" at some point, but I don't think it ended out in
a decission for the wg? If it did, then it failed misserably,
considering that we have four complete protocols and no seperated
"modules".

That said, I believe that modularity is emphasized in OLSR. As I said
it's basically a matter of seperate activities, which just happen to
benefit from the same signalling mechanism. Actually, I even think
(if you really insist to do so) that with the notion of link codes in
the OLSR spec, it is possible for an implementation to emit seperate
HELLOs for each activity. I.e. a "link-sensing-hello", a
"MPR-signalling-hello" and a "neighbor discovery hello" independantly
(Ok, a neighbor type of "unknown" might be required for this to work,
but you could stick in a bit for that - again, if you *really* want
to do this).

Of course, a node will then send three times as much control
messages, so noone would probably ever do so - which is why OLSR is
designed such that these three signalling mechanisms can be combined.
I do not think that this in any ways compromize modularity. Rather, I
think it is a good combination of modularity and low overhead.

> > no change from what we do in OLSR. However you would potentially
> > end up transmitting exactly the same address in three different
> > messages- i.e. you would just generate more protocol overhead
> > that way.
> 

I am not sure that the question is one of "which protocol is more
modular" at this point. I believe that one could argue that "doing
neighbor updates with topology updates is not very modular since they
are fundamentally different activities", but I don't think that this
is a very constructive exercise, and I won't go into that. 

As for approaches for the "final proactive protocol", I'd be happy to
discuss such when we get a little closer to actually engineering that
protocol. Currently, the WG is still shaping the future charter and
pushing the exp. protocols forward.

However basically (as I believe I have said before, I think in
London), I think that an important first step will be to define the
"information sets" (to use an OLSR term) that the algorithm(s) will
operate on. E.g. the content of a "local link set" and a "topology
set" (etc) - which will form the interface between the "information
being exchanged" and the "algorithms". The actual method for
population of these sets is an orthogonal issue (where we can start
arguing performance, overhead, differential- vs. full- vs. periodic-
vs. whatever-updates), but we will have a framework for such
arguments - and it may even be possible to have two fundamentally
different mechanism "populate" the same information set. Once we've
gotten this initial design ironed out, we can start investigating how
things can be tuned, how different signalling mechanisms can feasibly
be combined etc. 

However I think that this is somewhat premature at this point - or at
least, that we should discuss such under a different subject-line to
get as many peoples input as possible.

<SNIP>

> > 
> > I am not sure what exactly you are saying in the above: will
> > TBRPF choose not to support nodes with multiple interfaces? Or
> > will there be a future version of the TBRPF-specification, which
> > supports this?
> 

Ok, I will be looking forward to reading that spec. How much does
that change of the operation(s) in TBRPF?

> Really?  Then maybe we haven't been wasting our time developing
> OLSR and TBRPF. :) 

Well, if nothing else then we've had fun doing it. Even better if
what we've done has been usefull for someone, right :)

--thomas

> Actually, I meant more specifically that the
> use of RIDs in OSPF HELLOs prevents it from supporting directional
> antennas. I'm not sure whether Fred Baker considered this in his
> proposed modifications to OSPF.
> 
> Regards,
> Richard
> 
> > 
> > --thomas
> > 
> > > Regards,
> > > Richard
> > > 
> > 
> > 
> > -- 
> > 

--

---

From: [email-masked]
Date: Sat, 12 Apr 2003 15:22:40 -0700

Thomas,

> designed such that these three signalling mechanisms can be combined.

The three different control messages could be put into the same packet,
so the question is how much additional overhead would occur, due to 
the same node appearing redundantly in multiple messages.

The way OLSR is designed, you are right that a lot of redundancy
would occur.  But the main reason for that is that OLSR reports
neighbor information periodically even when differential reporting
is sufficient.  (TBRPF is one example of how neighbor sensing can be
done with differential reporting.)  MPR updates also can be differential,
since the MPR selector only needs to report its selected MPRs
to the MPRs themselves, and not to new neighbors.
(There are simple ways to do this reliably, which we don't need
to discuss now.)

Of course, I am not suggesting that you modify OLSR now.
I am talking about how to design the final proactive protocol.

> I am not sure that the question is one of "which protocol is more modular"

If you read my above paragraph again you will see that that was not my point.
My point is "Which way should it be done in the final protocol?"

> at this point. I believe that one could argue that "doing

That depends on what you mean by "doing neighbor updates".
I am talking about discovering 2-hop neighbors via topology updates, 
not 1-hop neighbors (which are done with HELLOs).
2-hop neighbors are not really neighbors (in the sense of most routing
protocols like OSPF).  So 2-hop neighbor discovery is usually considered 
part of topology discovery.  However, if some application needs
ONLY 2-hop neighbor information and not information for > 2 hops,
then one can easily separate topology updates into those that
report local links (to neighbors) and those that report non-local links.
(Or one can simply limit the scope of the routing protocol to 2 hops.)

> pushing the exp. protocols forward.

OK.  Maybe I am a bit early.  But you know the expression:
"Better early than never."  

> things can be tuned, how different signalling mechanisms can feasibly

I disagree!  It was Atlanta, not London. :)
Actually, it sounds like a good plan.

> that change of the operation(s) in TBRPF?

Not much, really.  It is mosly a matter of defining local links
to go to neighbor interfaces instead of to neighbor nodes
(as in OLSR). Topology discovery is not affected since it uses RIDs.

> what we've done has been usefull for someone, right :)

Right. 

Regards,
Richard

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Apr 2003 08:07:00 -0700

At 08:16 PM 4/12/2003 +0200, Thomas Heide Clausen wrote:
>I believe that if OSPF (any version) was directly appliable in MANETs, 
>then the MANET wg would not exist :) So it's only natural that we need to, 
>occationally, design beyond what is in OSPF.

I was the chair of the IET at the time the working group was formed. It was 
understood to be a research group, and would have been sent at the time to 
the IRTF if the IRTF had been functional; it was barely so at the time, so 
the IETF picked up the group and gave it a fair bit of leeway.

At the time, we felt there was quite a bit of room for experimentation, and 
that we didn't want to prejudge questions like whether or not OSPF was 
usable for the purpose. The WG/RG - take your pick - came up with a number 
of protocols that experimented with various aspects of the problem. This is 
was expected.

However, none of the manet proposals has addressed its own use in a 
non-manet network, which means that if someone has a manet that interacts 
with a static network, they at lest nominally have to exchange prefixes 
between two routing protocols. Operationally, I won't call that a 
non-starter, but it is a huge impediment; every device that might operate 
in either way must be configured twice, and someone needs to think very 
carefully about the policies for leaking routes between them. This is 
non-trivial in the extreme. Finding a way to run one protocol - whatever it 
is - in both the manet and the non-manet zone of a network reduces a lot of 
operational issues.

Few of the manet protocols have directly addressed security issues as 
raised in 
http://www.ietf.org/internet-drafts/draft-ietf-rpsec-routing-threats-00.txt. 
Given that no protocol can become an *informational* RFC, much less a 
standard, without seriously addressing security, ...

None has addressed management of the router using the protocol, or even a 
management model. None has addressed scaling of address management issues, 
in the sense that OSPF or IS-IS do in deploying areas, beyond wondering how 
it might reduce message count. None has...

I would count no protocol out of action, whether TBRPF, OLSR, AODV, OSPF, 
or IS-IS. Each has its strengths and weaknesses, and opportunities to 
address those weaknesses. If you want to talk about taking any manet 
routing protocol to Proposed Standard, however, I think it is only fair 
that you assume you will have to jump the same hurdles that the rest of us 
have (RFC 1264, which is probably dated but is what we were measured 
against), and that the protocol will need to be at least as operationally 
useful in a real network run by a real operator, not just one jerry-rigged 
to test certain aspects of research.

And given that none of the protocols have significantly addressed the 
issues that separate the "men" from the "boys" among routing protocols, I 
personally find the continued notes that one or another does particular 
poorly or particularly well on some narrowly chosen test to be a bit 
tiresome. Go finish the job, publish your counterparts to RFC 1245 and 
1246, and then we'll discuss it.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Apr 2003 09:42:05 -0700

Hello Fred,

> of protocols that experimented with various aspects of the problem. This is

In particular, as I remember from the BOFs, there was a great
deal of pessimism that OSPF could possibly do the job, resulting
from experiments that were presented showing that OSPF consumed
120% of the available bandwidth for some particular scenario.
Of course, it would do better in many other scenarios.

> between two routing protocols.

This is true, and is largely a result of the desire to avoid
disseminating host routes into larger routing domains.
The question of ad-hoc subnet formation, address allocation,
and aggregation may be beyond even what is currently reasonable
for the IRTF group.  I'm interested, and would help, but I don't
see anything being standard soon.  It seems to me that OSPF
works better when there is some subnet structure that one can
use effectively for aggregation.  On the other hand, there
is far more about OSPF that I do not know, compared to the
little bit I do know, so if my impressions are wrong I would
appreciate getting the better understanding.

>                                    Operationally, I won't call that a

Maybe this is related to the "hybridization" idea -- in this case,
we need one variant to deal with the nonaggregable parts of the
overall route table, and another variant to deal with the aggregable
part(s).

On the other hand, it is my belief that advances in protocol
design that result from work on ad hoc networks _should_ be
considered for use with other protocols (e.g., OSPF).  Is it
feasible to put this on the charter for manet-ng?

> standard, without seriously addressing security, ...

Maybe so, but my understanding is that the U.S. military is
showing very strong interest in manet protocols.  Joe probably
could say more about that.  The military probably has pretty
strong security requirements.  Putting these two ideas together,
I get that the military is able to live within the realm of
applicability defined by the security properties of the protocols
they are trying to use.  This probably means that they have
some other key management, outside the particular specification
of the routing protocol they may be trying to use.  That at least
allows messages to be authenticated and encrypted under the
particular assumptions in use.

> it might reduce message count. None has...

The management model for ad hoc nodes that I favor, is that
the user does not have to do any management whatsoever.
If my wireless, dynamic, multihop device requires me to type
in anything as complicated as what router experts are used to,
then the result will be almost a total failure.  Thus, I really
think your evaluation is far too harsh.  I would go so far as
to suggest that zero management is preferable to even the slightest
user inconvenience.

In fact, it is my belief that the IETF is driving productivity
to zero by insisting on unsatisfiably universal security demands,
instead of just making sure that protocols are secure for their
particular usage scenarios.  That's like saying since we can't
have everything, then by golly we'll show "them" and have nothing.
Oops, wrong soapbox!  I'll step off now...

> to test certain aspects of research.

I think instead that we ought to characterize the intended use
model well enough that it can be satisfied by something besides
big iron and routing priesthood.  I also think that it is quite
unfair to characterize all of the ad hoc research as jerry-rigging.
Who is Jerry, anyway??  Maybe that terminology is a descendent
of "gerrymandering"?

> 1246, and then we'll discuss it.

Fred, while no one (and least of all me, as you well know) would
doubt your good intentions here, I think that it comes off as
macho and insensitive to the issues needing discussion.  I'm sorry
if you have found all the foregoing work to be tiresome.  Maybe
the words "routing protocol" have too much baggage and history
within the IETF, and we need some other terminology to denote
the kind of cooperative network procedures needed for ad hoc.
Or maybe someone ought to express the ground rules for IETF participation
to make it clear whether manet qualifies.  If only complicated,
universally secure, fully managed network protocols can qualify,
maybe IETF is just plain the wrong place.  It would be nice to know.

Regards,
Charlie P.

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Apr 2003 10:17:40 -0700

At 09:42 AM 4/14/2003 -0700, Charles E. Perkins wrote:
>This is true, and is largely a result of the desire to avoid disseminating 
>host routes into larger routing domains.

The issue I am raising is in the following vein. In a manet network, for 
example, a truck (which has an internal wired LAN with some number of 
computers and a router connecting it to the manet) might drive into a yard 
and jack into the local network, becoming both a mobile and a fixed node. I 
think this is what you call a "hybrid" network; I find the concept a little 
tortured, as to me *every* network contains a mixture of local network 
types varying from serial lines to LANs to wireless LANs - every network is 
a hybrid. Calling this special case a "hybrid" and requiring it to use 
special protocols seems a bit daft, to be honest. But I digress.

Now, by military rules, the truck is supposed to have an address assigned 
by its unit, so what it probably does is generate a local address in the 
fixed network using DHCP and then advertise reachability to its mobile 
prefix. Hence, the mobile prefix is now floating in both IGPs. If the 
*intended* router between the IGPs now leaks the prefix back in either 
direction, problems can develop.

What said router wants to do is advertise a general prefix for the manet 
network into the base network that can be over-ridden using a longest-match 
rule, and only leak the route back if it is not being advertised within the 
manet network, or provide some form of hierarchy such as OSPF's prefix LSA 
and AS-external Summary LSA do. OSPF in the wired network addresses the 
issue; I don't see anything in the manet protocols to address it, leaving 
the issue to configuration and cleverness in the interface router.

Of course, if we could just say that the wired world and the wireless world 
were different areas in the same IGP's network (using IS-IS or OSPF 
language, but I'm not limiting my thinking to those protocols), the problem 
would sort itself out instantly.

Hence, I find myself wanting to use a single protocol in both the wireless 
and wired worlds. I want to treat the manet zone as part of the whole 
network, not a separate network that somehow gets tangled and untangled 
with the other one.

>On the other hand, it is my belief that advances in protocol design that 
>result from work on ad hoc networks _should_ be considered for use with 
>other protocols (e.g., OSPF).  Is it

To be discussed. I certainly don't have a problem with learning from the 
manet experience.

>I get that the military is able to live within the realm of applicability 
>defined by the security properties of the protocols they are trying to use.

Maybe, and Joe would know better. I would suspect that they are working 
around the issues in the protocols as opposed to accepting the issues.

>I'm sorry if you have found all the foregoing work to be tiresome.

I have not, and that's not what I said. What I said is that the periodic 
messages that say "pick me, because my protocol is better on some specific 
test" are tiresome.

And as to finishing the job, in the end someone has to actually run 
networks that use the protocols. Writing the spec is the fun and 
interesting part, but (as someone once said) the job isn't don't until the 
paperwork, the drudge part, is done. My point is that making the protocol 
work operationally is important too, and we need to get on with that.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 14 Apr 2003 11:46:54 -0700

Hello Fred,

Thanks for your note.  It puts your previous message in
a different light for me.

Fred Baker wrote:

           ........ example of truck associating with a fixed network
                    with fixed addressing rules ...

> direction, problems can develop.

Here's what I would suggest:

- Run manet on the truck
- Advertise fixed prefix to manet nodes
- Run manet router as an Internet gateway
- Allow truck manet nodes to run Mobile IP
  using the advertised prefix for allocating
  a care-of address
- Allow the manet nodes and the nodes in the
  fixed network to run route optimization.

If the manet nodes have an IP address which
is "never" topologically correct, then indeed
the manet router has to disseminate topology
information into the fixed network.  Otherwise,
the home agent for the topologically correct
network for a manet node's IP address has to
know about the care-of address.   Of course,
running route optimization amounts to disseminating
host routes to correspondent nodes in the fixed
network.

Some of these things seem to be definitional
consequences of having a fixed IP address to
be accessible from "the Internet".  I don't
see how the mobile network can avoid
the need to describe the topology to the
fixed network unless that topology is already
described implicitly by Internet hierarchical
routing.

> work operationally is important too, and we need to get on with that.

Check, double-check, and triple-check, except that
writing the spec isn't so much fun after about the first
dozen Internet Drafts of it.

Regards,
Charlie P.

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 14 Apr 2003 12:05:02 -0700

Hi Fred,

Fred Baker wrote:
> Hence, I find myself wanting to use a single protocol in both the 
> wireless and wired worlds. I want to treat the manet zone as part of the 
> whole network, not a separate network that somehow gets tangled and 
> untangled with the other one.

It seems then that you would favor a solution that provides the greatest
efficiency/scalability/etc in both worlds?

> messages that say "pick me, because my protocol is better on some 
> specific test" are tiresome.

Where are you seeing such messages? The messages I have seen recently
seem to be in a spirit of mutual collaboration toward a common goal,
and in keeping with the new wg charter. Have I missed something?

Thanks,

Fred
[email-masked]

---

From: [email-masked]
Date: Mon, 14 Apr 2003 13:28:48 -0700

> messages that say "pick me, because my protocol is better on some specific 

I haven't see much of that lately.  The purpose of the recent messages
between me and Thomas Clausen was to try to decide which candidate
techniques/features should be included in the final proactive routing 
protocol. (It may be early for that, but that is not the point.) 
These techniques can come from OLSR, TBRPF, OSPF, and other 
protocols. For example, I pointed out that the use of RIDs in OSPF
HELLO packets prevents it from supporting directional antennas,
which I think is an imortant point. (Maybe this is the "specific test"
you are talking about? If so, maybe you could comment on it.)  
For the most part, we are talking about modularity and efficiency in 
typical mobile ad hoc networks, and not about "specific tests".  
I think that OLSR does some things better than TBRPF, and TBRPF does 
some things better than OLSR.  In the latter case, it might look like 
I am saying "pick TBRPF", but I would not be objective or honest if 
I always said "pick OLSR or OSPF".  

> and in keeping with the new wg charter. Have I missed something?

Thanks, Fred.  You have not missed anything.  But I can see how someone
can get the wrong impression if they read the messages too quickly.

Regards,
Richard

---

From: Fred Baker <[email-masked]>
Date: Mon, 14 Apr 2003 13:40:06 -0700

>   using the advertised prefix for allocating

yes, one could use mobile IP in this special case. I'm looking at this as a 
general *routing* problem, not a special case scenario that can be worked 
around with special case addressing. My point stands that if the problem is 
handled generally, one need not do anything special - redistributing routes 
between protocols or using Mobile IP or anything else - in this special 
case. I'm looking for a deployable and operative solution that treats the 
entire network as a network, not as separate networks with some partially 
defined relationship to each other.

---

From: Joe Macker <[email-masked]>
Date: Mon, 14 Apr 2003 16:55:08 -0400

At 10:17 AM 4/14/2003 -0700, Fred Baker wrote:
>>This is true, and is largely a result of the desire to avoid disseminating host routes into larger routing domains.

Just chiming in with a few comments..

Honestly, we had discussed some of this in the past meetings and earlier on in the WG we focused on stub network application goal for manet, which simplifies a number of interconnection management issues. For initial application, I (and perhaps others) used managed prefixes for these areas. There are large variety of applications here but they are largely limited edge network applications with some topological relevance. I don't know about others, but I have deployed some experimental protocols in useful scenarios and they work. Lots more work to do and discussions to have of course.

I, for one, at least supported and would continue to support IETF discussions of  OSPF+ manet extensions (especially based off of OSPFv3) because I felt there were some less dynamic network backbone application areas that could benefit from the synergy of ideas (wireless interface handling, efficiency, convergence improvements)... and some of us (I am including a larger community than just manet WG) have done work in both experimenting with and deploying wireless OSPF variants already.  The main starting idea is some additional "nuts and bolts" MAY go a long way to having a more appropriate protocol for dynamic, wireless applications, especially in a more managed, backbone network scenarios.  I still don't think it would be right for all applications and is not a catch-all replacement for other manet related work.

I, for one, never saw this as a "one size fits all" situation, but see the benefits in both areas of work.

>The issue I am raising is in the following vein. In a manet network, for example, a truck (which has an internal wired LAN with some number of computers and a router connecting it to the manet) might drive into a yard and jack into the local network, becoming both a mobile and a fixed node. I think this is what you call a "hybrid" network; I find the concept a little tortured, as to me *every* network contains a mixture of local network types varying from serial lines to LANs to wireless LANs - every network is a hybrid. Calling this special case a "hybrid" and requiring it to use special protocols seems a bit daft, to be honest. But I digress.

I must have missed that hybrid thread.. Normal internetworking is multiple, heterogeneous interfacing.

<START DIGRESSION>
Hybrid, as a term, has been used in many different ways in the manet community and within related literature,etc. Sometimes it means a mix of reactive/proactive.  Sometimes..something else.. 

I have also been using it to describe "hybrid manet routing grids" where a portion of the manet routers are more static, pseudo-managed nodes (not much motion but the normal wireless dynamics occurring...these nodes are perhaps pre-placed strategically in a factory, etc)...and another set of nodes are transient through this "access grid" extending the routing infrastructure IF NEEDED.  In this scenario, typically only a few hops are needed before Internet backbone access is achieved.  The assumption here is Internet connection is the high preference requirement and nodes prefer routing through the "access grid nodes".

Ergot, the richness and abuse of the term hybrid.
<END DIGRESSION/FOR NOW>

>Hence, I find myself wanting to use a single protocol in both the wireless and wired worlds. I want to treat the manet zone as part of the whole network, not a separate network that somehow gets tangled and untangled with the other one.

The single protocol is IP ;-)  

I think multiple interface support is important..We may also wish to manage different routing solutions in different spaces when warranted. Most "interconnected" manet routing deployments should be topologically relevant at some level.

>>On the other hand, it is my belief that advances in protocol design that result from work on ad hoc networks _should_ be considered for use with other protocols (e.g., OSPF).  Is it
>To be discussed. I certainly don't have a problem with learning from the manet experience.

I think we pointed out a few potential "lessons learned"...interface behavior, neighbor discovery, link state scaling mechanism.. that might be borrowed or shared already.... Fred you helped with pointing those out  as well as anyone else.  There is a good opportunity for being synergistic here with engineering ideas.

>I have not, and that's not what I said. What I said is that the periodic messages that say "pick me, because my protocol is better on some specific test" are tiresome.

Despite being weary myself ... I am encouraged by recent strong commitments to a more cooperative engineering approach. Suggest we move forward with that mantra.

>And as to finishing the job, in the end someone has to actually run networks that use the protocols. Writing the spec is the fun and interesting part, but (as someone once said) the job isn't don't until the paperwork, the drudge part, is done. My point is that making the protocol work operationally is important too, and we need to get on with that.  

Agreed..
Let's not forget there are different operational problem spaces...

---

From: "Tao Lin" <[email-masked]>
Date: Mon, 14 Apr 2003 17:09:59 -0400

Hi, Fred,

Basically, I think the "general routing problem" mentioned in your emails
can be considered as an inter-operation issue between MANET and normal
network routing protocols.

As an alternative approach, we can incorporate a common solution to current
MANET protocols such as OLSR and TBRPF by introducing a gateway approach
(Gateway machines are nodes that connect directly to nodes in both MANET and
normal networks).  Gateway machines can broadcast information of associated
normal networks into MANETs when they discover a normal network.  These
gateway machines can also declare network-lost when their connections to
normal networks are lost.

It *might* be slightly different for reactive protocols.  In reactive
protocols, the gateway nodes may proactively broadcast new discovered
networks into MANETs, otherwise, MANET nodes may not be awared when a new
normal network is connected or lost.

Just my personal opinion.

Thanks

 Tao Lin
 Ph.D. Candidate
 ECE Dept.
 Virginia Tech.
 USA

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 14 Apr 2003 23:52:49 +0200

Hi Tao,

On Mon, 14 Apr 2003 17:09:59 -0400
"Tao Lin" <[email-masked]> wrote:

> Hi, Fred,
> 
> Basically, I think the "general routing problem" mentioned in your
> emails can be considered as an inter-operation issue between MANET
> and normal network routing protocols.
> 
> As an alternative approach, we can incorporate a common solution to
> current MANET protocols such as OLSR and TBRPF by introducing a
> gateway approach(Gateway machines are nodes that connect directly
> to nodes in both MANET and normal networks).  Gateway machines can
> broadcast information of associated normal networks into MANETs
> when they discover a normal network.  These gateway machines can
> also declare network-lost when their connections to normal networks
> are lost.

Such solutions for this exists OLSR (and, I think, in TBRPF aswell -
Richard, supplement here?) already. Working roughly as you sketch
above, even :) 

> 
> It *might* be slightly different for reactive protocols.  In
> reactive protocols, the gateway nodes may proactively broadcast new
> discovered networks into MANETs, otherwise, MANET nodes may not be
> awared when a new normal network is connected or lost.

I believe that Ryuji Waikikawa et. al. published an internet draft on
global connectivity, outlining how this can be done for reactive
protocols. The spec is IPv6-centric, but this should not make much
difference:

http://www.ietf.org/internet-drafts/draft-wakikawa-manet-globalv6-02.txt

These solutions, indeed, deal with a MANET as stub network with a
managed/dedicated prefix which, as Fred point out in another posting,
is a specific solution to a specific case which may or may not apply
in all situations. However this is different situation from having
the MANET be "just another area" in the larger routing
infrastructure.

--thomas

---

From: [email-masked]
Date: Mon, 14 Apr 2003 15:55:52 -0700

> defined relationship to each other. 

Some of the MANET routing protocols allow a node to have multiple interfaces,
some of which can be wired (e.g., Ethernet).  The TBRPF draft specifically
mentions Ethernet as a possibility.  Thus, a *single* network can include 
MANET links, wired broadcast links (Ethernet), and point-to-point links.

Multiple routers attached to the same Ethernet all advertise their links
to the other attached routers, i.e., we do not elect a designated router
as in OSPF, so there is room for improvement.  But such "hybrid" networks
are supported (or can be supported with slight modifications) by some
of the MANET routing protocols.

OLSR and TBRPF also advertise network prefixes (whether internal or external) 
and associated hosts. 

Tao, Your latest message deals with gateways between *separate* networks.
I think Fred is talking about a single network that does not need gateways
to connect its MANET units.

Regards,
Richard

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 14 Apr 2003 16:33:41 -0700

FYI, there is an interesting document entitled:

   "Multi-link Subnet Support in IPv6"
   http://www.ietf.org/internet-drafts/draft-ietf-ipv6-multilink-subnets-00.txt

that speaks to nodes with multiple links connecting to a single network.

Fred
[email-masked]

P.S. The above document is a somewhat controversial wg item of the
      IPv6 wg; this message should be seen as informational-only and
      not an endorsement.

---

From: Yasuhiro Ohara <[email-masked]>
Date: Tue, 15 Apr 2003 12:24:18 +0900 (JST)

Hi, I wanted to have some comments as an OSPF-centric researcher.
# May need to change subject ...

> is - in both the manet and the non-manet zone of a network reduces a lot of 

I felt that this is another issue, and should be discussed separately.

I know leaking/redistributing routes is highly policy dependent and so
complicated issue, and can create operational issues/problems.
But even with respect to IGP-EGP redistributing, there's no standard
except for the de facto one. The de facto one was developed with many
tries and errors *after* the protocol had been specified, isn't it ?

MANET wg should concentrate on specifying protocols efficient for
the communication within "Ad-hoc network", at least first.
I feel that the redistributing issue is the main subject of NEMO wg ...

> Of course, it would do better in many other scenarios.

I personally think that OSPF is not appropriate for the MANET use.

OSPF based on the segment concept has the prerequisite:
"If A can talk with B and A can talk with C, B can talk with C"
which is not applicable to MANET. (What was the name of the problem,
"line-of-sight problem" ?) Nor OSPF supports directional links.

> use effectively for aggregation.  On the other hand, there

Regarding to aggregation, all OSPF does is (generally) to use subnets
as the destination of the packet, rather than host-routes.
Area boundary may aggregate routes, but it's hard (requires pre-defined
address range for the area). It seems that segment/subnet concept
is hard to apply to the MANET environment, so I guess OSPF have no
advantage about aggregation.

> special protocols seems a bit daft, to be honest. But I digress.

I definitely agree the sentence "Every network is a hybrid", but it's
regarding to layer-2 technology.

I think it's better to separate MANET area and the rest Internet, as done
in IGP-EGP separation. No one desires that MANET frequency of topology
changes affects the IGP routing domain.

The word "hybrid" should be interpreted as "Hybrid of area separation"
(wrong english ?) rather than "Hybrid of wired/wireless network",
isn't it ?

> direction, problems can develop.

Again route leaking is separate issues ...

> would sort itself out instantly.

I agree.

> network, not a separate network that somehow gets tangled and untangled 

I disagree here. Regardless of wired or not, the MANET area should be
separated from the static network. Current IGP routing protocol (i.e.
OSPF or IS-IS, namely most link-state protocol) is very sensitive about the
topology changes at any single point within the domain.

If you assume using some kind of area separation of current IGP,
that is separated, in essence. Whether to use a new routing protocol
or not in that separate area is another issue, and MANET wg should
not specify (force) that, just like IGP choice is left to administrators.

> defined relationship to each other. 

I understand "if problem handled generally one need not do anything
special" and feel the same way: simple is the best, conditions should
be kept minimum.

But separating areas don't break simplicity, or may even gain
the simplicity.

I feel that this will be my fault saying this, not knowing how MANET
is working in real network (and if so I sincerely apologize),
but it seems that showing how MANET is working in real network
is what all Fred wants. If it's obvious that MANET will work in real,
then we will know some sort of management strategy and security issues.

I guess the reason why OSPF is deployed and trusted today, is because
J. Moy showed the example of working OSPF system in some
corporate (some kind of big, important) networks.

If I'm missing the point of this discussion, or if I said something
completely wrong, forgive me as it is whim of youth ;p)

regards,
yasu

---

From: Yasuhiro Ohara <[email-masked]>
Date: Tue, 15 Apr 2003 13:05:31 +0900 (JST)

> tries and errors *after* the protocol had been specified, isn't it ?

I found a lie in my message. "There's no standard except for the
de facto one" was a bit wrong, it is specified by RFC 1403
with respect to the interaction between BGP and OSPF .

My point was route redistribution is another issue and specifying it
can be deferred until after some deployments of MANET ...

regards,
yasu

---

From: David Young <[email-masked]>
Date: Mon, 14 Apr 2003 23:53:26 -0500

On Tue, Apr 15, 2003 at 12:24:18PM +0900, Yasuhiro Ohara wrote:
> "line-of-sight problem" ?)

  In the point-to-multipoint mode, OSPF does not make that assumption.

> Nor OSPF supports directional links.

  There is a variant of OSPF supporting directional links called Radio
  OSPF or RSPF (???) which amateur radio operators use for their packet
  radio networks.

Dave

-- 
David Young             OJC Technologies
[email-masked]      Urbana, IL * (217) 278-3933
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Yasuhiro Ohara <[email-masked]>
Date: Tue, 15 Apr 2003 15:34:45 +0900 (JST)

>   In the point-to-multipoint mode, OSPF does not make that assumption.

Right, and my mistake is that I didn't re-read Fred's slide ...

>   OSPF or RSPF (???) which amateur radio operators use for their packet

Interesting, I'll check it. thanks.

regards,
yasu

---

From: [email-masked]
Date: Tue, 15 Apr 2003 10:40:58 -0700

I will make some brief points now (since I am busy with other things)
but I want to think more about this issue later.

> But separating areas don't break simplicity, or may even gain

Separating a "hybrid" network into areas can make things more complex
if those areas have to be dynamically redefined due to mobility.
Also, separating the network into areas can result in suboptimal paths.

The main reason for areas in OSPF is for scalability.
As I said yesterday, some of the MANET routing protocols already
support "hybrid" networks with multiple wireless and wired interfaces.
So I don't think it is *necessary* to separate a hybrid network into 
areas (or domains or autonomous systems), although in some cases it 
may be desirable to do so.
For very large networks, scalability can be achieved using 
area routing or landmark routing.

There are some issues regarding how MANET routing protocols should
support a single hybrid network:
Should each node be aware of how non-local interfaces fit into the
topology?  In OLSR and TBRPF, each node maintains a logical
topology of the network represented by point-to-point links, which 
contains no knowledge about the *types* of links (wired, wireless,
point-to-point, Ethernet, etc.) that are represented by the 
logical point-to-point links.  (Of course, each node knows which
types of *local* interfaces it has, and which neighbors can be
reached thru each local interface.)  Unlike OLSR and TBRPF, OSPF 
distinguishes between different types of interfaces/links in LSAs,
and the LSAs describe how these interfaces fit into the topology,
and also assign a metric to each interface.  
So one question is: Should we do the same?

Richard