Subject: [manet] Comments on DYMO

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Jun 2007 15:09:57 +0200

Hi, some of these comments were raised previously I believe.

DYMO is in draft-ietf-manet-dymo-09.txt

> Most DYMO messages are sent with the IP destination address set to 
> the link-local multicast address LL MANET ROUTERS unless otherwise 
> stated.  Unicast DYMO messages specified in this document are sent 
> with the IP destination set to the Route.NextHopAddress of the route 
> to the TargetNode.

RREQs are specified to be sent to a LL multicast address, but nodes
are not required to join that group - they should, and probably better 
with MLD and IGMP.

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

Apparently the application must run on the router that initiates the
RREQ.  Ie it is not possible to have an LFN behind an MR because MR
doesn't know when to send the RREQ.  With NEMO moving networks the LFN
(Local Fixed Node) is a vanilla stack host not doing any mobility nor
much dynamic routing.

Another question that comes to mind is how does a DYMO router discover
its neighbor routers?  Apparently DYMO doesn't specify anything for
this.  I think ND rfc2461 should be used for that purpose.

> The IP TTL (IP Hop Limit) field for DYMO messages is set to one (1) 
> for all messages specified in this document.

1?  Then the DYMO messages are discarded when crossing another router?
Or is the entire MANET a single subnet?

> IP.DestinationAddress The IP address of the packet destination.  For
> RREQ the IP.DestinationAddress is set to LL MANET ROUTERS.  For RREP
> the IP.DestinationAddress is set to the NextHopAddress toward the 
> TargetNode.

So all MANET routers must join the LL MANET routers address - is this
specified?

> MsgHdr.HopCnt The number of hops this message has traversed.

Why is there a need of this field when the Hop Limit in the IP header
does the same thing?

> AddBlk.TargetNode.Address The IP address of the message TargetNode.
> In a RREQ the TargetNode is the destination for which a forwarding
> route does not exist and route discovery is being performed.  In a
> RREP the target node is the RREQ OrigNode.  The TargetNode address is
> the first address in the routing message.

Why is the TargetNode address necessary in the RREP when the IP dst
field contains the same thing?

> AddBlk.OrigNode.Address The IP address of the OrigNode.  This address
> is in an address block and not in the message header to allow for
> address compression and additional AddTLVs.  This address is the
> second address in the message for RREQ.

Why is this here when the src field has it too?

> The Intermediate Node SHOULD also issue a gratuitous RREP to the RREQ
>  TargetNode, so that the RREQ TargetNode receives routing information
>  on how to reach the RREQ OrigNode.

But a gratuitous message is sent without receiving any message (no RREQ
received), so how does the intermediate node know the RREQ TargetNode?

> Before processing a RM, a node checks the IP.Destination to ensure 
> that it is a link-local packet.

Only 'link-local'?  We know (by this spec) that the dst address can be
a ll multicast address or a unicast address.  If the unicast address
can only have a ll scope (fe80) then the entire MANET can only be a
single subnet?

> 5.7.  Advertising Network Addresses
> 
> Any node can advertise a network address by using a PREFIX_LENGTH TLV
>  [I-D.ietf-manet-packetbb].  Any nodes (other than the advertising 
> node) within the advertised prefix SHOULD NOT participate in the DYMO
>  protocol directly and these nodes MUST be reachable by forwarding 
> packets to the node advertising connectivity.  Nodes other than the 
> advertising node that do participate in DYMO must forward the DYMO 
> control packets to the advertising node.  For example, A.B.C.1 with a
>  prefix length of 24 indicates all nodes with the matching A.B.C.X
> are reachable through the node with address A.B.C.1.

Ok, but does MANET Router send Router Advertisements?

> 8.  Security Considerations
> 
> Currently, DYMO does not specify any special security measures. 
> Routing protocols, however, are prime targets for impersonation 
> attacks.  In networks where the node membership is not known, it is 
> difficult to determine the occurrence of impersonation attacks, and 
> security prevention techniques are difficult at best.  However, when 
> the network membership is known and there is a danger of such attacks

What is 'node membership'?

> While DYMO does not place restrictions on the authentication 
> mechanism used for this purpose, IPsec Authentication Message (AH) is
>  an appropriate choice for cases where the nodes share an appropriate
>  security association that enables the use of AH.

How about recommending IPsec ESP too?

