Subject: [manet] I-D ACTION:draft-ietf-manet-dymo-00.txt

From: [email-masked]
Date: Wed, 16 Feb 2005 10:24:05 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Dynamic MANET On-demand Routing Protocol (DYMO)
	Author(s)	: I. Chakeres, et al.
	Filename	: draft-ietf-manet-dymo-00.txt
	Pages		: 27
	Date		: 2005-2-15
	
The Dynamic MANET On-demand (DYMO) routing protocol is intended for
   use by mobile nodes in wireless multihop networks.  It offers quick
   adaptation to dynamic conditions, low processing and memory overhead,
   low network utilization, and determines unicast routes between nodes
   within the network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-dymo-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-manet-dymo-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-dymo-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Christophe Jelger <[email-masked]>
Date: Fri, 18 Feb 2005 11:57:50 +0100

Hi,

Just a quick mistake in part 2. Terminology we read :

IPBroadcastAddress
          Transmit the packet to the IP Limited Broadcast address,
          255.255.255.255 (IPv4) or FF:FF:FF:FF:FF:FF (IPv6).

Actually FF:FF:FF:FF:FF:FF is not an IPv6 address, and even 
FF:FF:FF:FF:FF:FF:FF:FF is not the IPv6 broadcast address (stricly there 
is no broadcast address with IPv6). Maybe you should use ff02::1 ?

Regards,
Christophe

[email-masked] wrote:
> ------------------------------------------------------------------------
>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Sat, 19 Feb 2005 14:31:28 +0900

Hi Christophe and Ian

We submitted a new draft regarding IPv6 support on MANET.
The flooding address is discussed in the draft.

http://www.ietf.org/internet-drafts/draft-wakikawa-manet-ipv6-support-00.txt

Any comments are appreciated.

thanks
ryuji

At Fri, 18 Feb 2005 11:57:50 +0100,

---

From: Christophe Jelger <[email-masked]>
Date: Mon, 21 Feb 2005 18:11:18 +0100

Hello Ryuji,

Before I trigger another hot topic of discussion (in a separate email), 
here are some comments about the draft. As a general comment, I think 
most of the draft gives a reasonable view of IPv6 networking in a MANET.

Some more detailed comments (sorry for the long email). I'm purposely a 
bit "nasty" sometimes, of course don't take it personnaly, my goal is 
just to trigger discussions.

About the "broadcast" address : shall we use ff02::1 or ff02::2, or even 
both ? I mean some messages could be sent to all nodes, and other 
messages can be sent to all_nodes_that_also_do_routing. This triggers 
the question : do we allow nodes in a MANET not to take part in the 
routing activity ? If yes, then using ff02::1 and ff02::2 would make 
sense because we could differentiate between nodes/routers from 
nodes/non_routers.

Section 2.2 : I think using unique local unicast addresses in a MANET 
makes a lot of sense since they (sort of) replace site-local addresses. 
However, the BIG problem is that such addresses are not automatically 
generated. I think that's really annoying, because if there is no 
special host to advertise such a prefix, the nodes of an autonomous 
MANET would not create such an address, and would then not be able to 
communicate since we don't route link-local addresses. Now if each MANET 
node was allowed to generate the Global ID and subnet ID fields (56 
bits, chosen via some random method), then all the nodes could at least 
have an address routeable in the MANET. Maybe a well-known 
MANET_Global_ID could even be used and reserved for MANETs. Each node 
could then compute its own Subnet_ID randomly. So ok all the nodes in 
the MANET would not use the same prefix, but is it really important ? 
(as you say in Section 3.1, a node can keep its unique local even when 
merges/partitions occur). Or do we want prefix continuity ? (as defined 
in my soon_updated draft ;-)

Section 3.2 : I would avoid talking about "foreign" network, as it does 
not have a clear meaning in a MANET (unless you relate it to MIP).

Section 4 : from previous discussions on the autoconf mailing list with 
C. Perkins and P. Engelstaad, I'm still not sure that such a strict 
statement is clear/right. As you explain in Section 7.1, top of page 9, 
a node should sometimes avoid using the tunnel when it uses its home 
address. I fully agree with that, but is this in agreement with RFC 3484 
? (which says use the home address, which for me means "use the tunnel" 
because home address is by essence topologically not correct, despite 
not written explicitely in RFC 3484). I think this is opened to 
interpretation, so maybe one should be very clear about that.

