Subject: Re: [manet] OLSRv2 - RouterID

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 11:19:01 +0200

Hello,

I had some time to look at the MPR calculation in OLSRv2 and I'm still not
convinced that the interface IPs are necessary to calculate routing and
forwarding set. So I try to explain our (Markus Kittenberg from Vienna and
me) concept a little bit more.

Even if it's too late to include this into the main OLSRv2 RFCs I will 
continue to work on the concept to see if it can be done correctly because
I think it's a good idea to allow an easier use of linklocal addresses and
handling of dynamic interfaces.

The router-id of a node should be a FIXED IP address which does not change.

The base of the concept is that there should be no change in packet format,
just a change what kind of IP will be written into Hello/TC messages.

OLSRv2/NHDP messages changes
============================

Hellomessages:

- a Hello message MUST contain the router-ID of it's OLSR node as the
  originator-IP of the message
- a Hello message CAN include the interface IP of it's OLSR node as an
  address tagged with LOCAL_IF(THIS_IF). The address can be omitted if
  the source IP of the package contains the interface IP
- a Hello message don't need to include other interface IP's of it's
  OLSR node. If these IP's are included in the message they must be
  tagged with LOCAL_IF(OTHER_IF) as described in the current draft.
- all address IPs of 1-hop neighbors in the Hello message will be
  originator-IPs, tagges as described in OLSRv2 10.1.1 (Page 30).
  Especially the LINK_STATUS/OTHER_NEIGHB tlv allows to distinguish
  between 2-hop neighbors on the same interface as the received
  Hello message and 2-hop neighbors on other interfaces, even if
  the interface IP's of this nodes are invisible.

TC message:

- a TC message MUST contain the router-ID of it's OLSR node as the
  originator-IP of the message
- a TC message MUST contain the originator-IPs of it's advertised
  neighbor set.

Information Bases:
==================

Some of the OLSR information bases that they store the originator-IP
instead of the interface IP. The only exception are data for 1-Hop
neighbors which will be stored including both IPs.