> If the mobile nodes in the ad hoc network have pre-established 
> security associations, the purposes for which the security 
> associations are created should include that of authorizing the 
> processing of DYMO control packets.  Given this understanding, the 
> mobile nodes should be able to use the same authentication mechanisms
>  based on their IP addresses as they would have used otherwise.

And if the mobile nodes in the ad hoc network _don't_ have
pre-established security associations?

This case is very important for MANEMO types of deployments where NEMO 
moving networks come and go.

Alex

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

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

---

From: "Ian Chakeres" <[email-masked]>
Date: Sat, 2 Jun 2007 15:45:13 +0530

Comments inline.

> are not required to join that group - they should, and probably better

I will put that DYMO routers should subscribe to the LL multicast
group. I'm a little unclear about MLD/IGMP comment, since there is no
need to inform anyone about LL subscriptions.

> (Local Fixed Node) is a vanilla stack host not doing any mobility nor

A DYMO router can be responsible for prefixes of attached hosts. In
this case the router manages the sequence number space for the sources
in the prefixes. I thought this concept was captured in Section 5.7
that you mention below. Perhaps it should be made more explicit. Would
you suggest I expand that section or flush it out more in the text
directly?

> this.  I think ND rfc2461 should be used for that purpose.

DYMO "discovers" other neighboring routers by the reception of RM. An
alternative and more robust mechanism like NHDP could and probably
should be used in most deployments.

> Or is the entire MANET a single subnet?

All packets are LL, there are no packets that are forwarded over multiple hops.

> Why is there a need of this field when the Hop Limit in the IP header

Messages are not forwarded by native IP forwarding. They are received,
processed, and then resulting LL messages might be sent.  The
MsgHdr.HopLimit controls dissemination via this mechanism.

> field contains the same thing?

In a RREP the IP destination does not contain the same thing. The IP
destination is the next hop router's address toward the RREP target.

> Ok, but does MANET Router send Router Advertisements?

Router advertisements are not DYMO routing protocol messages. Router
advertisements are generally for nodes attached to routers, not router
to router routing protocol communication.

> What is 'node membership'?

A priori knowledge of the different routers that a particular router
will communicate with in the future.

> How about recommending IPsec ESP too?

This is an option, but generally authentication is the most important component.

> pre-established security associations?

I believe this falls in the research arena.

---

From: "Ian Chakeres" <[email-masked]>
Date: Sat, 2 Jun 2007 17:24:22 +0530

Alexandru,

I now understand your query about sources having to be DYMO routers. I
have updated the text in relation to this issue. The text in the next
revision will make it clear that the source's DYMO router is
responsible for initiating route discovery on its behalf.

Ian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 14:07:02 +0200

> responsible for initiating route discovery on its behalf.

Hi Ian, what does the text look like?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 14:34:11 +0200

Ian Chakeres wrote:
>>> Most DYMO messages are sent with the IP destination address set 
>>> to the link-local multicast address LL MANET ROUTERS unless 
>>> otherwise stated.  Unicast DYMO messages specified in this 
>>> document are sent with the IP destination set to the 
>>> Route.NextHopAddress of the route to the TargetNode.
>> 
>>  are not required to join that group - they should, and probably 
>> better with MLD and IGMP.
> 

I'm not sure why you say there is no need to inform anyone about LL
subscriptions?  I think only the routers that subscribed to that group
should receive the DYMO Routing Message.  This is achieved by sending a
message saying it's interested in that group.  Then the DYMO RMs are
sent only to the routers interested in, bandwidth is saved.

>>> When a node originates a data packet and does not have a 
>>> forwarding route to the IP.DestinationAddress, it sends a RREQ 
>>> (described in Section 5.3.1) to discover a route to the 
>>> particular destination (TargetNode).
>> 
>> Apparently the application must run on the router that initiates 
>> the RREQ.  Ie it is not possible to have an LFN behind an MR 
>> because MR doesn't know when to send the RREQ.  With NEMO moving 
>> networks the LFN (Local Fixed Node) is a vanilla stack host not 
>> doing any mobility nor much dynamic routing.
> 
> A DYMO router can be responsible for prefixes of attached hosts.

In a MANEMO topology the Mobile Router (presumably the DYMO router) is
routing not only for hosts directly attached to it but also for all
other hosts in the NEMO moving network (presumably separated from it by
Fixed Routers).  The prefixes of the directly attached hosts and of the
hosts attached on FR can be completely different (not aggregated).