Section 6.1 : By IP flooding, do you mean some sort of multicast routing 
? (as broadcast/multicast is the same thing with IPv6). I mean, this 
forwarding entry would be setup dynamically (by some multicast routing 
protocol) or would it be a static "well-known" forwarding behavior ? If 
yes, then one must be careful about leaks : you don't want the flooding 
to "escape" from the MANET, but that means the gateway must be aware 
that some of its interfaces are not in the MANET, and as you say in 
Section 5.1 that "there is no mechanism to detect whether attached 
network is a MANET or a normal IPv6 network". Moreover, I would remove 
the statement that the all_manet_multicast address can also be defined 
for unique local scope, because these addresses have (strictly speaking) 
a global scope (but are not globally routeable).

Section 7.1 : as I said earlier, I agree that the tunnel should of 
course not be used to communicate with MANET nodes, but in the mean time 
the home address is somehow meaningless if the tunnel cannot be used. 
Especially if a unique local address can be used inside the MANET. So I 
would not defend the use of the home address when global connectivity is 
not available : use of some MANET-scope addresses is easier.

Hope you find these comments useful.

Regards,
Christophe

---

From: Christophe Jelger <[email-masked]>
Date: Mon, 21 Feb 2005 18:31:57 +0100

Ryuji/all,

Well I thought I would post the hot topic issue in a separate email for 
clarity. ;-)

--- Hot topic 1 :

I think most of the content of the draft makes sense, as soon as one 
agrees about the definition of a "link" in a MANET. It's clear that the 
MANET WG consensus is that a MANET is a multi-hop multi-link network, 
i.e. the link-layer is composed of multiple links. Well that's one 
definition which is fine and in full accordance with IETF activities 
which are targeted above layer 2.

But as Ryuji states in Section 2.1, can we see a MANET as a unique layer 
2 segment ? I know this is not the WG consensus, but it's a very viable 
assumption. In particular, usual IPv6 operations can be re-used without 
modifications since we emulate a broadcast link. Autoconf, neighbor 
discovery, DAD, everything can be used straightforward. An example is 
the LUNAR protocol (see http://core.it.uu.se/adhoc), which sits below IP 
and fools the IP layer by emulating the behavior of a LAN.

--- Hot topic 2 :

Now I also remember talking on the autoconf mailing list with some 
people about different things which lead us to the definition of a MANET 
... and I was particularly puzzled by statements such as : two 
inter-connected MANETs. Which leads to the immediate question : how do 
we define the boundaries of a MANET ? I think this issue should 
seriously be considered, especially if we want to do global address 
autoconfiguration with multiple gateways and prefixes.

Of course ;-) I still advocate the use of prefix continuity, as a mean 
to create logical sub-networks inside a MANET. I will hopefully update 
my draft this week.

Hope this will trigger some discussions on the autoconf list which is 
too quiet since Christmas break. ;-)

Best regards,
Christophe

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Feb 2005 12:48:03 -0800

Hello Christophe,

Here are some comments on your topics.

>and fools the IP layer by emulating the behavior of a LAN.
Surely it's possible, but then it seems to me that you are hiding
some multi-hop operations underneath layer 3.  For instance, you
used the word "fools".  I think this strategy goes along the path
towards restricting IP to run on top of things that resemble LANs.
So, perhaps the argument should be settled according to whatever
people think is the appropriate model for a network-layer protocol
that purports to route between links.

>   .......       how do 
Yes, I agree it needs serious consideration.  I wonder if it has to
be solved before we engineer an autoconfiguration protocol for
a single MANET.  I hope it doesn't, honestly.

>to create logical sub-networks inside a MANET. I will hopefully update 
Do you insist that a router advertising a prefix should offer
connectivity to every host addressable by way of that prefix?

Regards,
Charlie P.

---

From: Christophe Jelger <[email-masked]>
Date: Tue, 22 Feb 2005 09:41:56 +0100

Hello Charlie,

See my comments inline.

Regards
Christophe

> that purports to route between links.

Well you're right : such a solution hides the multihop nature of a MANET 
to IP. However, in many cases one may want a MANET to resemble a LAN ... 
and actually it is not so far from what is done in an infrastructure 
802.11 network : the physical topology is a star, nodes cannot 
communicate directly, but still IP "is fooled" and sees a 
"broadcast-like" LAN. It can happen that 2 nodes are radio isolated as 
they communicate via the access point : so it's a clear two-hops 
communication, but no IP routing is involved. I just think that the LAN 
analogy is very useful in many cases, it's a pity that it has not been 
considered more by the WG.

> a single MANET.  I hope it doesn't, honestly.

