Subject: Re: MANET & IP layering

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 9 Apr 2001 21:03:01 -0700 (PDT)

Hello,

Richard Ogier and I spent a good bit of time discussing this and,
along with the helpful input received from others on the mailing
list, we think we have converged on a common viewpoint for IPv4 in
MANETs. Additionally, Richard has come up with what we both feel
may be a good general solution for handling limited broadcasts and
the low-numbered multicasts (addresses within the range of 224.0.0.0
through 224.0.0.255) in the context of service discovery protocol
operation in MANETs.

Our viewpoint on the operation of IPv4 in MANETs is as follows:

  1. Within the MANET routing protocol, the IPv4 address assigned
     to each MANET node is essentially treated as an independent
     node ID. That is, there is no requirement for a common prefix
     for IPv4 forwarding between nodes within the MANET.

  2. From the outside, the MANET must present itself to the rest
     of the Internet as a set of one or more aggregatable IPv4
     prefixes.

  3. In order to accomplish #2, some sort of subnet convergence
     should occur - perhaps through some sort of gateway affiliation
     protocol - such that one or more logical IPv4 subnets (LIS)
     appear to reside within the MANET when viewed from the outside.

In terms of the remaining issue I have been citing (i.e. how
to get the low-numbered multicasts to span multiple hops within
the MANET), Richard's idea entails IP-in-IP encapsulation for IPv4
packets sent to the limited broadcast address and low-numbered
multicast addresses, with the outer IPv4 header containing a
*routable* IPv4 multicast destination address that is reserved
with IANA for MANET operation.

For example, if an IPv4 multicast address such as:

  224.0.1.173

were reserved with IANA as an "All_MANET_Nodes" multicast address,
this address could be used as the IPv4 destination address in the
encapsulation header. Then, using an efficient multicast routing
protocol designed for MANETs, such encapsulated messages could be
forwared through the MANET based on TTL-based hop counts,
administrative scoping rules, or a combination of both. While
this idea appears to be a good fit for the service discovery
protocol probelm we have been discussing, we also think it might
be a good solution whenever an internet-level router performs
multicast over the MANET subnet, i.e., the MANET subnet emulates
a conventional broadcast subnet by providing multicast.

A significant advantage of this approach over either changing
the rules for IPv4 forwarding for the low-numbered multicasts
or changing service discovery applications to use routable IPv4
multicast addresses is that this *may* be possible by simply
setting system configuration parameters for a "tunnel interface"
on existing hosts and routers. In other words, this approach
*may* be possible with little/no modification to existing
applications and/or host and router systems software. Richard's
idea was motivated in part by the literature that describes
IP encapsulation over ATM, and so there is relevant precendence
for this approach within the Internetworking framework.

Comments?

Fred and Richard

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 10 Apr 2001 07:13:57 -0700

Hello Fred,

>      for IPv4 forwarding between nodes within the MANET.

Agreed -- but, we should _allow_ for regions to have a common prefix.

>      of the Internet as a set of one or more aggregatable IPv4

This has the disadvantage of excluding any other wireless node that
happens to arrive with an IP address not represented by the
aggregated prefixes.

However, if a manet node can use Mobile IP with a home agent in
the infrastructure, the need for advertising its prefix evaporates.

>      appear to reside within the MANET when viewed from the outside.

I'm willing to agree that manet gateways should be ABLE to advertise
subnets (as long as it's sensible to do so), but I don't believe
we should make the restriction that all manet nodes fit within the
advertised subnet aggregation.

> with IANA for MANET operation.

Maybe it would be better to have an "all-nodes" multicast
address, and use two other methods to restrict distribution:

1) setting TTL  <  network diameter, and

2) allowing gateway router policy to avoid forwarding along
   certain (say, wired) interfaces.

I'd _really_ hate to go down the road of partitioning the
Internet address space into manet/non-manet prefixes
or multicast addresses.

>                                                     While
> protocol probelm we have been discussing,

I'm interested in service discovery within manet, but I don't
recollect the discussion on the mailing list.  Did I miss it?

Regards,
Charlie P.

---

From: Joe Macker <[email-masked]>
Date: Tue, 10 Apr 2001 10:16:48 -0400

>      for IPv4 forwarding between nodes within the MANET.

Right.

>      of the Internet as a set of one or more aggregatable IPv4

Sounds like good practice... Host routes should be still o.k. for some 
applications (e.g., edge system mobile agents. e.g., mobile IP), but if you 
can present the manet cloud as aggregatable to the rest of the world great!.

>with IANA for MANET operation.