So a DYMO router, if it wants to send RREQ to other DYMO routers it
should  do so for all hosts directly or indirectly (through FR) attached
to it, ie hosts in the NEMO moving network.

The DYMO sourter, if it wants to send RREP when requested by other DYMO
routers, should send RREP containing not only the prefix of its directly
attached hosts but also the prefixes of hosts that can be attached on
the Fixed Router.

> In this case the router manages the sequence number space for the 
> sources in the prefixes. I thought this concept was captured in 
> Section 5.7 that you mention below. Perhaps it should be made more 
> explicit. Would you suggest I expand that section or flush it out 
> more in the text directly?

Sorry, I don't yet have a full understanding of DYMO sequence numbers.
I'll have to see this.

>> Another question that comes to mind is how does a DYMO router 
>> discover its neighbor routers?  Apparently DYMO doesn't specify 
>> anything for this.  I think ND rfc2461 should be used for that 
>> purpose.
> 
> DYMO "discovers" other neighboring routers by the reception of RM.

Wouldn't it be more flexible if discovering was allowed too by the
reception of periodic unsolicited advertisements?  Like hosts discover
routers by either receiving unsolicitied advertisements or
'pro-actively' requesting one?

I think yes IMHO.

> An alternative and more robust mechanism like NHDP could and probably

There are more ND deployments than NHDP thus ND would be better I believe.

>>> The IP TTL (IP Hop Limit) field for DYMO messages is set to one 
>>> (1) for all messages specified in this document.
>> 
>> 1?  Then the DYMO messages are discarded when crossing another 
>> router? Or is the entire MANET a single subnet?
> 

Does this mean that all DYMO routers in a DYMO MANET network are
connected to a single subnet?  I'm tempted to think so... could you
please clarify?

>> Why is there a need of this field when the Hop Limit in the IP 
>> header does the same thing?
> 
> Messages are not forwarded by native IP forwarding. They are 
> received, processed, and then resulting LL messages might be sent. 
> The MsgHdr.HopLimit controls dissemination via this mechanism.

I really am not sure what you mean...

In a sense you seem to say that the whole MANET network is one subnet
(no packets forwarded over multiple hops) and in another sense you say
there are HopLimit variables...

I'll have to read it.

>>> AddBlk.TargetNode.Address The IP address of the message 
>>> TargetNode. In a RREQ the TargetNode is the destination for which
>>>  a forwarding route does not exist and route discovery is being 
>>> performed.  In a RREP the target node is the RREQ OrigNode.  The 
>>> TargetNode address is the first address in the routing message.
>> 
I don't understand... but I'll have to read more.

>>> Any node can advertise a network address by using a PREFIX_LENGTH
>>>  TLV [I-D.ietf-manet-packetbb].  Any nodes (other than the 
>>> advertising node) within the advertised prefix SHOULD NOT 
>>> participate in the DYMO protocol directly and these nodes MUST be
>>>  reachable by forwarding packets to the node advertising 
>>> connectivity.  Nodes other than the advertising node that do 
>>> participate in DYMO must forward the DYMO control packets to the 
>>> advertising node.  For example, A.B.C.1 with a prefix length of 
>>> 24 indicates all nodes with the matching A.B.C.X are reachable 
>>> through the node with address A.B.C.1.
>> 
>  advertisements are generally for nodes attached to routers, not 
> router to router routing protocol communication.

Generally yes, I agree.

However, in a MANEMO context, the Mobile Router acts a bit as a host on
its egress interface and configures a default route and a CoA based on
the RA received from another router.

If a DYMO router doesn't send RAs then a MANEMO MR can't configure a
default route from it.

The DYMO spec doesn't seem to care about default routes.  Probably there
is a reason for that, good to use in a DYMO MANET network.

But in a MANEMO or NEMO moving network there _are_ default routes and
they are needed.

I think I tend to disgress this dicussion towards the MANEMO needs, and
away from MANET protocol design for DYMO requirements.  I think my
interest is mainly in MANEMO context.

>>> mechanism used for this purpose, IPsec Authentication Message 
>>> (AH) is an appropriate choice for cases where the nodes share an 
>>> appropriate security association that enables the use of AH.
>> 

I agree.

