Subject: [manet] Some NHDP Concerns

From: Ian Chakeres <[email-masked]>
Date: Fri, 21 Aug 2009 13:53:49 -0400

During my recent review of NHDP I uncovered several concerns to the
current specification. That said, the most recent version is an
improvement on the prior version, and I really like the new
explanatory text with examples in the appendix.

I feel the existing NHDP spec is pretty well defined when running by
itself; I am more concerned when it is run more widely - with multiple
interfaces, multiple instances, multiple extensions, and multiple.

I've gone ahead and elaborated a little more on these items, and a few
more, below.

#1) I am concerned about running multiple protocols on-top of NHDP,
e.g. OLSRv2 SMF. My understanding is that each extension protocol
(that requires other nodes participate) must define its own TLVs and
tag each address that is participating. If this is our method for
doing extensions, let's make it explicit. Also, if OLSRv2 or SMF isn't
doing it right at the moment we should adjust them.

#2) I don't see how to run multiple NHDP instances on the same
interface or same router. PacketBB says that only one protocol
instance can accept a particular message. Currently there is no way to
identify which NHDP instance a NHDP message should be delivered.

#3) In the current spec there is no single identifier for a NHDP node;
instead a NHDP node is identified by the set of its IP addresses. I
really liked the new explanatory text and examples, but I still find
this complex - especially when there are multiple interfaces and
multiple hops. Can someone please explain to me why we don't use a
nhdp-node-id? Is this is related to relay set calculations.

#4) I don't see a way to identify a neighboring NHDP node's interface.
This is most important when multiple interfaces use the same IP
address (un-numbered interfaces).

#5) I would like text explaining why NHDP is such a complex HELLO
protocol, specifically that NHDP was build to assist in calculating
reduced relay sets (e.g. MPR, CDS). I think this stated purpose will
be helpful in explaining why certain information is included and the
overall design of the protocol.

#6) The spec explicitly identifies using multicast & broadcast, but it
does not mention using unicast for distribution of NHDP
messages/packets. I think we should be able to execute NHDP over
unicast transport too, although it might require more configuration.

I suspect some of my concerns may simply require further explanation
for me to ascertain the existing correctly specified behavior. If you
can shed light on any of the items above, please reply.

Thanks.
Ian Chakeres

---

From: "Justin Dean" <[email-masked]>
Date: Fri, 21 Aug 2009 15:16:20 -0400

While I would prefer to be addressing these issues within the scope of a
last call, my comments to the items in question are inline.

> -----Original Message-----
> From: Ian Chakeres [mailto:[email-masked]]
> Sent: Friday, August 21, 2009 1:54 PM
> To: MANET IETF
> Cc: Joe P Macker; Thomas Heide Clausen; Christopher Dearlove; Justin
> Wendell Dean
> Subject: Some NHDP Concerns
> 
I would not be opposed to expanding and elaborating on some common issues
which protocols using NHDP would need to address.  On the other hand I would
not be for mandating specific protocol behaviors as this is clearly outside
of the scope of NHDP. 

> identify which NHDP instance a NHDP message should be delivered.
Packetbb, RFC 5444, disallows this behavior.  Having more than one NHDP
instance on an interface will result in ambiguous behaviors.

> nhdp-node-id? Is this is related to relay set calculations.
A single identifier would seem to provide some functionality by logically
grouping addresses of nodes together.  I say seem because at the NHDP level
it doesn't really tell you anything as the addresses and interfaces they
represent might have differing functionality and although be co-located on
the same machine knowing this provides no extra benefit other than perhaps
network displays (they could not be used for CDS calculations as it isn't
know if all addresses provide the same functionality).  If the addresses all
have the same functionality then another TLV would have to be attached
indicating this thus providing redundant TLV messaging, SMF defines TLVs
which provide this behavior.  Having a single id would also increase
overhead (in the form of TLVS) in that all addresses would have to be
provided anyhow rather than just using a single id.  Furthermore things get
even more complicated when these identifier addresses change or disappear
but the underlying addressing does not.  Any protocol which would want this
type of functionality could easily provide it with a new TLV type which
would provide (in NHDP case) duel functionality indicating
co-location/protocol functionality.  IMO this is where the grouping of
addresses into one ID belongs using TLVs belongs in derived protocols.
 