Probably we don't need to solve this before we have a first 
autoconfiguration protocol, but I think we should always keep this in 
mind so that if we want logical organizations in a MANET we can easily 
add such an extension.

> connectivity to every host addressable by way of that prefix?

I'm sorry I'm not sure I fully understand what you mean by that. Prefix 
continuity was just the idea that we can create contiguous (connected) 
logical sub-networks inside a MANET. Can you please clarify your point ?

As I said in a previous email, I will submit a updated version of my 
draft later this week : I removed some non-vital stuff, and try to have 
a short proposal.

> 
> Regards,
> Charlie P.
> 
> 
> MANET Autoconf mailing-list
> To unsubscribe: mailto:[email-masked]?subject=unsubscribe
> 
> 	
>

---

From: Guillaume Chelius <[email-masked]>
Date: Tue, 22 Feb 2005 10:23:53 +0100

Hi all,

> But as Ryuji states in Section 2.1, can we see a MANET as a unique 
> layer 2 segment ? I know this is not the WG consensus, but it's a very 
> viable assumption. In particular, usual IPv6 operations can be re-used 
> without modifications since we emulate a broadcast link. Autoconf, 
> neighbor discovery, DAD, everything can be used straightforward. An 
> example is the LUNAR protocol (see http://core.it.uu.se/adhoc), which 
> sits below IP and fools the IP layer by emulating the behavior of a 
> LAN.

This is also the philosophy of the Ananas 
(http://sourceforge.net/projects/ananas) protocol which emulates a 
broadcast medium on top of  a multiple-interface MANet. However, it is 
quite clear that implementing MANet at level 2 is not the WG 
philosophy.

> people about different things which lead us to the definition of a 
> MANET ... and I was particularly puzzled by statements such as : two 

Christophe, I agree with you on the fact that the definnition of a 
MANet boundary should be seriously considered. As you said in your 
previous mail, this issue is also bound to the flooding problem. When 
performing a flooding on the all-manet-multicast address, we do not 
want the packet to go to the Internet through Internet-connected 
gateway interfaces. We must have some way to differentiate interfaces 
connected to a MANet from interfaces that are not. This is one thing we 
proposed in an earlier draft: draft-chelius-adhoc-ipv6-00.txt

Best regards,
Guillaume Chelius.
----------------------------
ARES Project, INRIA
web: http://ares.insa-lyon.fr/~gchelius
mail: [email-masked]
phone: (+33) 472 436 182
fax: (+33) 472 436 227

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 24 Feb 2005 15:56:10 +0900

> proposed in an earlier draft: draft-chelius-adhoc-ipv6-00.txt

For isolated MANET, the boundary can be defined as a range where
flooded packet are reached in terms of hoplimit,etc.

For connected MANET with IGW, the boundary can be simple defined with
the address configuration mechanism. I.e. all the nodes assigned a
global address form a MANET.

I did not notice your draft, can you send me a copy?

regards,
ryuji

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 24 Feb 2005 15:50:22 +0900

Hello Christophe

At Mon, 21 Feb 2005 18:31:57 +0100,
> and fools the IP layer by emulating the behavior of a LAN.

I prefer the fist statement.

My initial concern was NDP operation in MANET, because NDP is very
tight to the link definition.
It's not reasonable to modify NDP a lot for manet. It causes the
interoperability issues between a manet node and a v6 node. 

As you said, with LUNAR (hide multihop link from IP), MANET is
transparent to NDP/IPv6 at all. (which is great advantage though..).

> autoconfiguration with multiple gateways and prefixes.

I agree on this. 

> to create logical sub-networks inside a MANET. I will hopefully update 

:-) did you submit an updated version?

> too quiet since Christmas break. ;-)

I finally recovered from holidays:-p

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 24 Feb 2005 15:40:12 +0900

Hello Christophe

Thanks for comments.

At Mon, 21 Feb 2005 18:11:18 +0100,
> just to trigger discussions.

don't mind;-)

> sense because we could differentiate between nodes/routers from 

I tried to inherit the v4 operation. In v4, routing protocols use
255.255.255.255 as a limited broadcast, it's simple to say using ff02::1.

I am not so positive to use ff02;:2 for flooding, 
because router in IPv6 sense and router in manet sense is slightly different.
If all manet "routers" satisfy IPv6 router requirements. It will be fine, but..
In addition, I want to keep ff02::2 for Internet Gateways (IPv6 router
+ manet interface).

The clean solution is to have a new limited broadcast address for all
manet nodes/routers, but overhead to get these address must be high.

> in my soon_updated draft ;-)