Don't forget ... control  information (e.g., OSPF LSUs) can be still 
flooded with low-numbered multicast and/or one hop unicast addresses since 
the flooding,etc is handled logically at the protocol level (not at the IP 
level) and replicated as needed... this also allows for better aggregation 
of control messages and specialized forwarding rules as needed, defined per 
protocol).... OSPF and other algorithms do a number of interesting things 
while using only single hop association addresses. You may still want the 
above, just pointing out there is another way to think about it if the 
concern is forwarding routing control messages. User data forwarding is 
another story, but I think it is important not to confuse the two areas of 
application.

---

From: "Fred L. Templin" <[email-masked]>
Date: Wed, 18 Apr 2001 17:41:06 -0700

Charlie,

Sorry for the delay in responding to you; please find some
comments/questions for your message below:

> Agreed -- but, we should _allow_ for regions to have a common prefix.

Yes, I agree. My language was vague - I was not intending to
imply that common prefixes should be disallowed within the MANET.
 
> the infrastructure, the need for advertising its prefix evaporates.

I was more or less expecting the mobile nodes would associate with
a Mobile IPv4 Foreign Agent when they join the MANET. I am under
the impression that, when a Mobile node receives a care-of-address
from a foreign agent in the MANET it is visiting, the care-of-address
assignment is under the control of either the foreign agent or
something like DHCP. So, the care-of-address would likely appear
as belonging to an aggregatable IPv4 advertisment from the
perspective of the Internet if the foreign agent and/or DHCP
server are configured in a coherent fashion. I suppose another
alternative is some sort of NAT to turn the mobile node's home
address into something that makes topological sense for the
MANET's attachment point to the Internet.

Can you think of any legitimate cases in which a foreign node
should be allowed to send an IPv4 packet from the MANET to the
Internet such that the IPv4 source address in the packet does
*not* belong to an aggregatable prefix which can be traced back
to the MANET? 
 
>    certain (say, wired) interfaces.

Yes, this is the same basic model we had in mind. We agree that
using the TTL to effectively establish a network diameter is one
possible configuration option. In terms of 2), this is basically
the same thing I was trying to imply in my original note when I
referred to "administrative scoping" for multicasts. Again, this
is one possible configuration option.

> Internet address space into manet/non-manet prefixes

No - we are not proposing any sort of split such as this. The
problem we are attempting to address is, for IPv4 packets sent
to the all-1's broadcast and low-numbered multicast addresses
(those in the range from 224.0.0.0 - 224.0.0.255), there may be
cases in which you would like the packets to travel more than
one hop - even though the IETF standards all specify that such
packets should not be forwarded. In some instances, you might
wish for these packets to be forward based on a hop count in
the TTL or some form of administrative scoping rules or both,
as we agreed above.

The particular instance we are concerned with is networks that
are formed by a collection of nodes with IEEE 802.11 interfaces
in ad hoc mode such that the graph of the topology is not fully
connected at the data link level. As such, the data link broadcast
messages sent by a node reach only a proper subset of the nodes on
the topology. We are torn between the notion of whether this model
represents just a special case of an NBMA network, or a new class
unto itself - perhaps a term such as "Limited Broadcast, Multiple
Access (LBMA)" would be appropriate. The IEEE 802.11 example is
just one such instance, and we agree that such networks are not
necessarily specific to MANETs. Therefore, we are not proposing
any MANET-specific language.

The idea my colleague Richard Ogier has proposed is a form of
IPv4-in-IPv4 encapsulation in which the destination address in both
the inner and outer headers is a multicast address. The address
in the outer header will be an IANA assigned number from the
range of *forwardable* IPv4 multicast addresses (those between
224.0.1.0 - 239.255.255.255) and the address in the inner header
will be the all-1's broadcast address or a low numbered multicast
address. (There may be application for other IPv4 address forms
beyond the particular case we are concerned with.) We are hoping
that this will allow services such as router advertisements and
Mobile IP agent advertisements to reach mobile nodes that are more
than one hop away from the sending node on such LBMA networks.

The plan would be to register a single assigned number with
IANA for MANET/LBMA multicasting as we have described it above.
(There may be other uses for such an assigned number beyond the
cases discussed so far in this thread.) We think that this may
allow existing applications and IPv4 protocol stacks to function
without modification since configuration parameters can be set
up on nodes that access the LBMA network to enable this sort of
IPv4-in-IPv4 encapsulation.

> recollect the discussion on the mailing list.  Did I miss it?

The term "service discovery" crept into this thread as the
discussion evolved - I believe I may have been at fault for
this. I was more or less using that term to colloquially refer
to the class of applications that send/receive messages using
the all-1's broadcast address or one of the low-numbered IPv4
multicast addresses. Sorry for any confusion this may have
caused.

Comments?

Fred Templin
[email-masked]