> address (un-numbered interfaces).
I don't know anyone who deploys MANETs in this way but...if they were my
first question to them would be for what purpose are they the same?  Do they
need to be that way?  To me this seems like a very poorly configured MANET.
That being said here is a proposal for a solution to that "problem",
provided for discussion.

Introduction of an NHDP_AREA message level TLV which could de-conflict these
interfaces.
An optional TLV  which includes a value field which is administratively
configured.
Lack of this TLV would indicate a value of ONE or ZERO or whatever number is
decided upon.
Upon reception of an NHDP message the NHDP instance would ignore any NHDP
message which has a differing NHDP_AREA value other than itself.
The default mode of operation would be no TLV.

I am not currently convinced this is a good/bad idea just one which may
provide some extra functionality which some are looking for.

I also considered various schemes for using TLVs to "renumber" the
interfaces to de-conflict them.  I did not think of any satisfactory
solutions within routing layer scope which would not require extensive
changes to NHDP.  Using different physical or mac level distinguishers all
could work, although using the same address for multiple interfaces just
seems like a scenario ripe for being broken in one way or another.

> overall design of the protocol.
While CDS calculation is one of the goals it is not the only usage/goal of
NHDP.  I am not against expanding rational but am wary of language which
would limit the potential usefulness of NHDP to other possible protocol
uses.

