Subject: [manet] Dymo route discovery

From: "Romain Thouvenin" <[email-masked]>
Date: Fri, 20 Apr 2007 11:38:35 +0200

Hello,

I just wanted to be sure about a point of the DYMO specs. Section 5.4
says that a RREQ is created when it does not have a forwarding route.
Section 5.5 says also that a RRER must be issued when a data packet
for which no next hop is known is received. So in that case, a RRER
AND a RREQ are issued, is that right ?

Thanks,
Romain

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Apr 2007 12:16:29 +0200

Romain Thouvenin wrote:
>  says that a RREQ is created when it does not have a forwarding
> route. Section 5.5 says also that a RRER must be issued when a data
> packet for which no next hop is known is received. So in that case, a
> RRER AND a RREQ are issued, is that right ?

It sounds very odd to happen so, IMHO.

I always thought RRER and RREQ are to be used alternatively, not
simultaneously.

Probably the text should describe a situation whereby a router:
-check whether there's route for the dst of the received packet.
-if no then queue the packet
             and send RREQ
             and wait 10min
  else forward the packet.
-if after 10min
    there's route in routing table
          then forward the packet
    there's no route in routing table
          then issue RRER to src
               and drop the packet

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Romain Thouvenin" <[email-masked]>
Date: Fri, 20 Apr 2007 12:40:22 +0200

>     there's no route in routing table

Sounds interesting, but I'm not sure it is a good idea to make routers
queue packets in memory constrained contexts. Maybe that should be
administratively configurable.

Anyway, that's not how I understood the specs. 5.5 does not say
whether the RERR is sent immediately or after RREQ failure, and 5.4
does say that an error message should be sent after the failure, but
an ICMP message, not a RERR. That implies that the transport protocol
is IP, which is not the case for me.

Romain

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Apr 2007 13:46:39 +0200

Romain Thouvenin wrote:
>>> I just wanted to be sure about a point of the DYMO specs. Section
>>>  5.4 says that a RREQ is created when it does not have a 
>>> forwarding route. Section 5.5 says also that a RRER must be 
>>> issued when a data packet for which no next hop is known is 
>>> received. So in that case, a RRER AND a RREQ are issued, is that 
>>> right ?
>> 
>> -if no then queue the packet and send RREQ and wait 10min else 
>> forward the packet. -if after 10min there's route in routing table
>>  then forward the packet there's no route in routing table then 
>> issue RRER to src and drop the packet
>> 
>> Alex
> 
> Sounds interesting, but I'm not sure it is a good idea to make 
> routers queue packets in memory constrained contexts.

Ah, right, I agree.  Doesn't make sense to queue packets especially if
it's about streaming data.

> Maybe that should be administratively configurable.
> 
>  an ICMP message, not a RERR.

I much prefer if DYMO sends ICMP Destination Unreachable instead of RERR.

Because, if one wants DYMO to send RERR instead of ICMP then one must 
modify the IP stack code to disallow sending ICMP Destination 
Unreachable.  And that _only_ when DYMO runs on the machine.  This is 
too complex IMHO.

> That implies that the transport protocol is IP, which is not the case
> for me.

What is the transport protocol for you?

Alex

---

From: "Romain Thouvenin" <[email-masked]>
Date: Fri, 20 Apr 2007 14:15:37 +0200

> >>> received. So in that case, a RRER AND a RREQ are issued, is that
[...]
> >> issue RRER to src and drop the packet
[...]
> Unreachable.  And that _only_ when DYMO runs on the machine.  This is
Yes you're absolutely right. We are talking about a data packet, so
the transport protocol or its associated control protocol handles the
error.

> What is the transport protocol for you?

I'm implementing DYMO on TinyOS at the link-layer (no existing
net-layer). So DYMO messages are carried in AM packets, and I use my
implementation to provide a net-layer with AM as the transport packet
format. No control protocol for now.

Romain

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 20 Apr 2007 18:53:40 +0530

I guess I need to add an additional condition, as it is not clear in
the current document.

Here is the updated text in Section 5.4.

When a node originates a data packet and does not have a forwarding
route to the IP.DestinationAddress, it sends a RREQ (described in
Seciton 5.3.1) to discover a route to the particular destination
(TargetNode).

Is that more clear?

I've also updated Section 5.5 to say
"""
A RERR MUST be issued if a data packet is to be forwarded and it
cannot be delivered to the next hop because no forwarding route exists
"""