MPR selection
=============
(I'm referring to appendix B.1. in OLSRv2 page 56)

N(I):
  It's easy to see that N(I) can be calculated from the received Hellos of
  1-Hop neighbors. Each OLSR node knowns the originator-IP and the interface
  IP of it's neighbors.

N2(I):
  The union of all originator-IPs received by Hello messages of members
  of N(I)

Connected to I via Y:
  same as in OLSRv2 draft 08

D(Y,I):
  same as in OLSRv2 draft 08

R(Y,I):
  same as in OLSRv2 draft 08

Routing Metrics with link quality
=================================
(this applies to OLSR networks sending routing metric data as ETX through
the whole topology of the OLSR network)

If two OLSR nodes have multiple links between each other just the highest
link quality will be included into the TC message. Special routing metrics
like MIC might need additional data in the TC entries.

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: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing. 
Joachim Ender (Stellv.)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 10:31:21 +0100

> forwarding set.

You need
(a) All possible IP addresses that may be used as sending addresses
    of IP datagrams that include e.g. TC messages.
(b) Per interface knowledge of which neighbours are reachable, in
    order that you can determine MPRs (for flooding) per interface
    (and then form a union of those sets).
(c) Routable addresses of neighbours in order to advertise them in
    TC messages in order that nodes which are not selected as MPRs
    don't send messages (such as OLSR MID messages) unnecessarily.
(d) To handle cases where there may be multiple links, with different
    characteristics, between the same two nodes.

I do not believe any of these alternative proposals handles all of
these issues (and others I haven't listed).

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 12:38:06 +0200

> You need
I will compare this list to my recent proposal...

>     of IP datagrams that include e.g. TC messages.
We are using only the originator IPs for src/dst of unicast messages/routes.
Only OLSR broadcast have the interface IP as it's source.

So nodes 2 hop away don't need to know about the interface IPs.

>     (and then form a union of those sets).
You can read this from the hello packages, all neigbours with LINK_STATUS are 
reachable through "this" interface. No need to send the interface IP of each 
neighbour.

>     don't send messages (such as OLSR MID messages) unnecessarily.
That will be the originator-IPs in my suggestion. Interface IPs will only be 
reachable from one hop distance.

>     characteristics, between the same two nodes.
This one is more interesting.

In my oppinion there can be only one link between two OLSR nodes for each 
interface of a receiving node. If this is true the LINK_STATUS/OTHER_NEIGHB 
tlvs will help to set the status of multiple links. The LINK_STATUS will tell 
you if the link through THIS interface is symmetric/heared/lost, the 
OTHER_NEIGHB will tell you if there is a symmetric link through another 
interface.

> these issues (and others I haven't listed).
I think my proposal match all four points you raised.

Henning Rogge

Diplom Informatiker Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 11:47:48 +0100

> Only OLSR broadcast have the interface IP as it's source.

And those are exactly how TC messages are sent, and one reason we need
to know all interface addresses.

> I think my proposal match all four points you raised.

I think at the least it misses the point I note above.

And that list of four is not exhaustive, it's just the points that
I pulled together out of where I've immediately seen proposals fail.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 12:58:37 +0200

> to know all interface addresses.
Yes, and each OLSR nodes know this interface IPs from the Hellos of the 
sending node (TCs from non-symmetric neighbours are dropped).

> I think at the least it misses the point I note above.
I think you forgot about the interface-ip/originator-ip pair each nodes get 
through the Hello messages of it's neighbours.

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 12:03:24 +0100

Only if (but I'm not saying this is a sufficient condition,
only that it's a necessary one) we can guarantee that there's
only one such address that is always used for all IP datagrams
sent on an interface.

-- 
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: Henning Rogge [mailto:[email-masked]] 
Sent: 06 April 2009 11:59
To: Dearlove, Christopher (UK)
Cc: Thomas Heide Clausen; [email-masked]
Subject: Re: [manet] OLSRv2 - RouterID

Henning

---

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 13:07:28 +0200

> only one such address that is always used for all IP datagrams
If there are multiple interface IPs they can be all included in the Hello 
message marked with LOCAL_IF(THIS_IF). Of course you can only skip it if there 
is only one interface IP and it's used in all broadcast datagrams sent from 
this interface.

But they still don't need to be known more than one hop away.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 12:36:23 +0100

> message marked with LOCAL_IF(THIS_IF).

Now you're including IP addresses and interface IDs
in HELLO messages, Not good.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 13:44:16 +0200

Am Monday 06 April 2009 13:36:23 schrieb Dearlove, Christopher (UK):
> > If there are multiple interface IPs they can be all included in the
> in HELLO messages

interface IDs = router-id = originator-IP ?

From my first email today:

So yes, the Hello messages contain both the public/netwide IP of the router 
(the originator-ip), the (optional) the linklocal/interface IPs of the router 
and the public IPs of it's neighbors.

Should be pretty straight forward because Hellos are TTL 1 messages, so 
linklocal IPs ARE routable IPs in this scope.

> , Not good.

Thats similar how it's done in NHDP now. But you can skip the interface IP if 
this interface has only one and it is contained in the source of the ip-
datagram.

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 12:51:52 +0100

> Thats similar how it's done in NHDP now.

No. Right now the addresses in NHDP within OLSRv2 do three jobs
- interface identification for two hop set formation, knowledge
of possible TC sending address and addresses to route to. In the
simplest cases that gets efficiency because even if interface IDs
could be smaller than addresses, you need the addresses anyway
(and they may be compressed). The place you may lose efficiency
is in some unnecessary inclusion in TC messages, but that can be
addressed with permission to exclude/aggregate. (And we have to
revise OLSRv2 anyway, for metrics, so that's not a significant
deal.)

---

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 14:11:11 +0200

Am Monday 06 April 2009 13:51:52 schrieb Dearlove, Christopher (UK):
> (and they may be compressed).
Yes, in the trivial case my suggestion would always include the originator-IP 
into the message while NHDP could skip it.

> The place you may lose efficiency
In my experience there are a LOT more TCs in most OLSR networks than Hellos, 
especially in large networks.

So the current draft will be a little bit more efficient in Hellos because my 
suggestion have to include the originator-IP into it, but it will be as 
efficient as the current draft for "single interface" TCs and more efficient 
for "multi-interface" TCs.

So (if we ignore the whole efficiency stuff) I managed to convinced you that 
my proposal does work and sattisfy the requirements for correct MPR selection?

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 13:31:23 +0100

> for "multi-interface" TCs.

No, I don't believe that is the case either. TCs need to include
all routable IP addresses, however you do it. We can give permission
to drop the unneeded ones without introducing router IDs etc. You
can't just include router IDs in TC messages without reintroducing
something like a MID message. And in OLSRv1, if all nodes have
multiple addresses you send more MID messages than TC messages.

> my proposal does work and sattisfy the requirements for correct MPR
selection?

No. I haven't said that anywhere, in fact I've carefully pointed
out to the contrary in just about every posting (that although the
four points I made are important, they aren't all). And there are
several of other points (such as multiple link relationships) that
I haven't followed up on disagreement.

But, I will note that even today's proposal you've had to modify.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 14:36:02 +0200

Agreed with approach, it is in line with mine.
Inline some additional comments.

Teco.

|Van: |Henning Rogge
|
|I had some time to look at the MPR calculation in OLSRv2 and I'm still
|not
|convinced that the interface IPs are necessary to calculate routing and
|forwarding set. So I try to explain our (Markus Kittenberg from Vienna
|and
|me) concept a little bit more.
|
|Even if it's too late to include this into the main OLSRv2 RFCs 

Maybe it is late, but not too late. There is no OLSRv2 RFC yet.

| I will
|continue to work on the concept to see if it can be done correctly
|because
|I think it's a good idea to allow an easier use of linklocal addresses
|and
|handling of dynamic interfaces.
|
|The router-id of a node should be a FIXED IP address which does not
|change.
|
|The base of the concept is that there should be no change in packet
|format,
|just a change what kind of IP will be written into Hello/TC messages.

Yes, but we could decide to reduce complexity of the messages, if we want
to.

|OLSRv2/NHDP messages changes
|============================
|
|Hellomessages:
|
|- a Hello message MUST contain the router-ID of it's OLSR node as the
|  originator-IP of the message
|- a Hello message CAN include the interface IP of it's OLSR node as an
|  address tagged with LOCAL_IF(THIS_IF). The address can be omitted if
|  the source IP of the package contains the interface IP
|- a Hello message don't need to include other interface IP's of it's
|  OLSR node. If these IP's are included in the message they must be
|  tagged with LOCAL_IF(OTHER_IF) as described in the current draft.
|- all address IPs of 1-hop neighbors in the Hello message will be
|  originator-IPs, tagges as described in OLSRv2 10.1.1 (Page 30).
|  Especially the LINK_STATUS/OTHER_NEIGHB tlv allows to distinguish
|  between 2-hop neighbors on the same interface as the received
|  Hello message and 2-hop neighbors on other interfaces, even if
|  the interface IP's of this nodes are invisible.
|
|TC message:
|
|- a TC message MUST contain the router-ID of it's OLSR node as the
|  originator-IP of the message
|- a TC message MUST contain the originator-IPs of it's advertised
|  neighbor set.
|
|
|Information Bases:
|==================
|
|Some of the OLSR information bases that they store the originator-IP
|instead of the interface IP. The only exception are data for 1-Hop
|neighbors which will be stored including both IPs.

Or another identifier for the interface, e.g. ifIndex.
Note that LLs for VLANs typically have the same IPv6 LL address, because
they share the same MAC address.
The interface ID is local only, it is not sent to other nodes.

|MPR selection
|=============
|(I'm referring to appendix B.1. in OLSRv2 page 56)
|
|N(I):
|  It's easy to see that N(I) can be calculated from the received Hellos
|of
|  1-Hop neighbors. Each OLSR node knowns the originator-IP and the
|interface
|  IP of it's neighbors.
|
|N2(I):
|  The union of all originator-IPs received by Hello messages of members
|  of N(I)
|
|Connected to I via Y:
|  same as in OLSRv2 draft 08
|
|D(Y,I):
|  same as in OLSRv2 draft 08
|
|R(Y,I):
|  same as in OLSRv2 draft 08
|
|
|Routing Metrics with link quality
|=================================
|(this applies to OLSR networks sending routing metric data as ETX
|through
|the whole topology of the OLSR network)
|
|If two OLSR nodes have multiple links between each other just the
|highest
|link quality will be included into the TC message. Special routing
|metrics
|like MIC might need additional data in the TC entries.
|
|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: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.
|Joachim Ender (Stellv.)

---

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 14:47:15 +0200

> |Information Bases:
I remember that LLs contain a 16 Bit random number, that should give the two 
VLANs the same LL ?

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 14:59:51 +0200

|> You need
|I will compare this list to my recent proposal...
|
|> (a) All possible IP addresses that may be used as sending addresses
|>     of IP datagrams that include e.g. TC messages.
|We are using only the originator IPs for src/dst of unicast
|messages/routes.
|Only OLSR broadcast have the interface IP as it's source.
|
|So nodes 2 hop away don't need to know about the interface IPs.

There is no reason not using the RouterID for other purposes.
Agreed on that all NHDP/OLSRv2 messages use RouterID as source address.

|> (b) Per interface knowledge of which neighbours are reachable, in
|>     order that you can determine MPRs (for flooding) per interface
|>     (and then form a union of those sets).
|You can read this from the hello packages, all neigbours with
|LINK_STATUS are
|reachable through "this" interface. No need to send the interface IP of
|each neighbour.

Agreed.

|> (c) Routable addresses of neighbours in order to advertise them in
|>     TC messages in order that nodes which are not selected as MPRs
|>     don't send messages (such as OLSR MID messages) unnecessarily.
|That will be the originator-IPs in my suggestion. Interface IPs will
|only be reachable from one hop distance.

Agreed.

|> (d) To handle cases where there may be multiple links, with different
|>     characteristics, between the same two nodes.
|This one is more interesting.
|
|In my opinion there can be only one link between two OLSR nodes for
|each interface of a receiving node. If this is true the
|LINK_STATUS/OTHER_NEIGHB
|tlvs will help to set the status of multiple links. The LINK_STATUS will
|tell
|you if the link through THIS interface is symmetric/heared/lost, the
|OTHER_NEIGHB will tell you if there is a symmetric link through another
|interface.

We come from min_hop Dijkstra. Multiple topology routing is the other end of
the spectrum. For what we need right now, only the link with the lowest cost
is of interest. It will do advertizing only that one.

|> I do not believe any of these alternative proposals handles all of
|> these issues (and others I haven't listed).
|I think my proposal match all four points you raised.

Agreed.

Teco.

|Henning Rogge
|
|Diplom Informatiker Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 14:06:58 +0100

> Agreed on that all NHDP/OLSRv2 messages use RouterID as source
address.

That isn't agreement. Henning pointed out that OLSR
broadcasts will use interface IP as source address,
which is correct. Using Router ID is different, and
not what will happen.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 15:06:46 +0200

Not sure what this discussion is about.
Is it L2 to L2 address mapping? This needs some words, e.g. using ip
unnumbered or proxy-arp.
If not, what is the problem?

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Henning Rogge
|Verzonden: maandag 6 april 2009 13:44
|Aan: Dearlove, Christopher (UK)
|CC: [email-masked]; Thomas Heide Clausen
|Onderwerp: Re: [manet] OLSRv2 - RouterID
|
|Am Monday 06 April 2009 13:36:23 schrieb Dearlove, Christopher (UK):
|> > If there are multiple interface IPs they can be all included in the
|> > message marked with LOCAL_IF(THIS_IF).
|>
|> Now you're including IP addresses and interface IDs
|> in HELLO messages
|
|interface IDs = router-id = originator-IP ?
|
|From my first email today:
|- a Hello message MUST contain the router-ID of it's OLSR node as the
|  originator-IP of the message
|- a Hello message CAN include the interface IP of it's OLSR node as an
|  address tagged with LOCAL_IF(THIS_IF). The address can be omitted if
|  the source IP of the package contains the interface IP
|
|So yes, the Hello messages contain both the public/netwide IP of the
|router
|(the originator-ip), the (optional) the linklocal/interface IPs of the
|router
|and the public IPs of it's neighbors.
|
|Should be pretty straight forward because Hellos are TTL 1 messages, so
|linklocal IPs ARE routable IPs in this scope.
|
|> , Not good.
|
|Thats similar how it's done in NHDP now. But you can skip the interface
|IP if
|this interface has only one and it is contained in the source of the ip-
|datagram.
|
|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: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.
|Joachim Ender (Stellv.)

---

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 15:12:30 +0200

Am Monday 06 April 2009 15:06:58 schrieb Dearlove, Christopher (UK):
> > Agreed on that all NHDP/OLSRv2 messages use RouterID as source
>
> address.
>

Yes, I'm thinking of OLSR packets as "linklocal" packages (they only travel on 
hop away to the next OLSR instance), so they should always have the linklocal 
source IP.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 15:25:03 +0200

|> |Information Bases:
|> |==================
|> |
|> |Some of the OLSR information bases that they store the originator-IP
|> |instead of the interface IP. The only exception are data for 1-Hop
|> |neighbors which will be stored including both IPs.
|>
|> Or another identifier for the interface, e.g. ifIndex.
|> Note that LLs for VLANs typically have the same IPv6 LL address,
|because
|> they share the same MAC address.
|> The interface ID is local only, it is not sent to other nodes.
|I remember that LLs contain a 16 Bit random number, that should give the
|two VLANs the same LL ?

The 16-bit is for IPv4. IPv4 LLs on routers is not used today. However, we
can think about it.

IPv6 LLs on routers are mandatory (ND, RFC4861 page 9). Often, EUI-64
interface IDs are used. Those are composed from the L2 address, and on each
VLAN on a single physical port, the L2 MAC address is re-used and thus the
IPv6 LLs are the same for each VLAN. This is no problem, as VLAN equals
link, and MAC addresses are globally unique (if you buy stuff from a
respected vendor..).

Teco.

|Henning Rogge
|

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 14:26:21 +0100

There's nothing in NHDP that makes you use linklocal
addresses. But there's nothing that stops you. Yes,
you use those link local addresses further away (in
NHDP two hops away). I will note that as far as I
could tell most of the members of the autoconf
Design Team seemed happy to use a MANET interface
address with a MANET-wide scope. (The MANET WG has
ducked every time it's been suggested to ask IANA
for a specific MANET-scoped address however.)

But, if using link local addresses, you can't stop those
link local addresses being seen two hops away. And it is
essential (in NHDP) that they are unique up to two hops
(not just one) away, as that's how symmetry advertisement
in HELLO messages works. And once they are visible, have
to be inspected, and have to be unique two hops away,
putting them in Information Bases is not adding any new
problems.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 06 April 2009 14:13
To: Dearlove, Christopher (UK)
Cc: Teco Boot; [email-masked]; Thomas Heide Clausen
Subject: Re: [manet] OLSRv2 - RouterID

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 15:38:00 +0200

|> >|Only OLSR broadcast have the interface IP as it's source.
|> >
|> > Agreed on that all NHDP/OLSRv2 messages use RouterID as source
|>
|> address.
|>
|> That isn't agreement. Henning pointed out that OLSR
|> broadcasts will use interface IP as source address,
|> which is correct. Using Router ID is different, and
|> not what will happen.
|
|Yes, I'm thinking of OLSR packets as "linklocal" packages (they only
|travel on
|hop away to the next OLSR instance), so they should always have the
|linklocal
|source IP.

OK, we can discuss this "minor detail" later.
I originally suggested usage of LLs (see Autoconf PPT last IETF).

Using the RouterID as source address eliminates sending the msg-orig-addr in
hellos. It is more in line with Thomas his "practical addressing proposal"
using unique host prefixes on MANET interfaces. It introduces the
requirement for L3 to L2 mapping (solvable).

Teco.

|
|Henning Rogge
|

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 14:44:54 +0100

> OK, we can discuss this "minor detail" later.

This is not a minor detail. These details are critical to why
NHDP is as it is, and interface IP addresses are needed.

> hellos.

msg-orig-addr is already essentially eliminated, as it is optional in
RFC 5444 and isn't used in NHDP. (It is used in OLSRv2 TC messages.)

But trying to use a router ID as a source address does not
work in general. Note that what has a source address is an
IP datagram, containing an RFC 5444 packet which is multiplexed
from multiple protocols, of which NHDP and OLSRv2 are only
examples. This is essentially a layer violation.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 14:45:04 +0100

> Can these emails be please exchanged only among the concerned persons
> rather than the whole MANET group?

Actually, no. The main purpose of this IETF MANET WG mailing list is
to hold discussions relating to the progression of the WG's documents
towards RFC status. This is an open process, and this discussion
is being held in the open to achieve this.

The MANET mailing list was, until recently a mess where these
things it is meant for didn't happen here, and what was here
was a whole lot of off-topic discussion. (General discussion
of MANETs is not the purpose of this group, except in that it
progresses the WG documents and related matters, and WG
administration and so on.)

Fortunately, or rather due to an initiative by Ian [and my
apologies to the person who did (does?) a lot of the discouraging
of off-topic posting, that I can't recall your name to say thank
you] this list now does cover on topic things, and this discussion
is exactly that. Actually at least one side-thread has gone private,
where it has gone onto another topic. But the main subject is what
this list is for.

---

From: Henning Rogge <[email-masked]>
Date: Mon, 6 Apr 2009 15:45:36 +0200

> for a specific MANET-scoped address however.)
I can imagine that would be difficult... ;)

> putting them in Information Bases is not adding any new
The problem with OLSR (or wireless links) are the overlapping and non-disjoint 
broadcast domains, so yes the term link-local might be a little bit dangerous 
there.

> Using the RouterID as source address eliminates sending the msg-orig-addr
> in hellos. It is more in line with Thomas his "practical addressing
> proposal" using unique host prefixes on MANET interfaces. It introduces the

If you use the src-ip to transmit the router ID then you must include the 
interface IP in the message to define the "next hop" for your routing entries 
(which are done with linklocal IPs in most IPv6 routers). So I'm not sure this 
would safe much.

--------------

Okay, let's see if we can get back to something more "productive". I will 
continue to work (mostly coding it for OLSRv1 at the moment) on the 
"originator-IP" idea, but maybe we can all agree to relax some sentences in 
the OLSRv2 draft so the TC part of my concept will fit into the draft without 
changing existing implementations. The Hello part of the new concept still 
needs some work.

Part 8.2., page 32 of the OLSRv2 draft (TC messages) says

A TC message MUST contain:
.....

"All of the router's interface addresses. These MUST be included in the 
message's Address Blocks, unless..."

I think this paragraph could be relaxed to "All of the router's globaly 
routable IPs" or something like this. If I don't plan any routes to an 
interface IP, there is no reason to put it into the header of the TC.

A few lines later it says:

"If the TC message is complete, all addresses in the Advertised Address Set 
and..."

This section points to section 6.3.1., page 19 (Advertised Neighbor Set):

"A router's Advertised Neighbor Set contains interface addresses of symmetric 
1-hop neighbors which are to be advertised through TC messages. ..."

Maybe this one could be relaxed a little bit too so it's not necessary to put 
interface IPs in there but a globally routable IP of the neighbor node.

This way an OLSR agent can decide to use originator-IPs or just drop double 
link information from the AN set.

What do you think ?

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 15:51:43 +0200

|There's nothing in NHDP that makes you use linklocal
|addresses. But there's nothing that stops you. Yes,
|you use those link local addresses further away (in
|NHDP two hops away).

LLs could be used as identifier, as an extension to link local address for
"next hop routing". But only if this is applicable. We better use a well
defined identifier for it, such as RouterID.

| I will note that as far as I
|could tell most of the members of the autoconf
|Design Team seemed happy to use a MANET interface
|address with a MANET-wide scope.

No answers yet on my question what to do with IPv6 LLs. They are mandatory.
The current NHDP / OLSRv2 text locks out usage of IPv6. For sure, this point
will be raised in a NHDP / OLSRv2 WGLC and follow-up.

Small text changes fix this problem (ALL interface addresses, but NOT the
LLs..... or another concept using RouterID).

| (The MANET WG has
|ducked every time it's been suggested to ask IANA
|for a specific MANET-scoped address however.)
|
|But, if using link local addresses, you can't stop those
|link local addresses being seen two hops away. And it is
|essential (in NHDP) that they are unique up to two hops
|(not just one) away, 

Depending on movement, they MUST be unique in a MANET segment, that could be
10 hops away, or even 255...

If LLs are used as source address, and NOT as RouterID / InterfaceID or
whatever they are NOT seen further than 1 hop away.

|as that's how symmetry advertisement
|in HELLO messages works. And once they are visible, have
|to be inspected, and have to be unique two hops away,
|putting them in Information Bases is not adding any new
|problems.

The "problem" is that LLs are unique within a "segment". A router may use
the same LL address on multiple interfaces.

Teco.

|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: Henning Rogge [mailto:[email-masked]]
|Sent: 06 April 2009 14:13
|To: Dearlove, Christopher (UK)
|Cc: Teco Boot; [email-masked]; Thomas Heide Clausen
|Subject: Re: [manet] OLSRv2 - RouterID
|
|Am Monday 06 April 2009 15:06:58 schrieb Dearlove, Christopher (UK):
|> >|Only OLSR broadcast have the interface IP as it's source.
|> >
|> > Agreed on that all NHDP/OLSRv2 messages use RouterID as source
|>
|> address.
|>
|> That isn't agreement. Henning pointed out that OLSR
|> broadcasts will use interface IP as source address,
|> which is correct. Using Router ID is different, and
|> not what will happen.
|
|Yes, I'm thinking of OLSR packets as "linklocal" packages (they only
|travel on
|hop away to the next OLSR instance), so they should always have the
|linklocal
|source IP.
|
|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: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.
|Joachim Ender (Stellv.)
|
|
|********************************************************************
|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, 6 Apr 2009 14:58:54 +0100

> maybe we can all agree to relax some sentences in 
> changing existing implementations.

I think we are on the same page here.

> interface IP, there is no reason to put it into the header of the TC.

This isn't quite the solution, as it fails to handle the case of a node
that is routing only, i.e. only acts as a relay, has no routable
addresses, but still needs to appear in the Topology Graph. But that
can be squared, it's just a question of details.

Incidentally in this case (or any other) it's no harm if the address
ends up in the Routing Set, it just shouldn't be copied to the IP
routing table. That indicates another piece of text revision that would
be part of this.

And there is a second possible saving, relating to aggregation (possibly
more relevant to the non-LL address approach) that the authors have
bounced off each other but are still thinking about.

> interface IPs in there but a globally routable IP of the neighbor
node.

These two paragraphs should essentially be saying the same thing
from different perspectives. So if one changes, so does the other.
(And I don't rule out there being any others as well.)

I would be happy to proceed with NHDP as-is and undertake to make a
revision along these lines in OLSRv2.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 15:03:14 +0100

> A router may use

This I think is the one sticking point, it's not going
to work, as differentiating MANET interfaces is essential.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 16:06:42 +0200

|-----Oorspronkelijk bericht-----
|Van: Henning Rogge [mailto:[email-masked]]
|Verzonden: maandag 6 april 2009 15:46
|Aan: Dearlove, Christopher (UK)
|CC: Teco Boot; [email-masked]; Thomas Heide Clausen
|Onderwerp: Re: [manet] OLSRv2 - RouterID
|
|Am Monday 06 April 2009 15:26:21 schrieb Dearlove, Christopher (UK):
|> There's nothing in NHDP that makes you use linklocal
|> addresses. But there's nothing that stops you. Yes,
|> you use those link local addresses further away (in
|> NHDP two hops away). I will note that as far as I
|> could tell most of the members of the autoconf
|> Design Team seemed happy to use a MANET interface
|> address with a MANET-wide scope. (The MANET WG has
|> ducked every time it's been suggested to ask IANA
|> for a specific MANET-scoped address however.)
|I can imagine that would be difficult... ;)
|
|> But, if using link local addresses, you can't stop those
|> link local addresses being seen two hops away. And it is
|> essential (in NHDP) that they are unique up to two hops
|> (not just one) away, as that's how symmetry advertisement
|> in HELLO messages works. And once they are visible, have
|> to be inspected, and have to be unique two hops away,
|> putting them in Information Bases is not adding any new
|> problems.
|The problem with OLSR (or wireless links) are the overlapping and non-
|disjoint
|broadcast domains, so yes the term link-local might be a little bit
|dangerous
|there.
|
|> |Yes, I'm thinking of OLSR packets as "linklocal" packages (they only
|> |travel on
|> |hop away to the next OLSR instance), so they should always have the
|> |linklocal
|> |source IP.
|>
|> OK, we can discuss this "minor detail" later.
|> I originally suggested usage of LLs (see Autoconf PPT last IETF).
|>
|> Using the RouterID as source address eliminates sending the msg-orig-
|addr
|> in hellos. It is more in line with Thomas his "practical addressing
|> proposal" using unique host prefixes on MANET interfaces. It
|introduces the
|> requirement for L3 to L2 mapping (solvable).
|
|If you use the src-ip to transmit the router ID then you must include
|the
|interface IP in the message to define the "next hop" for your routing
|entries
|(which are done with linklocal IPs in most IPv6 routers). So I'm not
|sure this
|would safe much.

It saves the msg-orig-addr. Interface IP is not needed, as the receiver
interface is used as placeholder (sender and receiver interfaces are on same
link. RouterID could be used for next-hop. For forwarding on the medium, the
L2 address is important (far more important, as the next hop IP address is
not stored in the forwarded packet). Therefore, the need for L3 to L2
mapping.

|
|--------------
|
|Okay, let's see if we can get back to something more "productive".

OK.
I am still interested in a reference document describing using RouterID
doesn't work. It was mentioned there was a race condition. If there is a
problem, we all know the reason for the more complex approach, with some
more overhead.

|I will
|continue to work (mostly coding it for OLSRv1 at the moment) on the
|"originator-IP" idea, but maybe we can all agree to relax some sentences
|in
|the OLSRv2 draft so the TC part of my concept will fit into the draft
|without
|changing existing implementations. The Hello part of the new concept
|still
|needs some work.
|
|Part 8.2., page 32 of the OLSRv2 draft (TC messages) says
|
|A TC message MUST contain:
|.....
|
|"All of the router's interface addresses. These MUST be included in the
|message's Address Blocks, unless..."
|
|I think this paragraph could be relaxed to "All of the router's globaly
|routable IPs" or something like this. If I don't plan any routes to an
|interface IP, there is no reason to put it into the header of the TC.

Also, if a summary prefix is advertized, more specific prefixes do not need
to be advertized.
However, topology information must be complete.

|A few lines later it says:
|
|"If the TC message is complete, all addresses in the Advertised Address
|Set
|and..."
|
|This section points to section 6.3.1., page 19 (Advertised Neighbor
|Set):
|
|"A router's Advertised Neighbor Set contains interface addresses of
|symmetric
|1-hop neighbors which are to be advertised through TC messages. ..."
|
|Maybe this one could be relaxed a little bit too so it's not necessary
|to put
|interface IPs in there but a globally routable IP of the neighbor node.
|
|This way an OLSR agent can decide to use originator-IPs or just drop
|double
|link information from the AN set.
|
|What do you think ?
|
|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: Prof. Dr. rer. nat. Maurus Tacke (komm. Vors.), Prof. Dr.-Ing.
|Joachim Ender (Stellv.)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 15:10:01 +0100

> Also, if a summary prefix is advertized, more specific prefixes do not
need

That is what I meant by address aggregation.

> However, topology information must be complete.

And that's why the "relay only" node needs a little care.
But we can give it that.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 6 Apr 2009 10:25:46 -0400

> 
> Thats similar how it's done in NHDP now. But you can skip the 
> interface IP if this interface has only one and it is 
> contained in the source of the ip- datagram.
> 

It's beginning to sound like there are some assumptions being made -- like, OLSR will *always* run on top of UDP. That's a bad idea for router vendors. It adversely effects performance, not to mention the "architectural argument" about running Layer 3 on top of Layer 4... ;-)

Regards,
Stan

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Henning Rogge
> Sent: Monday, April 06, 2009 7:44 AM
> Cc: [email-masked]; Thomas Heide Clausen
> > Now you're including IP addresses and interface IDs in 
> HELLO messages
> 
> So yes, the Hello messages contain both the public/netwide IP 
> of the router (the originator-ip), the (optional) the 
> linklocal/interface IPs of the router and the public IPs of 
> it's neighbors.
> 
> Should be pretty straight forward because Hellos are TTL 1 
> messages, so linklocal IPs ARE routable IPs in this scope.
> 
> > , Not good.
> 
> Thats similar how it's done in NHDP now. But you can skip the 
> interface IP if this interface has only one and it is 
> contained in the source of the ip- datagram.
> 
> Henning Rogge
> 
> Angewandte Naturwissenschaften e. V. (FGAN) Neuenahrer Str. 
> 20, 53343 Wachtberg, Germany

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 15:38:08 +0100

There's an assumption that OLSR runs on top of IP, but
not necessarily using UDP. RFC 5498 gives both options,
and currently NHDP/OLSRv2 says do either. There was a 
suggestion made in San Francisco to pick one, which
would have to be the same for all MANET protocols using
RFC 5444 multiplexing, but this has not yet been decided.

Actually of course you can run the algorithm on top of
anything else that has the necessary properties. But it
seemed appropriate in the IETF to make this IP. However
RFC 5444 allows any size address (1 to 32 octets). If
time ever permits, some sort of "where else you can use
this" may be appropriate.

(What properties? Well, apart from the getting the packet
where it should go, using a local broadcast, it also
needs a source address of the same type. Actually in NHDP
you can manage without that - there's an "if" in the quoted
paragraph below - but in OLSRv2 you can't.)

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 06 April 2009 15:26
To: Henning Rogge; Dearlove, Christopher (UK)
Cc: [email-masked]; Thomas Heide Clausen
Subject: RE: [manet] OLSRv2 - RouterID

               *** WARNING ***

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

Regards,
Stan