Re: Extensions to OSPF to Support Mobile Ad Hoc Networking

Russ White <ruwhite@CISCO.COM> Mon, 23 February 2004 19:36 UTC

Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14674 for <ospf-archive@LISTS.IETF.ORG>; Mon, 23 Feb 2004 14:36:29 -0500 (EST)
Received: from PEAR.EASE.LSOFT.COM (209.119.0.19) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <4.00CFFB2C@cherry.ease.lsoft.com>; Mon, 23 Feb 2004 14:36:28 -0500
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 3590806 for OSPF@PEACH.EASE.LSOFT.COM; Mon, 23 Feb 2004 14:36:26 -0500
Received: from 64.102.122.148 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Mon, 23 Feb 2004 14:36:26 -0500
Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2004 11:38:53 -0800
Received: from cisco.com (shako.cisco.com [64.102.17.78]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i1NJaJ0K016296 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Feb 2004 14:36:24 -0500 (EST)
Received: from localhost (rtp-vpn3-305.cisco.com [10.82.217.51]) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) with ESMTP id OAA25907 for <OSPF@PEACH.EASE.LSOFT.COM>; Mon, 23 Feb 2004 14:36:19 -0500 (EST)
References: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2EA@xch-nw-27.nw.nos.boeing.com>
X-X-Sender: ruwhite@shako.cisco.com
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Message-ID: <Pine.WNT.4.53.0402231432140.4016@russpc.Whitehouse.intra>
Date: Mon, 23 Feb 2004 14:36:18 -0500
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Russ White <ruwhite@CISCO.COM>
Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking
To: OSPF@PEACH.EASE.LSOFT.COM
In-Reply-To: <6938661A6EDA8A4EA8D1419BCE46F24C020AC2EA@xch-nw-27.nw.nos.boeing.com>
Precedence: list

> > Using LLS gives you the ability to add anything to an existing OSPF
> > packet, rather than always declaring a new type...thus, preserving
> > backwards compatability. If an OSPF router receives a Hello packet with
> > LLS, and doesn't support LLS, it will simply ignore it.  The sender can
> > then decide to build the adjacency normally, or just not build an
> > adjacency at all.  On the flip side, if a Hello is replaced with a new
> > Incremental Hello packet type that is not supported, this breaks
> > backwards compatability.
>
> I didn't see explicitly mentioned in the draft that these extensions
> allow adjacencies to be created between MANET and non-MANET interfaces,
> with the MANET mechanisms working correctly throughout the subnet.  Is
> this the case?

The idea would be that if a new neighbor doesn't send us the LLS
information, we would be able to know that (because they don't respond with
the new packet format, or don't send it at all), and we can determine, at
that point, if we should form an adjacency or not (this would be
implementation/configuration specific).

Something I could envision (this is just thinking out loud) is that we
could detect nonMANET neighbors on a given physical interface, and put
these neighbors on a seperate logical interface, so such auto-detection
would/could be useful in some situations (?).

:-)

Russ


__________________________________
riw@cisco.com CCIE <>< Grace Alone