Subject: Re: OSPF WG Direction with respect to MANET Requirements

From: Vishwas Manral <[email-masked]>
Date: Wed, 26 Nov 2003 10:11:49 +0200

Hi Acee/Fred,

I have just started looking into ad-hoc networks so excuse me if I miss the
point. I browsed thru the slides
http://www.ietf.org/proceedings/02mar/slides/manet-1/sld005.htm and checked
the problem statement.

I think new LSA types/dynamic metric calculations(can be internal to an
implementation) would need to be added too besides the changes Acee has
listed. I am not sure what changes are required for the DR election, are you
suggesting that the STA(AP) with the route to the ABR becomes the DR.

Ad-hoc networks are IBSS LAN's, they do not have a DS. Why would we need to
have connection of Manet area to other Integrated LANs(I see the point in
Fred's slides too)? Is it for intermittently connecting to the internet,
when the cluster can(when it would not be an ad-hoc network)?

I have another doubt, is there an assumption that all STA's support IPv6?
Are any new security extensions also planned to be defined?

I feel we should proceed with Point 3 in Acee's mail.

Thanks,
Vishwas

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Fred
Baker
Sent: Wednesday, November 26, 2003 1:35 AM
To: [email-masked]
Subject: Re: OSPF WG Direction with respect to MANET Requirements

Acee:

At 11:56 AM 11/25/2003, Acee Lindem wrote:
>     1. Do nothing - Leave MANET to the routing protocol(s) currently
>        defined specifically for the MANET environment.
>
>     2. Define a OSPF-MANET boundary node which streamlines the
>        interfaction between the chosen MANET protocol (hopefully
>        one) and OSPF.
>
>     3. Define extensions to OSPFv3 which allow for one of more MANET
>        clouds to connect to an OSPFv3 backbone. The extensions should
>        be such that the base OSPFv3 network is insulated from the MANET
>        extensions so that OSPFv3 nodes not supporting the extensions
>        could co-exist outside the MANET cloud without changes. I say
>        OSPFv3 here since everyone at the WG meeting agreed that IPv6
>        was a requirement for MANET and everyone at the WG meeting
>        agreed that  any substanitive extensions should only goto into
>        OSPFv3.
>
>     4. Define a new protocol (OSPFv4) which attempts to satisfy
>        the requirements for OSPFv3 and MANET. It should be as
>        close to OSPFv3 as possible (but leaves out virtual
>        links :^).

I think there is at least one other approach that has been suggested, which
you have overlooked. IMHO, it is the simplest model.

In Alex's comments to Abhay Roy, he talked about a Manet Area. This
approach seemed to convolute the fundamental concepts of OSPF.
Operationally, one certainly wants to tie a string around the set of router
interfaces that form a manet network or part of one, both to constrain
their disruption of other parts of the network and to constrain the
interactions between similar-but-different manet networks. But
mobile-ad-hoc-ness is not fundamentally a characteristic of the area. The
area is a standard OSPF construct that one uses at an administrative or
policy boundary to ensure that proper summarization happens and unnecessary
changes are not propagated.

In your remarks, you talk about "extensions to OSPFv3 which allow for one
of more MANET clouds to connect to an OSPFv3 backbone". The manet cloud,
from the sound of it, is using another routing protocol. If you want to do
that, we can already do that - leaking routes between routing protocols is
something we pretty standardly do. But route leaking is not very pretty,
and we were hoping to not have to re-invent OSPF (areas, metrics,
multi-topology routing, and all that) to accomplish this. Heck, if we
wanted to go there, we would simply extend EIGRP, or adopt OLSR and extend
it with the things it needs to be deployable on a wide scale.

What we are proposing is something much simpler. We would like to add a
manet interface type to OSPFv3. The addition of this interface capability
is entirely optional - an implementation that never expects to be deployed
in a radio network need not implement it, and can fully expect to
interoperate with implementations that have implemented it, on their
non-radio interfaces.

The MANET interface is different from a standard serial interface (as it
has multiple neighbors) and different from a LAN interface (it has no DR).
I don't see that as a fundamental impediment; remember that about eleven
years ago I pointed out that the NBMA interface didn't work very well in
Frame Relay networks of the day and proposed what we now call the
point-to-multipoint interface. Adapting OSPF to new interface technologies
(F/R being fairly new then) is something that has always been integral to
OSPF's development. To throw out the idea of a manet interface because it
is different - well, that would be a step in conservatism that would cause
me a great deal of concern. I understand and very much support the
conservatism that says "don't break what already works". But conservatism
that prevents OSPF from addressing new requirements declares OSPF an
obsolete protocol, and forces new requirements into a new protocol. I don't
think of OSPF as obsolete...

Can you tell me why adding a manet interface to OSPF is not on of the
options you are willing to consider?

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 28 Nov 2003 12:06:02 -0800

> From: Vishwas Manral [mailto:[email-masked]]
> Sent: Thursday, November 27, 2003 6:05 AM
> Tom,
> I checked the link you sent a bit.
> 
> I may be wrong here but if we model our interfaces as P2MP, 
> we will not have
> a transit link from the Manet Area at all, as we are not 
> going above 2-way
> state in which case the only link for the P2MP network will 
> be (as per 2328)
> 
>                 o   A single Type 3 link (stub network) is added with
>                     Link ID set to the router's own IP interface
>                     address, Link Data set to the mask 0xffffffff
>                     (indicating a host route), and cost set to 0.

We do the additional step as in Point-to-Multipoint:

                o   For each fully adjacent neighbor associated with the
                    interface, add an additional Type 1 link (point-to-
                    point) with Link ID set to the Router ID of the
                    neighboring router, Link Data set to the IP
                    interface address and cost equal to the interface's
                    configured output cost.

This probably should be clarified further in the draft in section 12--
basically, on a wireless subnet, once neighbors get to state 2-Way
(seeing themselves in each other's Hellos) they are considered "fully
adjacent" from the perspective of generating LSAs (since they skip
database exchange) and can advertise Type 1 links between them.  

Tom