Subject: RE: [manet] RE: [Autoconf] Fwd: I-D ACTION:draft-chakeres-manet-iana-00.txt

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 26 Jul 2006 11:07:22 +0100

> Assuming the same mcast address and different ports... Since we don't
want
> OLSRv2 and NHDP messages to be disaggregated, then they should use the
same
> port, right? Then, a node running DYMO and NHDP would process the
routing
> messages sent by a neighbor running OLSRv2.
>
> So, even routing protocol messages are processed by nodes which aren't

> interested in them (unless I'm missing something). Of course, this
only
> happens if the nodes implement NHDP, but that's quite likely.

This is a point I've been thinking about, to no definite conclusion.
In fact it's even more complicated in one regard, but not quite as
bad as the above might suggest in another.

My previous comment was about if you want to separate protocol messages,
different multicast addresses are one option, but different ports are
another. But as you note, you may want to put them together, in which
case you really want the same multicast address, and maybe the same
port.

I'll consider OLSRv2 and SMF, as they make the point I want to make.
Both use NHDP, and NHDP sends and receives HELLO messages. But it's
more than that. Assuming we don't want to duplicate messages:

- The basic NHDP HELLO messages aren't sufficient for OLSRv2 or SMF.
  OLSRv2 needs to add WILLINGNESS and MPR TLVs. SMF may use these or
  (for a more interesting case) may want to add some other sort of
  CDS messages. So both protocols want to "decorate" the HELLO message
  outgoing. Note that having both in the same HELLO message should be
  fine.

- For efficient messages, OLSRv2 would like to control the HELLO
  message address ordering. SMF might want to do the same, but not
  in the same order. This needs further consideration.

- Both protocols need to see incoming HELLO messages.

- OLSRv2 generates and forwards TC messages. These must be able
  to be piggybacked with HELLO messages in multi-message packets.
  (Given that in many cases the number of packets is what matters,
  the size of the packets is not significant, it could even be more
  efficient to run NHDP twice in parallel than lose this capability.)

- Note that a protocol not using message type X can in fact skip that
  entire message reading only the type, ignoring the semantics, and
  the message length, and then skipping ahead by that message length.
  There is no need to even parse the rest of the message header.

- OLSRv2 (at least) may want to suggest a rescheduling of HELLO
  messages to NHDP. It may want to force all addresses to be
  reported, in particular if its MPR Set changes.

- Other scenarios to be considered are that there may be a need to
  add a signature to a message or packet. In both cases this needs
  to be the last thing done.

The architecture of all this is not trivial, or at least allowing the
options everyone might want isn't. In my case I would implement OLSRv2,
and SMF can be treated as an extension to OLSRv2. But others may not
want to do that. And I haven't even considered if DYMO wants to join
the party - noting that running OLSRv2 and DYMO together is a mostly
futile exercise, except on a node which reports itself as a gateway
into each of two separate MANETs, one running DYMO, one running OLSRv2.

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

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

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 26 Jul 2006 11:58:33 -0400

Chris:

I just want to clarify that SMF has three neighborhood discovery modes
defined in -02. The writeup below sounds like its always required to run
NHDP separately.  So SMF does not need to see HELLOs in mode (2) or (1) just
for clarification.

(3) would be updated to reference NHDP and related TLVs as you mention for
independent operation.  The present prototype implementations often run in
(2) mode which means OLSRv2 or MANET-OSPF,etc would run the neighborhood
discovery and the appropriate optimized CDS (e.g., MPR) information would be
shared.

   With respect to neighborhood topology knowledge and/or discovery,
   there are three basic modes of SMF operation:

   1.  Classical Flooding (CF) mode with no requirement for discovery or
       knowledge of neighborhood topology,

   2.  External control mode where an external process dynamically sets
       the local SMF relay status (e.g., Early SMF prototypes have
       leveraged neighborhood toplogy information collected by MANET
       unicast routing protocols such as OLSRv2 or Manet-OSPF ), and

   3.  Independent operating mode using a neighborhood discovery
       ("hello") protocol to collect the local topology information
       required for the various CDS algorithm modes discussed in the
       Appendices. 

>-----Original Message-----
>From: Dearlove, Christopher (UK) 
>[mailto:[email-masked]] 
>Sent: Wednesday, July 26, 2006 6:07 AM
>To: Francisco J. Ros; [email-masked]
>Cc: [email-masked]; Thomas Clausen
>Subject: RE: [manet] RE: [Autoconf] Fwd: 
>I-DACTION:draft-chakeres-manet-iana-00.txt
>
>
>In fact it's even more complicated in one regard, but not 
>quite as bad as the above might suggest in another.
>
>My previous comment was about if you want to separate protocol 
>messages, different multicast addresses are one option, but 
>different ports are another. But as you note, you may want to 
>put them together, in which case you really want the same 
>multicast address, and maybe the same port.
>
>Both use NHDP, and NHDP sends and receives HELLO messages. But 
>it's more than that. Assuming we don't want to duplicate messages:
>
>The architecture of all this is not trivial, or at least 
>allowing the options everyone might want isn't. In my case I 
>would implement OLSRv2, and SMF can be treated as an extension 
>to OLSRv2. But others may not want to do that. And I haven't 
>even considered if DYMO wants to join the party - noting that 
>running OLSRv2 and DYMO together is a mostly futile exercise, 
>except on a node which reports itself as a gateway into each 
>of two separate MANETs, one running DYMO, one running OLSRv2.
>
>
>This email and any attachments are confidential to the 
>intended recipient and may also be privileged. If you are not 
>the intended recipient please delete it from your system and 
>notify the sender.
>You should not copy it or use it for any purpose nor disclose 
>or distribute its contents to any other person.
>Autoconf mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/autoconf
>