Subject: Re: Broadcast when AODV in multiple interfaces

From: Elizabeth Royer <[email-masked]>
Date: Thu, 7 Sep 2000 09:19:31 -0700 (PDT)

Hello Manel,

Attached you'll find a copy of the most recent AODV Draft.
Its got a few key differences from the one currently in the 
Internet Draft repository.  In particular, Section 8.12
discusses the use of interfaces with AODV, and Section 2
includes the addition of an Interface field in the route
table.  

Regards,
Elizabeth

~> When you broadcast a RREQ from a host with at least two interfaces
~> where AODV is 'playing': The 'Source IP Address' of the packet should
~> be the one corresponding to each interface (so packets that would go
~> out by different interfaces would differ in the 'Source IP Address'
~> field, and therefor the 'Dest Seq Num' should be also different?
~> Or should we just one of them (randomly chosen)?
~> Which are the implications of that?
~> 
~> I have the filling that AODV has been designed with
~> one_AODV_interface_per_host scenarios in mind. Althoug there is no
~> explicit restriction about that.
~> Do you have any impresions about what would change and if it would
~> be possible to use it in scenarios with more than one AODV interfaces
~> per host?
~> 
~> Dou you think that the use of AODV should be restricted to only one
~> interface-per-host?
~> Somehow, it looks to me that this could be something that affects,
~> not only to AODV, but to manet protocols in general.
~> 
~> BR/ManelG
~> 
~> 4. Route Request (RREQ) Message Format
~> 
~>     0                   1                   2                   3
~>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
~>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~>    |     Type      |J|R|G|       Reserved          |   Hop Count   |
~>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~>    |                         Broadcast ID                          |
~>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~>    |                    Destination IP Address                     |
~>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~>    |                  Destination Sequence Number                  |
~>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~>    |                       Source IP Address                       |
~>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~>    |                     Source Sequence Number                    |
~>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Fri, 08 Sep 2000 10:29:14 +0300

Hi everybody:

Thanks for the update, Elizabeth.

I would like to make sure that I got it all right.
Let's use a example:

There is a host with 3 interfaces in the v4 world ;)
if1: 10.0.1.1/24 (non-AODV (that means AODV is not activated here))
if2: 10.0.2.1/24 (AODV)
if3: 10.0.3.1/24 (AODV)

It finds that needs a route to 10.0.4.1. Therefore, it
broadcast a RREQ.

Ok, ok, slowmotion here: it _broadcast_ to the AODV interfaces,
isn't it?

>>> SHALL it send an IP packet like this:
IP dst: 255.255.255.255
RREQ Flags = 0
RREQ Hop count = 0
RREQ Broadcast ID = 'X'
RREQ dst = 10.0.4.1
RREQ dst seq num = 'Y'
RREQ src = 10.0.1.1
RREQ src seq num = 'Z'

That's what is what I understend is sugested in
'manet-aodv-06' and 'manet-bcast-00'.
I don't know. Then it would be sent also to 'if1' (that is
not an interface where AODV should 'play').
Besides the fact than:
Some BSD systems treat 255.255.255.255 as an alias for the
broadcast address of the first interface that was configured.
Some other systems might send it just to the interface where
the default route is.

>>> OR SHALL it send two IP packets like these:
IP dst: 10.0.2.255
RREQ Flags = 0
RREQ Hop count = 0
RREQ Broadcast ID = 'X1'
RREQ dst = 10.0.4.1
RREQ dst seq num = 'Y1'
RREQ src = 10.0.2.1
RREQ src seq num = 'Z1'

IP dst: 10.0.3.255
RREQ Flags = 0
RREQ Hop count = 0
RREQ Broadcast ID = 'X2'
RREQ dst = 10.0.4.1
RREQ dst seq num = 'Y2'
RREQ src = 10.0.3.1
RREQ src seq num = 'Z2'

(where X1 = X2, Y1 = Y2, Z1 = Z2)

Please, notice the different RREQ src address.
(Should they be the same one?)

(I'm not sure if me and Charles understood each other:
when I told about "'Source IP Address' of the packet"
I was refering to the RREQ packet, not to the IP packet).

I personally think that the second option (with the packets
as shown) is the right one. But It would not surprise me if
I would be completly wrong ;)

	Manel Guerrero

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Fri, 08 Sep 2000 13:57:45 +0300

> includes the addition of an Interface field in the route

Hi again :)

In Section 8.12, (second paragraph) it's said:
"When multiple interfaces are available, a node receiving
and rebroadcasting a RREQ message rebroadcasts that message
on all interfaces except the one on which it was received."
[...]

Well, those interfaces are not necesarily wired. Therefore
it is not true that all the hosts that can reach one of the
interfaces of one host can reach between them all.
Hum... this is getting tricky to say without a example:

