Subject: [manet] Re: MPRF

From: Eric Fleury <[email-masked]>
Date: Wed, 18 Feb 2004 01:25:00 +0100

Hello,

We  have some   comments on  the  MPRF draft   proposal that you  have
submitted  on the MANet mailing list.  We  do believe  that  MPRF is a
great initiative and that MPRF can be useful  for all ad hoc protocols
(of course for both proactive and  reactive routing protocols but also
for service  location,  multicast...). We are  currently using  such a
concept  of  MPRF in order to   design and  implement simple multicast
routing  protocol [DMZ].  Thus we   are really interested by having  a
strong MPRF proposal inside the MANet group.   As mentioned by Richard
Ogier, we also noticed that because MPRs are source oriented, they may
present a lack of robustness as opposed to independent MPRs.

Since we have several additional comments I will take your bullet list
point by point.

The first point that  we want to make  is that regarding IPv6,  we did
propose  a  draft  ana6 [ANA6]   in order   to  support   IPv6 ad  hoc
architecture. The aim of  this draft  was not  to propose yet  another
routing  protocol  nor  to   implement a   specific protocol but   its
fundamental aim was to  allow IPv6 ad  hoc  networks at the  IP level,
based on the MANET RFC 2501, ``a  MANet node principally consists of a
router, which  may be  physically attached to   multiple IP  hosts (or
IP-addressable  devices),  which has  potentially  *multiple* wireless
interfaces--each interface using a *different* wireless technology''.

In the eyes of your draft  it appears that our  ana6 proposal may help
the    implementation  and  the    specification  of  "flooding   like
techniques".

In ana6,  we introduce a new type  of IPv6  local-use unicast address:
namely *ad hoc-local addresses*.   The   validity of an  ad  hoc-local
address is limited to an ad hoc network.  We define  an ad hoc network
as a maximal  connected set  of ad  hoc  interfaces.   Note that  this
definition allows no controversy about ad  hoc networks boundaries, as
opposed to the tricky problem  of defining a  site frontier which will
probably be responsible for the deprecation of site-local addresses.

Ana6 also defines the notion of  connector. The connector is the basic
addressable object  in  the ad   hoc network. It  virtualizes  several
network  interfaces  (the interfaces involved in   the ad hoc network)
into as  ingle addressable object. A  connector is associated to a set
of IPv6 addresses (1 ad hoc local and 0+ global). Each interface bound
to a connector (or involved in the ad hoc network) uses and recognizes
the   IPv6 addresses associated to  the  connector. In consequence, it
becomes really  straight-forward    to perform  ad   hoc routing  over
multiple  interfaces/multiple physical networks as  an  ad hoc node is
addressed regardless the interface it   is joined by. Another  feature
provided   by  connectors is  that    it becomes  possible to  perform
interface mobility/switching  (vertical handoff) without any change in
the IP addresses  used as the same ad  hoc addresses are recognized by
all ad hoc interfaces.

Within such architecture, it becomes more easier to :

 > - Works in networks that contain nodes that are not  MPRF-aware

A node  should be by  default a  MPR  and thus perform  a  "classical"
flooding.  Intelligent MPRF selection  will be there  only to thin the
number of MPRs and thus to perform more efficient. Doing pure flooding
as a default MPRF mode is easy in ana6.

 > - Fits well within IP, allowing forwarding for TTL>1
 >   without requiring application processing

Ana6 defines IPv6  ad hoc multicast addresses  and an ad hoc multicast
scope. Within  such a scope, only  adhoc nodes receive  multicast data
and   the routing is  performed strictly  at  the IP level without any
"application" consideration.   We  aim  at  offering full  classic  IP
services and  the notion of  multi-link  subnet is used  and allows to
share a unique  (or several  in an advanced   use) IP subnet  map over
severals links. This means that  there  is no addressing changes  from
one  link  to  another,  all of them  being  in  the  same IP  subnet.
However,  since the packet  crosses  several links during its journey,
the routing is still performed at the IP layer.

 > - Allows layer-2 broadcast (instead of iterated
 >   unicast tunneling) when possible

The  introduction  of an  ad  hoc  multicast   scope by  ana6  enables
multicast at level 3. It is not necessary any more  to perform level 2
broadcast  as the ad hoc  network is seen and  handled as a multi-link
subnet.

 > - Works for all upper layer protocols without
 >   requiring IP to make decisions based on the
 >   payload.

As  mentioned  above, the introduction of  ad  hoc multicast addresses
does not  impact  on upper layers  and  applications can still  use of
course global IPv6 addresses if the ad hoc network is connected to the
Internet.

 > 2.4 : Unique Identifier Destination Option

I think that  in IPv6 all  ad hoc multicast packets  must  have an UID
implemented as an  IPv6 option as you  mentioned  in your draft.  Many
IPv6 multicast packets (e.g.,  Router Advertisements) are  similar and
it is necessary to add such an option as we can not decide wether such
a packet has already  been received or wether it  is a new but similar
one.

Guillaume Chelius & Eric Fleury
INRIA - ARES

PS: Note that for IPv4, we also proposed in the past a level 2.5 
approach that offers all IP functionalities described in ana6 (one IP 
address for all ad hoc interfaces, level 2 broadcast, TTL> 1... ) but 
unfortunately not at the IP level which appeared to be not really 
*political correct* inside the MANet group (-;

[DMZ]  G.  CHELIUS, E. FLEURY,  AND  F. VALLOIS, Adaptive and robust
adhoc  multicast  structure, in 14th  IEEE  International Symposium on
Personal, Indoor and Mobile Radio Communication (PIMRC 2003), Beijing,
China, September 2003, IEEE.

[ANA6] G. CHELIUS AND E.  FLEURY, Ipv6 addressing architecture support
for  ad  hoc,  Internet  Draft  draftchelius- adhoc-ipv6-archi-00.txt,
Internet Engineering Task Force, August 2002.

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