> unicast transport too, although it might require more configuration.
While my co-authors may disagree I am not against allowing unicast (although
I don't see the use of it).  I prefer leaving it out but not specifically
disallowing the behavior either.

> can shed light on any of the items above, please reply.

Justin

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 24 Aug 2009 09:36:31 +0100

I will make some more specific comments later, but (unless I've
missed a subtlety below) I agree with Jstin's comments, that the 
resolution of all of these points (which are comments appropriate
to in WGLC, not to delay WGLC) is a mixture of a few odd sentences
to add, delegation to derived protocols (which is a reason for a
couple of the odd sentences) and don't do that. I have some specific
comments on what a delegated protocol might do, which varies (and
is a key reason for delegation).

-- 
Christopher Dearlove
Technology Leader, Communications Group
Networks, Security and Information Systems Department
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194  Fax: +44 1245 242124

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: Justin Dean [mailto:[email-masked]] 
Sent: 21 August 2009 20:16
To: 'MANET IETF'
Cc: 'Joe P Macker'; 'Thomas Heide Clausen'; Dearlove, Christopher (UK)
Subject: RE: Some NHDP Concerns

                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.

> doing it right at the moment we should adjust them.
I would not be opposed to expanding and elaborating on some common
issues
which protocols using NHDP would need to address.  On the other hand I
would
not be for mandating specific protocol behaviors as this is clearly
outside
of the scope of NHDP. 

> nhdp-node-id? Is this is related to relay set calculations.
A single identifier would seem to provide some functionality by
logically
grouping addresses of nodes together.  I say seem because at the NHDP
level
it doesn't really tell you anything as the addresses and interfaces they
represent might have differing functionality and although be co-located
on
the same machine knowing this provides no extra benefit other than
perhaps
network displays (they could not be used for CDS calculations as it
isn't
know if all addresses provide the same functionality).  If the addresses
all
have the same functionality then another TLV would have to be attached
indicating this thus providing redundant TLV messaging, SMF defines TLVs
which provide this behavior.  Having a single id would also increase
overhead (in the form of TLVS) in that all addresses would have to be
provided anyhow rather than just using a single id.  Furthermore things
get
even more complicated when these identifier addresses change or
disappear
but the underlying addressing does not.  Any protocol which would want
this
type of functionality could easily provide it with a new TLV type which
would provide (in NHDP case) duel functionality indicating
co-location/protocol functionality.  IMO this is where the grouping of
addresses into one ID belongs using TLVs belongs in derived protocols.
 
I don't know anyone who deploys MANETs in this way but...if they were my
first question to them would be for what purpose are they the same?  Do
they
need to be that way?  To me this seems like a very poorly configured
MANET.
That being said here is a proposal for a solution to that "problem",
provided for discussion.

Introduction of an NHDP_AREA message level TLV which could de-conflict
these
interfaces.
An optional TLV  which includes a value field which is administratively
configured.
Lack of this TLV would indicate a value of ONE or ZERO or whatever
number is
decided upon.
Upon reception of an NHDP message the NHDP instance would ignore any
NHDP
message which has a differing NHDP_AREA value other than itself.
The default mode of operation would be no TLV.

changes to NHDP.  Using different physical or mac level distinguishers
all

> overall design of the protocol.
While CDS calculation is one of the goals it is not the only usage/goal
of
NHDP.  I am not against expanding rational but am wary of language which
would limit the potential usefulness of NHDP to other possible protocol
uses.

> unicast transport too, although it might require more configuration.
While my co-authors may disagree I am not against allowing unicast
(although
I don't see the use of it).  I prefer leaving it out but not
specifically
disallowing the behavior either.

Justin

********************************************************************
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.
********************************************************************

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 24 Aug 2009 15:43:41 +0100

Sorry, top-posting is evil, but I'm doing it here. Please
disentangle to read properly. But of course the earlier
postings can be read as made in sequence.

I'll make one specific comment. SMF (and variations that it
could use) shows an example of why delegation to the derived
protocol (n various alternative use cases) is to be preferred.

One might think that all you need in SMF is a simple "I am an
SMF router" added to HELLO messages (message TLV). That both
doesn't work and almost works.

- It doesn't work because SMF is not a single protocol, but a
  familiy of protocols in flooding algorithm. (Also in DPD issues,
  but that's not important right now.) So the SMF message TLV
  needs a parameter for flooding algorithm.

- It almost works in that that message TLV is sufficient to
  ensure that flooding doesn't attempt to use an unsuitable
  router as an intermediate. (At least, I think that's the
  case. All such things need rigorously proving before we
  base a protocol on them.) But it doesn't work efficiently.
  If I have a neighbour A, and A has neighbours B, C, D, ...
  but none of the latter are (compatible) SMF routers, then
  with just a message TLV I may pick A as an MPR (for example)
  but actually I don't need to, and it would be more efficient
  not to do so. So SMF has a second TLV to mark addresses.

However with regard to the latter point, SMF for MPRs wants
that second TLV. SMF for blind flooding doesn't. That's all
information that NHDP doesn't know. In fact had a simple TLV
for NHDP been designed we might have missed the address block
TLV requirement. And if we defined both TLVs (as SMF does)
we might miss another case that some NHDP derivative needs.
Only the derived protocols know this stuff. And each derived
protocol is also where to make tradeoffs. For example here
is a simple modification to the SMF strategy that typically
saves octets - make the message TLV specify a default for
the address block TLV, thus saving the address block TLV
when all routers are using the same SMF variant. Is that
appropriate for SMF? We could debate this. Should some other
extension protocol make a different tradeoff? Quite possibly.

And there are more cases. One such is that if administratively
I know which other routers are sharing routing protocol with
me, as we should form a subnet, then I can filter on HELLO
sending addresses to separate uses. (I could filter either by
dropping HELLO messages I don't want, or I could filter by
putting everything into various protocol sets, but ignoring
Tuples with the "wrong" addresses. This is, in effect,
allowing different protocols to have different "views" of
NHDP's Information Bases.) Or I could filter at L2 - if you
don't have the right IDs and encryption keys you are out.
This may leave me able to simply ignore the whole issue of
alternative uses of NHDP, because in my closed world defined
by that ID/key there are no alternative uses of NHDP, so why
waste octets on excluding them?

(I would expect to cover the latter case to end up with the
derived protocol using SHOULD level mechanisms, possibly
backed up by a MUST do this or something administrative.
But we can debate that in due course.)

Incidentally I've done some work on something which basically
is unicast NHDP. And there are some significant issues,
including:

- Efficiency: If you have N neighbours, local broadcast NHDP's
  workload is fixed, unicast NHDP's workload scales as N does.

- Bootstrapping: Local broadcast is assumed to find other routers
  that could be neighbours (within range in a typical wireless
  system). But unicast won't do that for you. You need an alternative
  approach to deal with this.

- Theoretical timing issues, you can produce a race condition if you
  extend this to flooding by hop by hop unicast.

This all leads to that unicast NHDP is not a simple base protocol
variant, but rather needs someone who knows what they are doing
- which may involve an extension. Specifying the base protocol
using local broadcast/multicast and leaving open the avenue to a
unicast extension by not actually banning it is again the best
approach I strongly suggest.

Finally if you want a unique identifier, RFC 5444 provides the
message originator address to do that task. And the next version
of OLSRv2 will require message originator addresses in all cases
(but with a feature to avoid adding any overhead in the single
address router case). But some NHDP uses (e.g. SMF) don't require
it, and hence bandwidth efficiency suggests omitting from this
base specification.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Dearlove, Christopher (UK)
Sent: 24 August 2009 09:37
To: Justin Dean; MANET IETF
Cc: Thomas Heide Clausen
Subject: Re: [manet] Some NHDP Concerns

                    *** WARNING ***

-----Original Message-----
From: Justin Dean [mailto:[email-masked]] 
Sent: 21 August 2009 20:16
To: 'MANET IETF'
Cc: 'Joe P Macker'; 'Thomas Heide Clausen'; Dearlove, Christopher (UK)
Subject: RE: Some NHDP Concerns

                    *** WARNING ***

 

Justin

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

---

From: Ian Chakeres <[email-masked]>
Date: Thu, 27 Aug 2009 09:46:12 -0400

Comments inline

> not be for mandating specific protocol behaviors as this is clearly outside

I think it is appropriate for NHDP to provide clear instructions for
extensions to NDHP. My example above which is true for both SMF &
OLSRv2 seems appropriate for inclusion. I suspect I may be unaware of
other important pieces of wisdom for NHDP extensions. If you are aware
let's please discuss them.

> instance on an interface will result in ambiguous behaviors.

RFC 5444 does not disallow the behavior I described. It does disallow
having multiple NHDP instances receive the same message. Therefore,
there must be a way to determine the instance of NHDP to which a
message should be delivered.

> addresses into one ID belongs using TLVs belongs in derived protocols.

I understand what you are saying, but I'm not sure I agree.

Here is one situation in which I think it would help to have single
identifier. Let's imagine that a NHDP node is going to sign its
messages - which identifier or set of identifiers would it use to
identify itself? Knowing that the other device may or may not have the
complete set of IP addresses associated with this particular NHDP
node.

I would actually feel more comfortable depending on a fixed NHDP
identifier, instead of an IP address which might be changed as you
pointed out.

> That being said here is a proposal for a solution to that "problem",

There are many cases when existing routers use unnumbered interfaces
presenting the same IP address/identifier on multiple interfaces. I
think this can make it easier to address and manage the router.

> seems like a scenario ripe for being broken in one way or another.

I agree there are several different ways to solve this problem. I am
open to discussing several and deciding upon the most appropriate.

> would limit the potential usefulness of NHDP to other possible protocol

I also would not like to limit the potential usefulness of NHDP.
Although, I do feel that the document appears overtly complex for the
basic functionality provided in the NHDP spec, and I think it is
important to explicitly call out and explain why certain complexity
was included to simplify NHDP extensions, e.g. OLSRv2 & SMF.

---

From: Ian Chakeres <[email-masked]>
Date: Thu, 27 Aug 2009 09:52:01 -0400

Comments about unicast NHDP.

I agree that finding out about unicast neighbors dynamically is
challenging, but in the case where you know who your unicast neighbor
is (e.g. point-to-point) - I think it is very valuable to be able to
run NHDP between these neighbors.

Therefore, I would say that unicast NHDP should be included if
properly administratively configured.

Ian

On Mon, Aug 24, 2009 at 10:43 AM, Dearlove, Christopher
(UK)<[email-masked]> wrote:
<snip>
> approach I strongly suggest.
<snip>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 27 Aug 2009 15:58:11 +0200

I would, like Justin, much prefer addressing these issues within the  
scope of a last call, corresponding to the consensus at the Stockholm  
WG meeting.

Comment below.

>> last call, my comments to the items in question are inline.

<SNIP>

> message should be delivered.

RFC5444 reads:

    o  For each Message Type, a protocol -- unless specified otherwise,
       the one making the IANA reservation for that Message Type -- MUST
       be designated as the "owner" of that Message Type.
<SNIP>
    o  Incoming messages MUST be either silently discarded or MUST be
       delivered to the instance of the protocol that owns the  
associated
       Message Type.  Incoming messages SHOULD NOT be delivered to any
       other protocol instances and SHOULD NOT be delivered to more than
       one protocol instance.
The detail you're to be looking carefully at is in the first sentence  
of the second bullet.

I believe that this addresses the issue fully.

Thomas

---

From: Ian Chakeres <[email-masked]>
Date: Thu, 27 Aug 2009 10:12:10 -0400

Comments about NHDP extensions.

I think your example below calls out the complexity involved in
building a NHDP extension, and I agree that in certain cases the
extension may be best suited to define the implementation.

As you mentioned, if a particular NHDP extension expects/requires
other NHDP instances running the same extension, or a compatible
extension, its messages need to be properly tagged.

I think we should call this particular case out & any other important
lessons that we've already learned from OLSRv2 and SMF.

Ian

<snip>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 27 Aug 2009 15:14:57 +0100

> extensions to NDHP.

NHDP should say "you need to ensure that ..." but not "you need to
ensure that by doing this".

> My example above which is true for both SMF &
> OLSRv2 seems appropriate for inclusion.

We will not have a dependency, normative or non-normative of NHDP
on SMF or OLSRv2. So the specific example in those terms is not
appropriate. And as previously noted, different extensions will
have different things to manage, and a "one size fits all"
mechanism in NHDP is not appropriate.

---

From: Ian Chakeres <[email-masked]>
Date: Thu, 27 Aug 2009 10:20:44 -0400

Comments about administrative exclusion.

I agree completely that users likely need methods to explicitly
identify information, possibly identified as not appropriate for
processing or disseminating. I think that the exclusion criteria must
be inside NHDP and not exclusively based upon information from other
layers (e.g. mac address, src/dst ip address).

I feel that requiring NHDP, or any protocol, mix information from
other protocols with NHDP may muddy the meaning of the other
information and limit the flexibility of each layer.

Ian

<snip>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 27 Aug 2009 15:25:46 +0100

I would expect - in WGLC, which is seriously overdue and
should have been called a month ago - to add something like
the following comments to WGLC. These are rough notes, not
proper wording. They go along with the notes about a protocol
extension being able to add to a HELLO message.
- In some cases, a protocol using NHDP may need to recognise
  which HELLO messages, or which parts of a HELLO message
  (specifically which neighbour addresses) it should process.
  In these cases, the protocol must ensure that required
  information is appropriately labelled (e.g. with message
  and/or address block TLVs).
- In other cases, due to protocol design, or administrative
  configuration (e.g. considering address ranges) such
  additions to a HELLO message may not be necessary.

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 27 August 2009 15:12
To: Dearlove, Christopher (UK)
Cc: Justin Dean; MANET IETF; Thomas Heide Clausen
Subject: Re: [manet] Some NHDP Concerns

                    *** WARNING ***

Ian

<snip>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 27 Aug 2009 15:29:42 +0100

The most obvious information that may be used is IP
addresses. That is not mixing layer information.

In other cases, the other layers may provide the
exclusion needed without NHDP having to be aware of
this happening. If I am running OLSRv2 over 802.11
and I set my 802.11 IDs and security so that in my
specific deployment I know that OLSRv2 is all I'm
going to see, because no device that knows that stuff
has anything else deployed, why should I waste
octets in HELLO messages to exclude the possibility
of something that can't happen?

-----Original Message-----
From: Ian Chakeres [mailto:[email-masked]] 
Sent: 27 August 2009 15:21
To: Dearlove, Christopher (UK)
Cc: Justin Dean; MANET IETF; Thomas Heide Clausen
Subject: Re: [manet] Some NHDP Concerns

                    *** WARNING ***

Ian

<snip>

---

From: jacquet <[email-masked]>
Date: Thu, 27 Aug 2009 16:42:24 +0200

As far as I know signatures require a lot more informations than an  
unique identifier of few bytes. An efficient signature would be close  
to 1000 bits and the basic keys would be echanged via an external  
intermediation protocol. But maybe we are not talking of the same thing.

Philippe

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 28 Aug 2009 15:47:21 +0200

Comment below.

> properly administratively configured.

The scenario you summon is, that you have a point-to-point connection  
to (one of) your neighbors.

If you *know* this to be true, then either (likely) you have a  
physical point-to-point link between yourself and that neighbor -- or  
you don't have a physical link but you know that the connectivity is  
so stable that you can set one up (with a virtual interface in each  
end, if need be) easily.

In that case, if you run NHDP as-is, over your point-to-point link,  
the NHDP multi/broadcasts essentially becomes the "unicast" that you  
suggest. Managing your suggested point-to-point connectivity as such  
allows NHDP to be run identically across also these interfaces.

Therefore, I would say that this is a matter of properly  
administratively configuring of your point-to-point connectivity, and  
not NHDP.

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Fri, 28 Aug 2009 17:50:46 +0200

Comment below.

> overall design of the protocol.

The current draft-ietf-manet-nhdp-10 (as well as all revisions back  
until draft-ietf-manet-nhdp-07, dated July 10 2008) explicitly states  
in section 1.1 that:

    MANET routing protocols, for example [RFC3626] and [RFC5449], often
    employ relay set reductions in order to conserve network capacity
    when maintaining network-wide topological information, with
    calculation of these reduced relay sets employing up to two hop
    information.
I believe that this addresses the issue fully.

Thomas

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 31 Aug 2009 08:55:18 -0400

If the term "instance" is excluded by a SHOULD, let's instead use the
term "area" or another term to logically separate NHDP information. Is
there a term you prefer?

I think the ability to identify/separate information and allow
multiple people to use the same physical medium is especially
important in wireless networks.

Ian

On Thu, Aug 27, 2009 at 9:58 AM, Thomas Heide
Clausen<[email-masked]> wrote:
> I would, like Justin, much prefer addressing these issues within the scope
> of a last call, corresponding to the consensus at the Stockholm WG meeting.
> Comment below.
>       delivered to the instance of the protocol that owns the associated
> The detail you're to be looking carefully at is in the first sentence of the
> second bullet.

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 31 Aug 2009 09:05:54 -0400

I believe there are several design decisions involving higher
complexity. beyond that of simply a 2-hop neighbor hello protocol,
that have been introduced into NHDP to enable and facilitation reduced
relay sets. I feel that a person outside MANET would be perplexed why
things are written the way they are written.

I know that this complexity issue was one of the major things that
Elwyn Davies had identified in NHDP-05. I will ask if he can review
the document again to see if the current specification satisfies him.

Ian Chakeres

On Fri, Aug 28, 2009 at 11:50 AM, Thomas Heide
Clausen<[email-masked]> wrote:
> The current draft-ietf-manet-nhdp-10 (as well as all revisions back until
> draft-ietf-manet-nhdp-07, dated July 10 2008) explicitly states in section
> 1.1 that:
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Aug 2009 15:07:35 +0200

> term "area" or another term to logically separate NHDP information. Is

It is not a matter of preferring a term over the other, it's a  
conceptual matter.

> important in wireless networks.

NHDP simply detects connectivity. If a protocol (such as SMF) wants to  
be further discriminative as to which connectivity it wants to use,  
then this is a task for that protocol (e.g. by decorating with TLVs) -  
and most certainly not for NHDP.

You can even construct an efficiency argument as for why this would be  
a bad thing to do.

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Aug 2009 15:09:50 +0200

> things are written the way they are written.

The main complexity in NHDP is due to the fact that *correctly*  
detecting bidirectionality between pairs of wireless interfaces,  
especially when faced with routers with multiple interfaces  
potentially operating in the same spectrum, is a complex task.

Thomas

>> until

---

From: Ian Chakeres <[email-masked]>
Date: Mon, 31 Aug 2009 09:13:18 -0400

I believe that conceptually, NHDP and the other WG protocols should
allow multiple areas of information to be administratively separated,
especially since wireless will not provide any strict physical
separation.

Ian Chakeres

On Mon, Aug 31, 2009 at 9:07 AM, Thomas Heide
Clausen<[email-masked]> wrote:
> It is not a matter of preferring a term over the other, it's a conceptual
> matter.
>
> NHDP simply detects connectivity. If a protocol (such as SMF) wants to be
> further discriminative as to which connectivity it wants to use, then this
> is a task for that protocol (e.g. by decorating with TLVs) - and most
> certainly not for NHDP.
>
> You can even construct an efficiency argument as for why this would be a bad
> thing to do.
>
> Thomas
>
>> Ian
>>
>>> scope

---

From: Thomas Heide Clausen <[email-masked]>
Date: Mon, 31 Aug 2009 15:29:33 +0200

NHDP detects connectivity over the wireless medium. Nothing more,  
nothing less.

If another protocol wishes to do something additional, require  
something additional for admitting a communicating pair into its  
operation, then that protocol should be responsible for determining  
such. An example: An SMF router may wish to discriminate among other  
SMF routers based on their relay algorithm capabilities. Therefore,  
SMF includes a way of doing such. And NHDP includes a way for SMF to  
embed necessary signaling in NHDP HELLO messages by way of TLVs.

Alternatively, for each perceived "administrative separation" (such as  
"for each relay selection algorithm in SMF"), you would have to send  
distinct HELLO messages over the same interface and so consume network  
capacity for no good reason whatsoever, and for no benefit whatsoever.

This is not an NHDP issue, this is an issue for protocols using NHDP  
-- and (as we have seen in SMF), "administratively separated areas" is  
*not* sufficient to be a solution.

I therefore maintain my position on this matter -- that NHDP  
definitely should not do anything more than detect connectivity over  
the wireless medium.

Thomas

On Aug 31, 2009, at 3:13 PM, Ian Chakeres wrote:

>> conceptual
>>>> On Fri, Aug 21, 2009 at 3:16 PM, Justin  
>>>> Dean<[email-masked]>
>>>> wrote:
>>>>
>>>> The detail you're to be looking carefully at is in the first  
>>>> sentence of
>>>> the
>>>> second bullet.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 31 Aug 2009 15:38:15 +0200

> definitely should not do anything more than detect connectivity over
I agree to this.

NHDP as a protocol does not need to know anything except a very basic 
"presence service". It records what connections it has to it's one hop 
neighbors and their connection to other neighbors. Nothing more, nothing less.

NHDP implementations might do more stuff, because other protocols like SMF or 
OLSRv2 add additional TLVs to the hello messages to be more efficient. What 
these TLVs do is out of scope for the NHDP protocol, but the implementation 
needs some kind of multiplexer if you want to allow multiple other protocols 
enhancing NHDP. Normally NHDP will be integrated with another protocol (or 
multiple protocols) into a single implementation, but thats beyond the scope 
of the protocol.

Henning Rogge

*************************************************
Diplom Informatiker Henning Rogge
Forschungsgesellschaft für
Angewandte Naturwissenschaften e. V. (FGAN) 
Neuenahrer Str. 20, 53343 Wachtberg, Germany
Tel.: 0049 (0)228 9435-961
Fax: 0049 (0)228 9435-685
E-Mail: [email-masked]
Web: www.fgan.de
************************************************
Sitz der Gesellschaft: Bonn
Registergericht: Amtsgericht Bonn VR 2530
Vorstand: Dr. rer. nat. Ralf Dornhaus (Vors.), Prof. Dr. Joachim Ender 
(Stellv.)