Good point. I agree with you here.
My first idea was a new well-known prefix for manet nodes.
However, IPv6 WG is not completed the ULP spec and I tried not to
bring the confusion.

If we say all the nodes in a MANET use the individual ULP address, we
should have a manet specific prefix range. Otherwise, it will bring
another problems to ULP operation in wired.

> not have a clear meaning in a MANET (unless you relate it to MIP).

OK.

> interpretation, so maybe one should be very clear about that.

Right. This is not specified yet.  

FYI. Pascal, Greg and I setup a mail-list to discuss the integration
of MANET and MIP/NEMO.  please check the announce mail sent to NEMO ML.

> a global scope (but are not globally routeable).

I did not discuss how to stop flooding here. I tried to explain how
flooding of each protocol (specified with IPv4) can be operated in IPv6.

For example, MPR flooding is an example.  MPR6 simply uses ff02::1
like it uses 255.255.255.255 in IPv4.  The prevention of flooded
packets leak should be solved by MPR and not by IPv6.

> the home address is somehow meaningless if the tunnel cannot be used. 

I believe it's meaningful:-)
The home address is assigned to a node (not interface). 
It can still use as an identifier of a node in a manet. 

Moreover, in an isolated manet, DNS is not expected.  The use of home
address is one answer to solve a destination address, if the home
address is well-known or cached.

In addition, if a communication is established between two home addresses, 
the communication can be kept active when one of node leaves the MANET.
Here is an example.

If two vehicles communicate by vehicle-vehicle MANET, one of node
starts speedup and leaves the MANET. Then the nodes switch to GPRS and
continue the communication. If the nodes use ULP address, this can not
be achieved.

> not available : use of some MANET-scope addresses is easier.

It depends on operations and services. 
And this is all about source address selection. 

> Hope you find these comments useful.

thanks!

regards,
ryuji

---

From: Guillaume Chelius <[email-masked]>
Date: Thu, 24 Feb 2005 15:35:52 +0100

Hi Ryuji,

Please see my remarks below.

> global address form a MANET.

The problem is that the Internet-connected interface of the gateway is 
also configured with a global address. So there is no way for the 
gateway to decide which of its interfaces are in a MANet and which are 
not.

> I did not notice your draft, can you send me a copy?

The draft is quite old and has expired. Please find it in attachment. 
An implementation of this draft is also available for FreeBSD at 
http://sourceforge.net/projects/anax (FreeAna6-routing and kernel). To 
summary, there were three main ideas in the draft:

1) to add an MANET_MODE  flag associated to each interface in order for 
a node to know which interfaces are or are not part of a MANet.

Using this flag we can define a MANet as a maximal connected set of 
MANet interfaces. There are no more problems of MANet boudaries.

2) creation of a a manet scope for unicast as well as multicast 
addresses. MANet interfaces are associated with MANET-local addresses 
and a MANET scope is used for multicast diffusion inside a MANet. 
Validity of  MANet-local (unicast and multicast) addresses is limited 
to the MANet. For example, a packet destinated to the ALL-MANET-NODES 
must not be forwarded through an interface which is not in MANET_MODE.

I guess this second idea is close to the one expressed by Christophe 
Jelger when he talks about "IPv6 MANET-local addresses" (please 
Christophe, correct me if I'm wrong).

3) use of a single ad hoc address to identify all MANet interfaces of a 
single node. This last point is more polemical and this proposition was 
made in order to ease the vertical handover (or interface mobility) 
inside a MANet.

More generally, I view a MANet as a new IPv6 scope. MANet interfaces 
must be attributed a MANet-local addresses in order to insure 
addressing and routing inside an isolated MANet and to give the 
addressing and routing material to setup other protocols such as global 
address configuration protocols in Internet-connected MANets. Just as 
with link-local addresses. A MANet multicast scope should also be 
defined in order to limit  the diffusion of information to the MANet or 
to a subset of the MANet (e.g. all MANet GWs...).The validity of theses 
MANet addresses must be limited to the MANet.
However, in order to make this scope viable, we should solve the issue 
of MANet boundarie which is for example partially responsible for the 
deprecation of site-local addresses (problem with site boudary 
definition). We must introduce a clear mechanism (e.g. flag in the 
system interface structure) to differentiate interfaces that are and 
are not part of a MANet. As soon as this is made, definition of a MANet 
becomes clear: it is a maximal connected set of MANet interfaces. 
MANet-restricted packets (the one using MANet-local addresses) must not 
be forwarded through interfaces that are not in MANET-MODE.

Best regards,
Guillaume Chelius.