>>> processing of DYMO control packets.  Given this understanding, 
>>> the mobile nodes should be able to use the same authentication 
>>> mechanisms based on their IP addresses as they would have used 
>>> otherwise.
>> 

Well, depends.  Using certificates (instead of pre-established security
associations) and/or IKE is spec'ed in RFCs Standards Tracks I believe.
  MIP6 Return Routability messages are also RFC Std Track.  These two I
can think of quickly as not using pre-established SAs.

Alex

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 4 Jun 2007 18:21:44 +0530

"""When a source's DYMO router needs to forward a data packet and it
does not have a ..."""

I've also updated other places, where the source's router needs to
perform operations on behalf of nodes in its prefix(es).

Ian

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 4 Jun 2007 18:40:02 +0530

Comments inline.

> sent only to the routers interested in, bandwidth is saved.

Especially in MANET, nodes may not know if people are interested all
the time. They should send them anyway.

I think it also depends on IPv4/IPv6 about the issuance of IGMP
messages related to LL multicast groups.

I will add text to state that DYMO routers should subscribe to LL MANET routers.

> attached hosts but also the prefixes of hosts that can be attached on

This sounds fine.

> 'pro-actively' requesting one?

DYMO does not disallow this behavior, but it does not mandate it either.

> There are more ND deployments than NHDP thus ND would be better I believe.

ND does not handle asymmetric reachability. Also it cannot be combined
with other MANET messaging.

This is not to say, that ND could not be useful in addition to other mechanisms.

> connected to a single subnet?  I'm tempted to think so... could you

Subnet is a poorly defined term. Please see the MANET arch document
about addressing.

I will say that if one DYMO router sends a LL multicast, it does not
expect to reach all other DYMO routers in a MANET. I will say that all
DYMO routers in a MANET are expected to be within one IP hop of
another DYMO router.

> there are HopLimit variables...

No packets are forwarded over multiple hops. Instead the appropriate
information is placed in a new packet. In this way information is
propagated over multiple hops.

> If a DYMO router doesn't send RAs then a MANEMO MR can't configure a

A (DYMO) router could easily send RAs on its classic IP interfaces
(see manetarch - figure 1 i think - nodes behind the router).

> can think of quickly as not using pre-established SAs.

I agree certs could be used. My point was that something needs to be
pre-established (not necessarily SAs).

Ian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 15:39:56 +0200