If you have any other issues, please keep them coming. These are good
suggestions.

Thanks.
Ian Chakeres

---

From: "Ian Chakeres" <[email-masked]>
Date: Fri, 20 Apr 2007 19:03:35 +0530

<snip>

> Unreachable.  And that _only_ when DYMO runs on the machine.  This is

RERR messages are disseminated in a controlled manner to remove routes
that are no longer available/accurate. An generic ICMP Destination
Unreachable message would not be capable of performing this operation.

Can you please talk more as to why you think RERR messaging or
processing is too complex? Or how we might improve RERR operation?

Ian Chakeres

---

From: "Romain Thouvenin" <[email-masked]>
Date: Fri, 20 Apr 2007 16:11:39 +0200

> If you have any other issues, please keep them coming. These are good

So no RREQ during packet forwarding, and (of course) no RERR during
packet originating. Yes I agree.

---

From: "Romain Thouvenin" <[email-masked]>
Date: Fri, 20 Apr 2007 16:15:55 +0200

> processing is too complex? Or how we might improve RERR operation?

I think the point was not RERR processing, but using RERR instead of
ICMP, that is interfering with IP implementation.

With your clarifications, no problem anymore. Nodes always generate
RERR to update surrounding routing tables, and can also use ICMP to
let know the originating application that a problem occured.

Romain

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Apr 2007 16:20:15 +0200

Ian Chakeres wrote:
>> Because, if one wants DYMO to send RERR instead of ICMP then one
>> must modify the IP stack code to disallow sending ICMP Destination 
>> Unreachable.  And that _only_ when DYMO runs on the machine.  This
>> is too complex IMHO.
> 
> RERR messages are disseminated in a controlled manner to remove
> routes that are no longer available/accurate. An generic ICMP
> Destination Unreachable message would not be capable of performing
> this operation.

Would a generic ICMP Redirect achieve the same effect you look for? (add
a route that overcomes an existing route that is no longer accurate).

> processing is too complex? Or how we might improve RERR operation?

I meant it is complex to implement the logic whereby one forbids the
generation of ICMP Destination Unreachable.  Presumably, that's what you
want to do on a router: if it runs DYMO and sends RERR then it must not
send ICMP Destination Unreachable, right?

You find easy to forbid the generation of Dest Unreachable?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Apr 2007 16:58:25 +0200

Romain Thouvenin wrote:
>>>>> I just wanted to be sure about a point of the DYMO specs.
>>>>> Section 5.4 says that a RREQ is created when it does not have
>>>>> a forwarding route. Section 5.5 says also that a RRER must be
>>>>> received. So in that case, a RRER AND a RREQ are issued, is
>>>>> that right ?
>>>> 
> [...]
>>>> 
>>>>  -check whether there's route for the dst of the received
>>>> packet. -if no then queue the packet and send RREQ and wait
>>>> 10min else forward the packet. -if after 10min there's route in
>>>> routing table then forward the packet there's no route in
>>>> routing table then issue RRER to src and drop the packet
>>>> 
>>>> Alex
>>> 
> [...]
>>> 
>>> whether the RERR is sent immediately or after RREQ failure, and
>>> 5.4 does say that an error message should be sent after the
>>> failure, but an ICMP message, not a RERR.
>> 
>>> That implies that the transport protocol is IP, which is not the
>>> case for me.
>> 

Sorry, 'AM' stands for what?

Which link-layer is that?

Just for my clarification, thanks.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 20 Apr 2007 17:11:37 +0200

> Seciton 5.3.1) to discover a route to the particular destination 

YEs to me.

Can it say what it does about the packet to be forwarded until a RREP is 
received?  Drop, queue, buffer?  And for how long to wait?