('ifxx---ifyy' means than those two interfaces can hear each other)
('ifxx-Hy' means that the Host Hy has the network interface ifxx)

   if11---if21---if31---if41
    |      |      |      |
    H1     H2     H3     H4
           |
          if22

- There are 4 hosts: H1, H2, H3, H4
- H2 has 2 interfaces: if21, if22.
- H2 can hear H1 and H3 using if21, but cannot hear none of them
with if22.
- H1 interfaces cannot hear H3 interfaces, and viceversa.

- H1 needs a route to H4. Broadcasts a RREQ.
- H2 is the only node to hear it (by if21).
- H2 rebroadcast the RREQ message
"on all interfaces except the one on which it was received."
(that means if22).
- H3 does not receive the RREQ
- The RREQ is not discovered.

Is that right, or am I missing something?

Regards,

	Manel Guerrero

---

From: Manel Guerrero Zapata <[email-masked]>
Date: Mon, 11 Sep 2000 12:21:05 +0300

Hi again :)

I've been thinking this weekend about the whole thing.
And I would like to sumarise/specify/correct it,
so it's easer to you to make comments on them.

I think that the right think to do would be:

* Always broadcast and rebroadcast to all the AODV interfaces.
  Otherwise a RREQ could not reach the host that is looking for.
  (I've explained why in the previous email).

> if1: 10.0.1.1/24 (non-AODV (that means AODV is not activated here))

* Hello would be like this:
Two packets:

IP dst: 10.0.2.255
RREP Flags = 0
RREP Prefix size = 0
RREP Hop Count = 0
RREP dst = 10.0.2.1
RREP src = 10.0.2.1

IP dst: 10.0.3.255
RREP Flags = 0
RREP Prefix size = 0
RREP Hop Count = 0
RREP dst = 10.0.3.1
RREP src = 10.0.3.1

Because what we advertise with the hello is the interfaces.
And because is the only way to send it though if2 & if3 but not though
if1
Therefore we would have hellos broadcasting in all the AODV interfaces
and not in the non-AODV ones.

* Broadcast and rebroadcast of RREQ:

If a route to 10.0.4.1 is needed to send a packet
with IP src addres 10.0.2.1:
Two packets:

IP dst: 10.0.2.255
RREQ Broadcast ID = 'X1'
RREQ dst = 10.0.4.1
RREQ dst seq num = 'Y1'
RREQ src = 10.0.2.1
RREQ src seq num = 'Z1'

IP dst: 10.0.3.255
RREQ Broadcast ID = 'X2'
RREQ dst = 10.0.4.1
RREQ dst seq num = 'Y2'
RREQ src = 10.0.2.1	//And not 10.0.3.1 !!!
RREQ src seq num = 'Z2'

The use of the common 'RREQ src' for both packets
is needed to make this hack of the multiple interfaces
invisible to the system.
(That is a correction I'm making from one of my
previous mails).

Sending a single packet with IP dst:255.255.255.255
would send it also though if1.

So what we are doing is sending the same RREQ but
to the broadcast addresses of each AODV interface.
This packet has as RREQ dst the host we need a route to,
and the RREQ src is the interface though we are gonna
send the packet when we'll get the route.

* Broadcast and rebroadcast of RERR:

Two packets with the following IP dst:

IP dst: 10.0.2.255

IP dst: 10.0.3.255

And with the same RERR.

So pretty the same than with RREQ.

---

Regards,

	Manel Guerrero

---

From: Lusheng Ji <[email-masked]>
Date: Tue, 12 Sep 2000 08:36:24 -0400 (EDT)

Greetings!

While I was reading the new MAODV draft (draft-ietf-manet-maodv-00.txt), 
I was a little confused by the processing of GRPH message.  Could you
please help me understanding it.

In section 9.12, the third paragraph, the draft says: "... Otherwise, 
the node updates its group leader table to reflect the current multicast
group IP address/group leader IP address combination, and increments the
Hop Count value in the message.  If the node receiving the GRPH message is
a member of the multicast tree, it also updates this information in its
multicast route table." 
However, does this make the 'U' flag sort of useless since no matter if
there is any leader information change, a node needs to update its group
leader table and multicast route table (if on-tree) anyway.

Another question is about the 'M' flag of the GRPH message.  The draft
says (also section 9.12 3rd paragraph): "...If the M flag is unset, then
this node can also use the Hop Count value to verify its current distance
from the group leader."  Just wondering what is the actual meaning of
"verify".  If the current distance does not match with the Hop Count in
GRPH message, is the node required to do anything?  The same question
goes for the MACT message which is used to update the "distance to
group leader" information of all down stream tree nodes after repairing 
a broken link.  I guess a more general question of this type goes
like this: if a node sees that its "distance to group leader" is changed
to some value different from the current value, is it required to do
anything?

Thank you very much and have a nice day.

Lusheng