> """When a source's DYMO router needs to forward a data packet and it

And what if it has a default route?

Alex

>> better
>> forwarding
>> discover
>> (1)
>> (AH) is

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 15:50:53 +0200

Ian Chakeres wrote:
>>>>> Most DYMO messages are sent with the IP destination address 
>>>>> set to the link-local multicast address LL MANET ROUTERS 
>>>>> unless otherwise stated.  Unicast DYMO messages specified in 
>>>>> this document are sent with the IP destination set to the 
>>>> RREQs are specified to be sent to a LL multicast address, but 
>>>> nodes are not required to join that group - they should, and 
>>>> probably better with MLD and IGMP.
>>> 
>>>  group. I'm a little unclear about MLD/IGMP comment, since there 
>>> is no need to inform anyone about LL subscriptions.
>> 
>>  subscriptions?  I think only the routers that subscribed to that 
>> group should receive the DYMO Routing Message.  This is achieved by
>>  sending a message saying it's interested in that group.  Then the 
>> DYMO RMs are sent only to the routers interested in, bandwidth is 
>> saved.
> 
>>>>> forwarding route to the IP.DestinationAddress, it sends a 
>>>>> RREQ (described in Section 5.3.1) to discover a route to the
>>>> Apparently the application must run on the router that 
>>>> initiates the RREQ.  Ie it is not possible to have an LFN 
>>>> behind an MR because MR doesn't know when to send the RREQ. 
>>>> With NEMO moving networks the LFN (Local Fixed Node) is a 
>>>> vanilla stack host not doing any mobility nor much dynamic 
>>>> routing.
>>> 
>> In a MANEMO topology the Mobile Router (presumably the DYMO router)
>>  is routing not only for hosts directly attached to it but also for
>>  all other hosts in the NEMO moving network (presumably separated 
>> from it by Fixed Routers).  The prefixes of the directly attached 
>> hosts and of the hosts attached on FR can be completely different 
>> (not aggregated).
>> 
>>  should  do so for all hosts directly or indirectly (through FR) 
>> attached to it, ie hosts in the NEMO moving network.
>> 
>> The DYMO sourter, if it wants to send RREP when requested by other 
>> DYMO routers, should send RREP containing not only the prefix of 
>> its directly attached hosts but also the prefixes of hosts that can
>>  be attached on the Fixed Router.
> 
> This sounds fine.
> 
>>>  Section 5.7 that you mention below. Perhaps it should be made 
>>> more explicit. Would you suggest I expand that section or flush 
>>> it out more in the text directly?
>> 
>> Sorry, I don't yet have a full understanding of DYMO sequence 
>> numbers. I'll have to see this.
>> 
>>  reception of periodic unsolicited advertisements?  Like hosts 
>> discover routers by either receiving unsolicitied advertisements or
>>> An alternative and more robust mechanism like NHDP could and 
>>> probably should be used in most deployments.
>> 
> ND does not handle asymmetric reachability.

Right...

UDLR and some TCP flavors do.

> Also it cannot be combined with other MANET messaging.
> 
>>>>> The IP TTL (IP Hop Limit) field for DYMO messages is set to 
>>>>> one (1) for all messages specified in this document.
>>>> 
>  expect to reach all other DYMO routers in a MANET.

It should expect to reach all the DYMO routers who subscribed that group.

> I will say that all DYMO routers in a MANET are expected to be within
> one IP hop of another DYMO router.

Looks not as routing then :-)  This is one link, and link-layer 
'routing', no?

>>> received, processed, and then resulting LL messages might be 
>>> sent. The MsgHdr.HopLimit controls dissemination via this 
>>> mechanism.
>> 
>> In a sense you seem to say that the whole MANET network is one 
>> subnet (no packets forwarded over multiple hops) and in another 
>> sense you say there are HopLimit variables...
> 

But you said previously that all DYMO routers are within one hop...

Sorry... it may be me who doesn't follow all the protocol description. 
I will stop here asking.  I realize much work went into this protocol 
design.

>> Well, depends.  Using certificates (instead of pre-established 
>> security associations) and/or IKE is spec'ed in RFCs Standards 
>> Tracks I believe. MIP6 Return Routability messages are also RFC Std
>>  Track.  These two I can think of quickly as not using 
>> pre-established SAs.
> 

I agree, usually it's the case... just to say that if IKE (and D-H like 
mechanisms), _or_ certificates and PKI exists, _or_ return routability 
tests, then nothing is pre-established... and it's not research...

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 4 Jun 2007 16:26:03 +0100

> It should expect to reach all the DYMO routers who subscribed that
group.

No. Because the LL multicast is only going one hop, and some
(usually most) other routers are more than one hop away.

> Looks not as routing then :-)  This is one link, and link-layer 

No. Each DYMO router is within one hop of another (at least one
other) DYMO router, but not of all other DYMO routers. And then
you do network layer routing, which is what DYMO is there for.

> But you said previously that all DYMO routers are within one hop...

See previous comment.

Incidentally in these regards, OLSRv2 is the same as DYMO.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 18:00:04 +0200

> (usually most) other routers are more than one hop away.

Ok.

> you do network layer routing, which is what DYMO is there for.

Ok.

So this fits Ian's previous explanation where the DYMO's RREQ/RREP IP 
messages are not 'forwarded' but received, processed and other IP 
RREQ/RREP constructed and sent.

In these messages two variables are used: HopLimit and HopCnt.

The base IPv6 header and the IPv4 header have a field called HopLimit 
and TTL respectively.  These fields are used extensively to limit 
forwarding of packets and keep count of it.

DYMO calling HopLimit exactly as Hop Limit in IPv6 base header is a 
source of confusion to me.

DYMO not specifying what to put in the src address of the base header 
when constructing new messages is confusing to me.

I agree with DYMO to use what it sees fit in its messages, especially 
when it has been experimented in practice.

However, that doesn't necessarily make DYMO appropriate for a MANEMO 
configuration and topology.

MANEMO configuration and topologies don't necessarily need the HopLimit 
field in the UDP payload - it could use the Hop Limit field in the base 
header.  Also, it does not need to 'relay' or 'proxy' messages, it could 
forward them if need were; such that no need to change neither src nor 
dst address of base header.

MANEMO is the main reason why I post remarks on DYMO.  I would invite 
MANET readers to read MANEMO documents and remark on those too.

> Incidentally in these regards, OLSRv2 is the same as DYMO.

Thanks for this clarification with respect to OLSRv2 and DYMO behaviour 
in this respect.  That means that OLSRv2 too 'relays' the messages 
constructing new src and dst addresses in the base header at each hop, 
right?

Alex

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 4 Jun 2007 22:00:18 +0530

If a default route exists in the forwarding table, and the router were
not configured to do anything special based on the information in the
packet (e.g. src/dst, etc), the packet could be forwarded without
performing route discovery.

Ian

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 4 Jun 2007 17:36:46 +0100

> dst address of base header.

This is missing that if we have nodes A - B - C with a hop between them,
a DYMO message sent by A is received and processed by B, and then
forwarded by B, before reaching C. Just sending it at A with an IP hop
limit of 2 will not suffice, the two single hops are necessary. This
isn't specific to DYMO, it occurs in OLSR and many other ad hoc routing
protocols. I venture to suggest you'll find it necessary too
(particularly
when you consider the need for bidirectional routes). Note that this is
for signalling, data is another matter, there we do use a hop limit of
(at least) 2.

---

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

Comments inline.

> source of confusion to me.

They have the same purpose and therefore the same name. Their use is
clearly called out differently in the spec as IP TTL/HopLimit and
MsgHdr.HopLimit.

> when constructing new messages is confusing to me.

There may need to be some textual changes, related to the "Source's
DYMO router" as I explained before. I think the idea is now cleared up
though.

> MANET readers to read MANEMO documents and remark on those too.

Alexandru, I am very glad to see your comments about DYMO and enjoy
making the DYMO spec better. I also hope that we can also make
progress in the MANEMO area, as I think this will require a lot of
knowledge from both groups.

Ian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 18:50:35 +0200

Dearlove, Christopher (UK) wrote:
>> MANEMO configuration and topologies don't necessarily need the 
>> HopLimit field in the UDP payload - it could use the Hop Limit 
>> field in the base header.  Also, it does not need to 'relay' or 
>> 'proxy' messages, it could forward them if need were; such that no 
>> need to change neither src nor dst address of base header.
> 
> This is missing that if we have nodes A - B - C with a hop between 
> them, a DYMO message sent by A is received and processed by B, and 
> then forwarded by B, before reaching C. Just sending it at A with an
> IP hop limit of 2 will not suffice, the two single hops are
> necessary.

I think that if the message is really forwarded by B and that if there
are two different subnets, one on A-B the other on B-C then it is
sufficient to use hoplimit 2 in base header.  This assumes that A-B and 
B-C are different subnets with different prefixes.

I think that if you consider that A-B-C are in a situation of hidden
terminal problem (A can send to B but not to C, B can send to both A and
C) then this hidden terminal problem can be solved by a range extender
or other bridging mechanism acting at MAC layer, such that all three A,
B and C are in the same subnet.  An IP packet sent by A will be bridged
by B and IP-received by C.  The hop limit in base header should be 1.

> This isn't specific to DYMO, it occurs in OLSR and many other ad hoc 
> routing protocols. I venture to suggest you'll find it necessary too 
> (particularly when you consider the need for bidirectional routes). 
> Note that this is for signalling, data is another matter, there we do
>  use a hop limit of (at least) 2.

Christopher, thanks for the clarification.  I understand the situation
may occur with OLSR and other ad-hoc routing protocols.

Could you please suggest what do you think about using a bridge range
extender acting at MAC layer, or a repeater repeating all it hears on
one interface to the other interface - as a potential solution running
on B, thus avoiding the hidden terminal problem?

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 4 Jun 2007 18:01:38 +0100

> B-C are different subnets with different prefixes.

I think you aren't picking up on the architecture. A, B and C can be
any three nodes in the same MANET, just with A and C outside radio
range (or otherwise blocked from communicating). Subnets are a red
herring here.

> by B and IP-received by C.  The hop limit in base header should be 1.

That would be a layer 2 routing protocol. You can build layer 2 routing
protocols. Many people have - and the jury is still out on which will
win in which marketplaces. But here we are building layer 3 routing
protocols (though many of the ideas could - and have been - be reused in
a layer 2 routing protocol). RFC 2501 is the IETF specific document
here,
although it's a bit long in the tooth now.

It's very easy in a layer 3+ centric organisation to say "make it a
layer 2
problem". But you are going to get many of the same problems in both
cases.
Of course each also has its advantages and disadvantages as well.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 20:38:45 +0200

Dearlove, Christopher (UK) wrote:
>>> This is missing that if we have nodes A - B - C with a hop 
>>> between them, a DYMO message sent by A is received and processed 
>>> by B, and then forwarded by B, before reaching C. Just sending it
>>> at A with an IP hop limit of 2 will not suffice, the two single
>>> hops are necessary.
> 
>> I think that if the message is really forwarded by B and that if 
>> there are two different subnets, one on A-B the other on B-C then 
>> it is sufficient to use hoplimit 2 in base header.  This assumes 
>> that A-B and B-C are different subnets with different prefixes.
> 

I agree that A-B and B-C two different subnets is one possibility, and
you pointing this is not the right architecture makes me think you think
of the second case below.

>> I think that if you consider that A-B-C are in a situation of 
>> hidden terminal problem (A can send to B but not to C, B can send 
>> to both A and C) then this hidden terminal problem can be solved by
>>  a range extender or other bridging mechanism acting at MAC layer, 
>> such that all three A, B and C are in the same subnet.  An IP 
>> packet sent by A will be bridged by B and IP-received by C.  The 
>> hop limit in base header should be 1.
> 
> That would be a layer 2 routing protocol. You can build layer 2 
> routing protocols.

I think I'm not proposing routing protocol, but yes, at layer 2.  I'm
writing about a dumb repeater, a range extender, making it just like an
Ethernet repeater: what it hears on left puts on right and vice-versa.

In the hidden terminal problem A-B-C, if C can't hear A it's because the
range is not enough, the physical distance is too long between A and C,
or the transmission power is limited by gov't/federal restrictions on
emit power in unlicensed spectrum.  The same problem appears with wired
Ethernet when the cable is too long, except it's not gov't regulatory;
and the solution is a repeater.

> Many people have - and the jury is still out on which will win in 
> which marketplaces.

I agree with this reflexion, but I didn't mean the routing part in
layer-2 protocol.  I meant repeating and bridging.

I think repeaters and bridges have their large shares in the wired
markeplaces and have been built at least by communities in search of
wifi Internet access over large areas.

> But here we are building layer 3 routing protocols (though many of 
> the ideas could - and have been - be reused in a layer 2 routing 
> protocol). RFC 2501 is the IETF specific document here, although it's
>  a bit long in the tooth now.
> 
> layer 2 problem". But you are going to get many of the same problems 
> in both cases. Of course each also has its advantages and 
> disadvantages as well.

I agree it were incorrectly easy to say just make it another layer's
problem -  only if it didn't have a solution :-)

But the hidden terminal problem does have solutions, in WiFi deployments
it's called range extenders and is deployed by some, as a repeater.

I don't understand what you mean by one is going to get many of the same
problems in both cases.  If layer-2 does the bridging then the hidden
terminal problem is solved I don't see where else can same problem arise.

Finally, still as my MANET perspective: if MANET protocols try to solve
this asymmetricity problem (we seem to agree it's the hidden terminal
problem) with a layer-3 routing protocol then I'm not against it.  Just
to say that does not mean that all WLAN deployments ressembling a MANET
(routers that move around) should solve the problems in the same way as
MANET protocols do.

Alex

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 4 Jun 2007 22:44:41 +0200

Please do not overload the term "hidden terminal".
I think it is misused. The term is borrowed from "hidden terminal problem"
and this has to do with CSMA/CA where carrier sensing has some problems. RTS
- CTS partly solves this problem, see MACA (D. Allen) and MACAW (V.
Bharghavan) for details.

Teco

> -----Original Message-----
> From: Alexandru Petrescu [mailto:[email-masked]]
> Sent: maandag 4 juni 2007 20:39
> To: Dearlove, Christopher (UK)
> Cc: manet; Alexandru Petrescu
> Subject: Re: [manet] Comments on DYMO
>

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 5 Jun 2007 09:49:00 +0100

> Ethernet repeater: what it hears on left puts on right and vice-versa.

That's not going to be sufficient - at least not without reducing to
blind flooding. And the whole point of just about all MANET work is
that yes, you can blind flood - but not if you want anything remotely
efficient.

You seem to think you can push the problem from layer 3 to layer 2,
and then magic it away at that level. You might consider that if this
were the case people might have spotted there were no problems long
ago - in fact before I ever heard the phrase "ad hoc network".

> In the hidden terminal problem A-B-C

As Teco Boot points out, this is not what is usually referred to
as the hidden node problem, which is not simply that A can't hear
C and you need multi-hop transmission (without which you don't
have a MANET) but that refers to a contention problem that occurs
because of this case.

> if C can't hear A it's because the
> emit power in unlicensed spectrum.

There are quite a few more possible reasons than that. Here's just one
- there's a physical obstacle between A and C.

> layer-2 protocol.  I meant repeating and bridging.

Which will not suffice to build an efficient MANET. The people
creating routing protocols at layer 2 have to do similar intelligent
stuff at layer 2.

> problem -  only if it didn't have a solution :-)

You really think you've just solved all the problems we've worked on
for several years in my case, and more years by many others than me,
with a simple layer 2 repeater?

> problem)

No. First I wouldn't use the hidden terminal terminology here. And
this isn't the asymmetry problem either. The asymmetry problem is
if A can hear B, but B can't hear A. That's a detail of the problem
though (but one of the reasons why some simpler solutions to the
multihop problem are insufficient).

> with a layer-3 routing protocol then I'm not against it.  Just

If you don't want blind flooding (and we don't) then you've
got to do something intelligent at layer 2, or layer 3, or
both, or combining the two, or something similar. Those are
all MANET protocols. They may or may not be the IETF MANET WG
protocols (though using them, their predecessors, or their
ideas, is common). The last time I looked (quite a few years
ago) I stopped counting at about 50 different MANET routing
protocols. I'm sure there are at least that many more again.
Of course they reuse ideas.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Jun 2007 12:18:13 +0200

Christopher, thanks for the message.

Just wanted to point out that although I disagree with you on many
points below, it is far from my intentions to neglect prior work on
MANET, MAC, layer-2 and 3 routing; or to do any inefficient blind flooding.

It's just that there are certainly MANET-like contexts where many of the
problems revealed by the most special MANET testbeds are not necessarily
quantifiable and addressable problems for some deployments.  I think of 
an IETF meeting packed with people doing Internet over WiFi, and I think
about what are the problems that were raised... or I think about 
vehicles in a large parking doing the same.

Alex

Dearlove, Christopher (UK) wrote:
>> I think I'm not proposing routing protocol, but yes, at layer 2. 
>> I'm writing about a dumb repeater, a range extender, making it just
>>  like
> an
>  that yes, you can blind flood - but not if you want anything
> remotely efficient.
> 
> As Teco Boot points out, this is not what is usually referred to as 
> the hidden node problem, which is not simply that A can't hear C and 
> you need multi-hop transmission (without which you don't have a 
> MANET) but that refers to a contention problem that occurs because of
>  this case.
> 
>> if C can't hear A it's because the range is not enough, the 
>> physical distance is too long between A and
> C,
>> or the transmission power is limited by gov't/federal restrictions 
>> on emit power in unlicensed spectrum.
> 
> There are quite a few more possible reasons than that. Here's just 
> one - there's a physical obstacle between A and C.
> 
>> I agree it were incorrectly easy to say just make it another 
>> layer's problem -  only if it didn't have a solution :-)
> 
>> this asymmetricity problem (we seem to agree it's the hidden 
>> terminal problem)
> 
> this isn't the asymmetry problem either. The asymmetry problem is if 
> A can hear B, but B can't hear A. That's a detail of the problem 
>> with a layer-3 routing protocol then I'm not against it.  Just to 
>> say that does not mean that all WLAN deployments ressembling a
> MANET
>> (routers that move around) should solve the problems in the same 
>> way
> as
>> MANET protocols do.
> 
> If you don't want blind flooding (and we don't) then you've got to do
>  something intelligent at layer 2, or layer 3, or both, or combining 
> the two, or something similar. Those are all MANET protocols. They 
> may or may not be the IETF MANET WG protocols (though using them, 
> their predecessors, or their ideas, is common). The last time I 
> looked (quite a few years ago) I stopped counting at about 50 
> different MANET routing protocols. I'm sure there are at least that 
> many more again. Of course they reuse ideas.
>