> I've also updated Section 5.5 to say """ A RERR MUST be issued if a
> data packet is to be forwarded and it cannot be delivered to the next
> hop because no forwarding route exists """

Can you say something about whether ICMP Destination Unreachable is
issued or not in this case?

Thanks,

Alex

> Thanks. Ian Chakeres
>> 5.4 says that a RREQ is created when it does not have a forwarding
>> packet for which no next hop is known is received. So in that case,
>> a RRER AND a RREQ are issued, is that right ?
>> 
>> Thanks, Romain
>> 
>> 
>> _______________________________________________ manet mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/manet
>> 
> 
> 
> _______________________________________________ manet mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/manet
>

---

From: "Ian Chakeres" <[email-masked]>
Date: Sun, 22 Apr 2007 16:16:31 +0530

Comments inline.

> a route that overcomes an existing route that is no longer accurate).

ICMP redirect would not convey the same information as a RERR, nor
would it be distributed appropriately.

> send ICMP Destination Unreachable, right?

ICMP Destination Unreachable messages are for the sources of packets,
not the routers in between.

In the AODV/DYMO implementations I've seen, ICMP Destination
Unreachable messages are issued by the source if it cannot find a
route.

I believe this is the chosen proceedure to discourage a sources
application from believing that no route is available, since it is
likely that the route is only temporarily broken or unavailable and
will soon be repaired.

Ian

---

From: "Ian Chakeres" <[email-masked]>
Date: Sun, 22 Apr 2007 16:19:27 +0530

Comments inline.

> received?  Drop, queue, buffer?  And for how long to wait?

We recommend queue, but there are parameters regarding the queue and
how long to wait. Please see the ID.

> issued or not in this case?

I would recommend that an ICMP destination unreachable not issued, but
I would not require it. Please see my other email on this subject.

Ian Chakeres

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 22 Apr 2007 23:12:21 +0200

Ian Chakeres wrote:
>>>> Because, if one wants DYMO to send RERR instead of ICMP then 
>>>> one must modify the IP stack code to disallow sending ICMP 
>>>> Destination Unreachable.  And that _only_ when DYMO runs on the
>>>>  machine.  This is too complex IMHO.
>>> 
>>> Destination Unreachable message would not be capable of 
>>> performing this operation.
>> 
>> Would a generic ICMP Redirect achieve the same effect you look for?
>>  (add a route that overcomes an existing route that is no longer 
>> accurate).
> 

We somehow turn and turn.

Indeed RERR conveys information more similar to ICMP Dst Unreachable (it
contains the address that is unreachable).

>> I meant it is complex to implement the logic whereby one forbids 
>> the generation of ICMP Destination Unreachable.  Presumably, that's
>>  what you want to do on a router: if it runs DYMO and sends RERR 
>> then it must not send ICMP Destination Unreachable, right?
> 

Yes.   ICMP Redirect is for routers in between.

But, do you mean that RERR and ICMP Destination Unreachable can work
simultaneously ok?

> Unreachable messages are issued by the source if it cannot find a 

Well, I think that is wrong.  The Dst Unreachable is usually generated
by the last router in the path to the destination that has no route to
that destination (and not by the source).  The local source host will
not generate a Dst Unreachable because it is supposed to have at least a
default route.

> likely that the route is only temporarily broken or unavailable and 

I think better than that can be achieved by always offering a default
route to the host.

But here again we assume different models for the networks.  You assume
that the application is run on the router that does the route discovery
as well.  I assume the application is run on a host that has no routing
capabilities, and always has at least a default route.  I will send a
separate message about this, later.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Sun, 22 Apr 2007 23:16:44 +0200

Ian Chakeres wrote:
>>> I guess I need to add an additional condition, as it is not clear
>>> in the current document.
>>> 
>>> When a node originates a data packet and does not have a
>>> forwarding route to the IP.DestinationAddress, it sends a RREQ
>>> (described in Seciton 5.3.1) to discover a route to the
>>> particular destination (TargetNode).
>>> 
>>> Is that more clear?
>> 
>> YEs to me.
>> 
>> Can it say what it does about the packet to be forwarded until a
>> RREP is received?  Drop, queue, buffer?  And for how long to wait?
> 
>>> I've also updated Section 5.5 to say """ A RERR MUST be issued if
>>> a data packet is to be forwarded and it cannot be delivered to
>>> the next hop because no forwarding route exists """
>> 
> I would recommend that an ICMP destination unreachable not issued,
> but I would not require it. Please see my other email on this
> subject.

I think this sounds like a recommendation on the use of ICMP Destination
Unreachable.  This recommendation should be discussed in my oppinion.
Currently the draft only talks about a local Dst Unreachable delivered
to the application.  I think what you want is to make sure that no
router in a network running DYMO sends a ICMP Dst Unreachable, because
its information may be contradicting the information in RERR.

I think I understand you correctly.  Sorry if I misunderstand you.

Alex

---

From: "Thomas M. DuBuisson" <[email-masked]>
Date: Sun, 22 Apr 2007 23:26:52 -0400

Is there a library for PacketBB out there?

Thomas

-- 
"The philosophy behind your actions should never change, on the other
hand, the practicality of them is never constant." - Thomas Main
DuBuisson

---

From: "Charles E. Perkins" <[email-masked]>
Date: Sun, 22 Apr 2007 20:52:56 -0700

Hello Alex,

I am pretty sure RERR is better, because it can invalidate
many broken routes.  An ICMP message would pretty much
be restricted to invalidating only one.  The ICMP message
would have to be unicast to the source (and, actually, to the
particular application on the source).  The RERR message
is a hop-by-hop broadcast and can do a lot better.

Does this make sense?

> its information may be contradicting the information in RERR.
I am not sure when the ICMP data would contradict the RERR
message data -- except unless the RERR triggered a route repair
without disturbing the application.  Is that what you meant?

Regards,
Charlie P.

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 23 Apr 2007 09:35:35 +0530

Comments inline.

> contains the address that is unreachable).

Here is a short list of some of RERRs features.

The RERR is disseminated in a limited flood. RERR may contain the
addresses of many now unreachable devices. RERR can be generated
on-demand, instead of waiting for data traffic to flow. RERR contain
the sequence number related to the addresses for which a route is not
available.

> But, do you mean that RERR and ICMP Destination Unreachable can work

I don't see any reason why they couldn't work together, but as I
mention I wouldn't suggest it.

> not generate a Dst Unreachable because it is supposed to have at least a

The question here is about "having no route". In reactive protocols,
just be cause you don't have a route at this moment, does not mean you
can't find a route.

> separate message about this, later.

We do not assume that the application is run on the router. A MANET
router can/will perform route discovery on behalf of its attached
hosts.

Ian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Apr 2007 11:32:59 +0200

> is a hop-by-hop broadcast and can do a lot better.

Makes sense.  For IPv6, distributing RERR seems to happen in multicast 
mode, ie to a multicast address.

> without disturbing the application.  Is that what you meant?

I mean it is useless to have both ICMP Dst Unreachable and RERR do the 
same thing.  You seem to challenge the fact that their contents would be 
contradicting each other - probably they won't - but still, one wouldn't 
want both Dst Unreachable and RERR to be issued for deleting the same 
route, because for sure one will not find that particular route to delete.

In which case DYMO would assume that if RERR is implemented then 
DstUnreachable  shouldn't ever be sent, right?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Apr 2007 11:38:46 +0200

Ian Chakeres wrote:
>>>>>> Because, if one wants DYMO to send RERR instead of ICMP 
>>>>>> then one must modify the IP stack code to disallow sending 
>>>>>> ICMP Destination Unreachable.  And that _only_ when DYMO 
>>>>>> runs on the machine.  This is too complex IMHO.
>>>>> 
>>>>> RERR messages are disseminated in a controlled manner to 
>>>>> remove routes that are no longer available/accurate. An 
>>>>> generic ICMP Destination Unreachable message would not be 
>>>>> capable of performing this operation.
>>>> 
>>>> Would a generic ICMP Redirect achieve the same effect you look 
>>>> for? (add a route that overcomes an existing route that is no 
>>>> longer accurate).
>>> 
>>> ICMP redirect would not convey the same information as a RERR, 
>>> nor would it be distributed appropriately.
>> 
>> Indeed RERR conveys information more similar to ICMP Dst 
>> Unreachable (it contains the address that is unreachable).
> 
> on-demand, instead of waiting for data traffic to flow.

I always thought 'on-demand' means data traffic  flows demands
construction of a route :-)

> RERR contain the sequence number related to the addresses for which a
>  route is not available.

Ok, I'll have to check that.

>>>>> Can you please talk more as to why you think RERR messaging 
>>>>> or processing is too complex? Or how we might improve RERR 
>>>>> operation?
>>>> 
>>>> I meant it is complex to implement the logic whereby one 
>>>> forbids the generation of ICMP Destination Unreachable. 
>>>> Presumably, that's what you want to do on a router: if it runs 
>>>> DYMO and sends RERR then it must not send ICMP Destination 
>>>> Unreachable, right?
>>> 
>>> ICMP Destination Unreachable messages are for the sources of 
>>> packets, not the routers in between.
>> 
>> But, do you mean that RERR and ICMP Destination Unreachable can 
>> work simultaneously ok?
> 

So one has to _disable_ ICMP DstUnreachable generation code, right?
That's built-in into the stack.

>> Well, I think that is wrong.  The Dst Unreachable is usually 
>> generated by the last router in the path to the destination that 
>> has no route to that destination (and not by the source).  The 
>> local source host will not generate a Dst Unreachable because it is
>>  supposed to have at least a default route.
> 
>  just be cause you don't have a route at this moment, does not mean 
> you can't find a route.
> 
> 
>>> application from believing that no route is available, since it 
>>> is likely that the route is only temporarily broken or 
>>> unavailable and will soon be repaired.
>> 
>> I think better than that can be achieved by always offering a 
>> default route to the host.
>> 
>> But here again we assume different models for the networks.  You 
>> assume that the application is run on the router that does the 
>> route discovery as well.  I assume the application is run on a host
>>  that has no routing capabilities, and always has at least a
>> default route.  I will send a separate message about this, later.
> 

For my clarification, will a MANET router act as a default router for
its attached hosts?  Or will it try to provide host-based routes to
install in the host's routing table for every correspondent this host
talks to?  This is very important to the MANEMO analysis, thanks.

Alex

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 23 Apr 2007 15:52:46 +0530

Comments inline.

> construction of a route :-)

In reactive/on-demand routing protocols, nodes do no know the routes
to all other nodes beforehand. They have to find routes on demand.
Using this logic, it is difficult to determine absolutely whether a
node is reachable or unreachable.

> That's built-in into the stack.

This is an implementation issue. I myself cannot say how/when ICMP
destination unreachable messages are generated. Though as I mentioned
above, making the judgement that an ICMP dst unreachable should be
issued might be weird in networks running reactive routing protocols.

> talks to?  This is very important to the MANEMO analysis, thanks.

A MANET router will act like a router for its attached nodes. In a
simple scenario where we have a router with attached hosts, the hosts
can be configure the router as their default router.

Ian

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 23 Apr 2007 15:59:48 +0530

Comments inline.

> mode, ie to a multicast address.

In IPv4 & IPv6 RERR messages are sent to a link local multicast
address (LL MANET routers). Upon receipt of a RERR message a DYMO
router might generate another RERR message to inform its LL MANET
routers.

> route, because for sure one will not find that particular route to delete.

As far as I know, reception of an ICMP Dst Unreachable does not cause
any modification to the routing/forwarding table in nodes.

A RERR very clearly has an impact on the DYMO routing protocol and the
routing/forwarding tables maintained.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Apr 2007 13:53:55 +0200

Ian Chakeres wrote:
[...]
> destination unreachable messages are generated.

I can say when they're generated: when a packet travelling to a
destination hits a router having no route to that destination, and no
default route.  Any router will generate such an ICMP DstUnreachable. 
Do you agree?

> Though as I mentioned above, making the judgement that an ICMP dst
> unreachable should be issued might be weird in networks running
> reactive routing protocols.

I think we diverge here.  ICMP DestUnreachable is specified and 
implemented and most if not all routers do implement it.

But I agree it would be weird for a network using RERR messages to also 
issue ICMP DstUnreachable.

Should this be clarified in the DYMO draft?  Should the DYMO draft say 
that when DYMO is run then ICMP DstUnreachable should not be issued by 
any router in the MANET?  I think yes.

[...]
>> For my clarification, will a MANET router act as a default router
>> for its attached hosts?  Or will it try to provide host-based
>> routes to install in the host's routing table for every
>> correspondent this host talks to?  This is very important to the
>> MANEMO analysis, thanks.
> 

Ok, this is a common behaviour with NEMO moving networks, where LFNs 
(Local Fixed Nodes) often can auto-configure a default route to the 
Mobile Router, with stateless address auto-configuration.

Alex

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 24 Apr 2007 10:53:43 +0530

Comments inline.

> any router in the MANET?  I think yes.

I will add the following text to the dymo draft in the "route
maintenance" section. The paragraph is talking about issuing RERR when
data is to be forwarded and no forwarding route exists.

"""
In this case, an ICMP Destination Unreachable message SHOULD NOT be
generated, unless this router is responsible for the IP.Destination
and the IP.Destination is not reachable.
"""

Do you have any textual recommendations?