Subject: [manet] OLSRv2 - RouterID

From: "Teco Boot" <[email-masked]>
Date: Thu, 2 Apr 2009 14:25:24 +0200

Dear OLSRv2 design team,

I have a question on:

> OLSRv2 does not make any assumption about router addresses, other
> than that each router is assumed to have at least one unique and
> routable IP address for each interface that it has which participates
> in the MANET.

Why is this? It excludes usage of link local addresses. I do not see a hard
reason not using LLs, as long as they are unique in the MANET Routing
Domain. And LLs are not routable.

More important: IPv6 LL addresses are mandatory for IPv6 router interfaces
(RFC4861).

Currently, LLs that are not MANET-wide unique may not be used by NHDP /
OLSRv2. Why isn't there a router identifier? OLSRv1 had this:

> main address
>   The main address of a node, which will be used in OLSR control
>   traffic as the "originator address" of all messages emitted by
>   this node.  It is the address of one of the OLSR interfaces of
>   the node.

This is removed in OLSRv2. Now it is harder to recognize routers because
there is no single router identifier anymore. Interfaces may go up and down
or temporally addresses may be used, and as a result the identity changes
over time. 

A scenario that introduces problems:
Assume a router with multiple layer-2 Ethernet to 802.11 bridges attached,
using VLANs. IPv6 is used, with "default" EUI-64 addressing.
The MAC address of a VLAN logical interfaces is the same for all on the same
physical interface, and thus the EUI-64 interface-IDs are the same.
Uniqueness on each link is OK, assume the MAC address for the physical
interface is globally unique.

Currently, NHDP does not send the msg-orig-addr but instead sends sets with
**all** addresses, for itself and for all neighbors. Moreover, addresses may
be identifiers **or** locators. Locators change when an MANET Router moves
within the topology (result of definition of locator, as used in IRTF RRG).

For SPF calculation, only identifiers for the nodes and their links are
needed. A straightforward approach would be unique router identifiers within
the routing domain and unique interface identifiers within the scope of each
router. For the latter, ifIndex could be used and single octet provides
namespace for 256 interfaces using continuous numbering. One may think of
extended numbering. A link is identified by a 4-tuple of RouterID and a
interface identifier, for itself and the neighbor. I don't think the
interface identifiers are needed in the NHDP and OLSRv2 messages.

I think the problems can be circumvented by using the following information
bases, for NHDP and OLSRv2:
(to be verified)
		
Local Information Base		
	Local Interface Set	
		ifIndex              # added
		I_local_iface_addr   # 
		I_manet
	Removed Interface Address Set	
		ifIndex              # added
		IR_local_iface_addr
		IR_time
	Originator Set	    # not required if orig_addr is stable
		O_orig_addr      
		O_time
	Local Attached Network Set	
		AL_net_addr
		AL_dist
		
Interface Information Bases		
	Link Set	
		ifIndex         # added
		L_orig_addr     #
		L_ifIndex       # needed ??
		L_HEARD_time
		L_SYM_time
		L_quality
		L_pending
		L_lost
		L_time
	2-Hop Set	
		ifIndex         # added
		N2_orig_addr    #
		L_ifIndex       # needed ??
		N2_2H_orig_addr
		N2_time
		
Neighbor Information Base 		
	Neighbor Set 	
		N_orig_addr        #
		N_symmetric
		N_willingness
		N_mpr
		N_mpr_selector
	Lost Neighbor Set
		NL_orig_addr       #
		NL_time

Topology Information Base		
	Advertised Neighbor Set 	
		A_orig_addr        #
	Advertising Remote Router Set	
		AR_orig_addr       #
		AR_seq_number
		AR_time
	Topology Set 	
		T_dest_orig_addr   #
		T_orig_addr        
		T_seq_number
		T_time
	Attached Network Set	
		AN_net_addr
		AN_orig_addr
		AN_dist
		AN_seq_number
		AN_time
	Routing Set	
		R_dest_addr
		R_next_iface_addr
		R_dist
		R_local_ifIndex    #
		
Processing and Forwarding Information Base		
	Received Set	
		RX_type
		RX_orig_addr
		RX_seq_number
		RX_time
	Processed Set	
		P_type
		P_orig_addr
		P_seq_number
		P_time
	Forwarded Set	
		F_type
		F_orig_addr
		F_seq_number
		F_time
	Relay Set 	
		RY_neighbor_orig_addr    #

As a result, the NHDP hello messages must contain msg-orig-addr (may be
suppressed if IP header source address is msg-orig-addr). This may be a
small increase of the size of the packets. But other messages would be
largely reduced in size, as not ALL addresses are advertized anymore. Each
router identifier (orig-addr) represents all addresses of all interfaces of
the router. 

Also unidirectional links become available for routing, as long as there is
a pair of unidirectional links (in opposite directions). This is desirable
qualitative properties #7 of MANET routing protocols (RFC2501).

I discussed this with Thomas Clausen in SF last week. His first response was
that I was somewhat late with this enhancement. I have to agree. But I think
it is worth to consider. Better late than never.

Teco.

---

From: Henning Rogge <[email-masked]>
Date: Thu, 2 Apr 2009 14:44:28 +0200

> or temporally addresses may be used, and as a result the identity changes
I have to agree to this (and was in the process writing a similar mail).

It's not necessary for OLSR to use interface IPs in TCs and Hellos, a single 
"Originator IP" for the router instance would be enough to calculate the 
route.

> The MAC address of a VLAN logical interfaces is the same for all on the
> same physical interface, and thus the EUI-64 interface-IDs are the same.
> **all** addresses, for itself and for all neighbors. Moreover, addresses
> may be identifiers **or** locators. Locators change when an MANET Router
> moves within the topology (result of definition of locator, as used in IRTF
> RRG).
>
> needed. A straightforward approach would be unique router identifiers
> within the routing domain and unique interface identifiers within the scope
> of each router. For the latter, ifIndex could be used and single octet
> provides namespace for 256 interfaces using continuous numbering. One may
> think of extended numbering. A link is identified by a 4-tuple of RouterID
> and a interface identifier, for itself and the neighbor. I don't think the

I don't think using an interface index would be a good idea, because it's OS 
dependent how this ids are handled (and what happens when an interface is 
down). We used a similar idea in the OLSR.org implementation and had/have 
lot's of trouble when interfaces are down for a moment (because you cannot 
convert the interface index into the interface data during this time !)

I think it would be easier if each NHDP link has stored a "next hop" IP in 
addition to the originator IP of the other side of the link. This way the 
local node can forward packages to the interface IP of the other side without 
advertising this IPs at all.

The topology database does not need to know about the interfaces between 
distant nodes at all, only that there is a connection between the nodes. This 
way we could reduce the amount of change OLSRv2 and NHDP need.

> qualitative properties #7 of MANET routing protocols (RFC2501).
Using unidirectional links is not a good idea in my oppinion, especially on 
wireless links. Some layer 2 technologies (like 802.11) cannot send unicast 
traffic on unidirectional links.

My proposal would be to allow NHDP and OLSRv2 to send an unique router-id (ip 
address) instead of interface IPs. The only difficulty in this approach is 
that a node receiving a NHDP package would have to discover the interface IP 
of the originator of this package. This could be done either done by using 
information from lower protocol layers (IP source address of the incoming 
broadcast) or the interface IP would have to be included into the NHDP 
package.

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: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 2 Apr 2009 08:54:17 -0400

Teco, 

One question inline. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Teco Boot
> Sent: Thursday, April 02, 2009 8:25 AM
> To: 'manet'
> Subject: [manet] OLSRv2 - RouterID
> 
> Dear OLSRv2 design team,
> 
> I have a question on:
> 
> > OLSRv2 does not make any assumption about router addresses, 
> other than 
> > that each router is assumed to have at least one unique and 
> routable 
> > IP address for each interface that it has which participates in the 
> > MANET.
> 
> Why is this? It excludes usage of link local addresses. I do 
> not see a hard reason not using LLs, as long as they are 
> unique in the MANET Routing Domain. And LLs are not routable.
> 
> More important: IPv6 LL addresses are mandatory for IPv6 
> router interfaces (RFC4861).
> 
> Currently, LLs that are not MANET-wide unique may not be used 
> by NHDP / OLSRv2. Why isn't there a router identifier? OLSRv1 
> had this:
> 
> > main address
> This is removed in OLSRv2. Now it is harder to recognize 
> routers because there is no single router identifier anymore. 
> Interfaces may go up and down or temporally addresses may be 
> used, and as a result the identity changes over time. 
> 
> Assume a router with multiple layer-2 Ethernet to 802.11 
> bridges attached, using VLANs. IPv6 is used, with "default" 
> EUI-64 addressing.
> The MAC address of a VLAN logical interfaces is the same for 
> all on the same physical interface, and thus the EUI-64 
> interface-IDs are the same.
> Uniqueness on each link is OK, assume the MAC address for the 
> physical interface is globally unique.
> 
> **all** addresses, for itself and for all neighbors. 
> Moreover, addresses may be identifiers **or** locators. 
> Locators change when an MANET Router moves within the 
> topology (result of definition of locator, as used in IRTF RRG).
> 
> For SPF calculation, only identifiers for the nodes and their 
> links are needed. A straightforward approach would be unique 
> router identifiers within the routing domain and unique 
> interface identifiers within the scope of each router. For 
> the latter, ifIndex could be used and single octet provides 
> namespace for 256 interfaces using continuous numbering. One 
> may think of extended numbering. A link is identified by a 
> 4-tuple of RouterID and a interface identifier, for itself 
> and the neighbor. I don't think the interface identifiers are 
> needed in the NHDP and OLSRv2 messages.
> 

Forgive me if this is a silly question, but how would you use a 4-tuple
on a multi-access link like an Ethernet? replicate the local information
for each OLSR neighbor?

Regards,
Stan

> I think the problems can be circumvented by using the 
> following information bases, for NHDP and OLSRv2:
> (to be verified)
> 		
> Local Information Base		
> 	Local Interface Set	
> 		ifIndex              # added
> 		I_local_iface_addr   # 
> 		I_manet
> As a result, the NHDP hello messages must contain 
> msg-orig-addr (may be suppressed if IP header source address 
> is msg-orig-addr). This may be a small increase of the size 
> of the packets. But other messages would be largely reduced 
> in size, as not ALL addresses are advertized anymore. Each 
> router identifier (orig-addr) represents all addresses of all 
> interfaces of the router. 
> 
> Also unidirectional links become available for routing, as 
> long as there is a pair of unidirectional links (in opposite 
> directions). This is desirable qualitative properties #7 of 
> MANET routing protocols (RFC2501).
> 
> I discussed this with Thomas Clausen in SF last week. His 
> first response was that I was somewhat late with this 
> enhancement. I have to agree. But I think it is worth to 
> consider. Better late than never.
> 
> 
> Teco. 
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 2 Apr 2009 13:59:00 +0100

> "Originator IP" for the router instance would be enough to calculate
the 

I'm afraid that is not true. In HELLOs at least you need interface
addresses
in order for per interface MPR selection to work correctly. And the
current
design of TC messages is part of how we abolished MID messages from OLSR
- and that's a major win in efficiency because MID message forced all
multiple
addressed nodes to transmit them, while TC messages are only required by
MPRs.
In addition coordintion between differently timed MID and TC messages is
not
at all nice, while the current processing is simpler in this regard.

I believe these suggestions are failing to appreciate these details. And
the
serious revision that would be required is exactly what is not what we
need
at this time. Looking back over drafts, this has been stable in this
form since
2006.

********************************************************************
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: Thu, 2 Apr 2009 15:10:53 +0200

Am Thursday 02 April 2009 14:59:00 schrieb Dearlove, Christopher (UK):
> > It's not necessary for OLSR to use interface IPs in TCs and Hellos, a
> > single "Originator IP" for the router instance would be enough to
> > calculate
> > the route.
>
> addresses in order for per interface MPR selection to work correctly.
I'm not sure about this.

If each OLSR node does know the interface IPs of it's one hop neighbors this 
should be enough to calculate the MPR set, because the LOCAL_IF tlv tells it 
which of the two-hop-neighbors are connected to this node through the same 
interface (value THIS_IF).

> And the current design of TC messages is part of how we abolished MID
> messages from OLSR
If each OLSR node does only have one routable IP for "long range" (more than 
2-hop) traffic, MIDs are not necessary.

> multiple addressed nodes to transmit them, while TC messages are only
> required by MPRs.
MIDs are necessary to solve map the multiple identities of OLSR interface IPs 
to a single OLSR node. Without multiple IPs for the same router in TCs, there 
is no need for MIDs too.

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 2 Apr 2009 15:11:25 +0200

Inline.

|-----Oorspronkelijk bericht-----
|Van: Henning Rogge [mailto:[email-masked]]
|Verzonden: donderdag 2 april 2009 14:44
|Aan: [email-masked]
|CC: Teco Boot
|Onderwerp: Re: [manet] OLSRv2 - RouterID
|
|Am Thursday 02 April 2009 14:25:24 schrieb Teco Boot:
|> Dear OLSRv2 design team,
|>
|> I have a question on:
|> > OLSRv2 does not make any assumption about router addresses, other
|> > than that each router is assumed to have at least one unique and
|> > routable IP address for each interface that it has which
|participates
|> > in the MANET.
|>
|> Why is this? It excludes usage of link local addresses. I do not see a
|hard
|> reason not using LLs, as long as they are unique in the MANET Routing
|> Domain. And LLs are not routable.
|>
|> More important: IPv6 LL addresses are mandatory for IPv6 router
|interfaces
|> (RFC4861).
|>
|> Currently, LLs that are not MANET-wide unique may not be used by NHDP
|/
|>
|> OLSRv2. Why isn't there a router identifier? OLSRv1 had this:
|> > main address
|> >   The main address of a node, which will be used in OLSR control
|> >   traffic as the "originator address" of all messages emitted by
|> >   this node.  It is the address of one of the OLSR interfaces of
|> >   the node.
|>
|> This is removed in OLSRv2. Now it is harder to recognize routers
|because
|> there is no single router identifier anymore. Interfaces may go up and
|down
|> or temporally addresses may be used, and as a result the identity
|changes
|> over time.
|I have to agree to this (and was in the process writing a similar mail).
|
|It's not necessary for OLSR to use interface IPs in TCs and Hellos, a
|single
|"Originator IP" for the router instance would be enough to calculate the
|route.

This is exactly what I propose !!

|> A scenario that introduces problems:
|> Assume a router with multiple layer-2 Ethernet to 802.11 bridges
|attached,
|> using VLANs. IPv6 is used, with "default" EUI-64 addressing.
|> The MAC address of a VLAN logical interfaces is the same for all on
|the
|> same physical interface, and thus the EUI-64 interface-IDs are the
|same.
|> Uniqueness on each link is OK, assume the MAC address for the physical
|> interface is globally unique.
|>
|> Currently, NHDP does not send the msg-orig-addr but instead sends sets
|with
|> **all** addresses, for itself and for all neighbors. Moreover,
|addresses
|> may be identifiers **or** locators. Locators change when an MANET
|Router
|> moves within the topology (result of definition of locator, as used in
|IRTF
|> RRG).
|>
|> For SPF calculation, only identifiers for the nodes and their links
|are
|> needed. A straightforward approach would be unique router identifiers
|> within the routing domain and unique interface identifiers within the
|scope
|> of each router. For the latter, ifIndex could be used and single octet
|> provides namespace for 256 interfaces using continuous numbering. One
|may
|> think of extended numbering. A link is identified by a 4-tuple of
|RouterID
|> and a interface identifier, for itself and the neighbor. I don't think
|the
|> interface identifiers are needed in the NHDP and OLSRv2 messages.
|>
|> I think the problems can be circumvented by using the following
|information
|> bases, for NHDP and OLSRv2:
|> (to be verified)
|>
|> Local Information Base
|> 	Local Interface Set
|> 		ifIndex              # added
|> 		I_local_iface_addr   #
|> 		I_manet
|> 	Removed Interface Address Set
|> 		ifIndex              # added
|> 		IR_local_iface_addr
|> 		IR_time
|> 	Originator Set	    # not required if orig_addr is stable
|> 		O_orig_addr
|> 		O_time
|> 	Local Attached Network Set
|> 		AL_net_addr
|> 		AL_dist
|>
|> Interface Information Bases
|> 	Link Set
|> 		ifIndex         # added
|> 		L_orig_addr     #
|> 		L_ifIndex       # needed ??
|> 		L_HEARD_time
|> 		L_SYM_time
|> 		L_quality
|> 		L_pending
|> 		L_lost
|> 		L_time
|> 	2-Hop Set
|> 		ifIndex         # added
|> 		N2_orig_addr    #
|> 		L_ifIndex       # needed ??
|> 		N2_2H_orig_addr
|> 		N2_time
|>
|> Neighbor Information Base
|> 	Neighbor Set
|> 		N_orig_addr        #
|> 		N_symmetric
|> 		N_willingness
|> 		N_mpr
|> 		N_mpr_selector
|> 	Lost Neighbor Set
|> 		NL_orig_addr       #
|> 		NL_time
|>
|> Topology Information Base
|> 	Advertised Neighbor Set
|> 		A_orig_addr        #
|> 	Advertising Remote Router Set
|> 		AR_orig_addr       #
|> 		AR_seq_number
|> 		AR_time
|> 	Topology Set
|> 		T_dest_orig_addr   #
|> 		T_orig_addr
|> 		T_seq_number
|> 		T_time
|> 	Attached Network Set
|> 		AN_net_addr
|> 		AN_orig_addr
|> 		AN_dist
|> 		AN_seq_number
|> 		AN_time
|> 	Routing Set
|> 		R_dest_addr
|> 		R_next_iface_addr
|> 		R_dist
|> 		R_local_ifIndex    #
|>
|> Processing and Forwarding Information Base
|> 	Received Set
|> 		RX_type
|> 		RX_orig_addr
|> 		RX_seq_number
|> 		RX_time
|> 	Processed Set
|> 		P_type
|> 		P_orig_addr
|> 		P_seq_number
|> 		P_time
|> 	Forwarded Set
|> 		F_type
|> 		F_orig_addr
|> 		F_seq_number
|> 		F_time
|> 	Relay Set
|> 		RY_neighbor_orig_addr    #
|>
|
|I don't think using an interface index would be a good idea, because
|it's OS
|dependent how this ids are handled (and what happens when an interface
|is
|down). 

ifIndex is a SNMP / MIP id, and I think management MIBsis required for a std
track protocol.
In short, ifIndex is as stable as possible.

|We used a similar idea in the OLSR.org implementation and
|had/have
|lot's of trouble when interfaces are down for a moment (because you
|cannot
|convert the interface index into the interface data during this time !)

ifIndex should not dependent of addresses. It is simply a number.

|I think it would be easier if each NHDP link has stored a "next hop" IP
|in
|addition to the originator IP of the other side of the link. This way
|the
|local node can forward packages to the interface IP of the other side
|without
|advertising this IPs at all.

The "next hop" would be the IP header address.

|The topology database does not need to know about the interfaces between
|distant nodes at all, only that there is a connection between the nodes.
|This
|way we could reduce the amount of change OLSRv2 and NHDP need.

Yes, this is my proposal.

Teco.

|> As a result, the NHDP hello messages must contain msg-orig-addr (may
|be
|> suppressed if IP header source address is msg-orig-addr). This may be
|a
|> small increase of the size of the packets. But other messages would be
|> largely reduced in size, as not ALL addresses are advertized anymore.
|Each
|> router identifier (orig-addr) represents all addresses of all
|interfaces of
|> the router.
|>
|> Also unidirectional links become available for routing, as long as
|there is
|> a pair of unidirectional links (in opposite directions). This is
|desirable
|> qualitative properties #7 of MANET routing protocols (RFC2501).
|Using unidirectional links is not a good idea in my oppinion, especially
|on
|wireless links. Some layer 2 technologies (like 802.11) cannot send
|unicast
|traffic on unidirectional links.
|
|My proposal would be to allow NHDP and OLSRv2 to send an unique router-
|id (ip
|address) instead of interface IPs. The only difficulty in this approach
|is
|that a node receiving a NHDP package would have to discover the
|interface IP
|of the originator of this package. This could be done either done by
|using
|information from lower protocol layers (IP source address of the
|incoming
|broadcast) or the interface IP would have to be included into the NHDP
|package.
|
|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: "Teco Boot" <[email-masked]>
Date: Thu, 2 Apr 2009 15:20:09 +0200

Inline.

|-----Oorspronkelijk bericht-----
|Van: Stan Ratliff (sratliff) [mailto:[email-masked]]
|Verzonden: donderdag 2 april 2009 14:54
|Aan: Teco Boot; manet
|Onderwerp: RE: [manet] OLSRv2 - RouterID
|
|Teco,
|
|One question inline.
|
|> -----Original Message-----
|> From: [email-masked] [mailto:[email-masked]]
|> On Behalf Of Teco Boot
|> Sent: Thursday, April 02, 2009 8:25 AM
|> To: 'manet'
|> Subject: [manet] OLSRv2 - RouterID
|>
|> Dear OLSRv2 design team,
|>
|> I have a question on:
|>
|> > OLSRv2 does not make any assumption about router addresses,
|> other than
|> > that each router is assumed to have at least one unique and
|> routable
|> > IP address for each interface that it has which participates in the
|> > MANET.
|>
|> Why is this? It excludes usage of link local addresses. I do
|> not see a hard reason not using LLs, as long as they are
|> unique in the MANET Routing Domain. And LLs are not routable.
|>
|> More important: IPv6 LL addresses are mandatory for IPv6
|> router interfaces (RFC4861).
|>
|> Currently, LLs that are not MANET-wide unique may not be used
|> by NHDP / OLSRv2. Why isn't there a router identifier? OLSRv1
|> had this:
|>
|> > main address
|> >   The main address of a node, which will be used in OLSR control
|> >   traffic as the "originator address" of all messages emitted by
|> >   this node.  It is the address of one of the OLSR interfaces of
|> >   the node.
|>
|> This is removed in OLSRv2. Now it is harder to recognize
|> routers because there is no single router identifier anymore.
|> Interfaces may go up and down or temporally addresses may be
|> used, and as a result the identity changes over time.
|>
|> A scenario that introduces problems:
|> Assume a router with multiple layer-2 Ethernet to 802.11
|> bridges attached, using VLANs. IPv6 is used, with "default"
|> EUI-64 addressing.
|> The MAC address of a VLAN logical interfaces is the same for
|> all on the same physical interface, and thus the EUI-64
|> interface-IDs are the same.
|> Uniqueness on each link is OK, assume the MAC address for the
|> physical interface is globally unique.
|>
|> Currently, NHDP does not send the msg-orig-addr but instead
|> sends sets with
|> **all** addresses, for itself and for all neighbors.
|> Moreover, addresses may be identifiers **or** locators.
|> Locators change when an MANET Router moves within the
|> topology (result of definition of locator, as used in IRTF RRG).
|>
|> For SPF calculation, only identifiers for the nodes and their
|> links are needed. A straightforward approach would be unique
|> router identifiers within the routing domain and unique
|> interface identifiers within the scope of each router. For
|> the latter, ifIndex could be used and single octet provides
|> namespace for 256 interfaces using continuous numbering. One
|> may think of extended numbering. A link is identified by a
|> 4-tuple of RouterID and a interface identifier, for itself
|> and the neighbor. I don't think the interface identifiers are
|> needed in the NHDP and OLSRv2 messages.
|>
|
|Forgive me if this is a silly question, but how would you use a 4-tuple
|on a multi-access link like an Ethernet? replicate the local information
|for each OLSR neighbor?

No, what I mean by link is the relation (edge) between 2 nodes (vertices).
Maybe only the 2 node IDs would be enough to identify the link. This is what
we need for hop count SPF calculations.
Maybe we need interface IDs for distinguish parallel links. Or we could
advertize just the best link.
 
Info in hello: set of neighbors.
Info in information bases, all information that is available and needed for
processing.

Teco.

|Regards,
|Stan
|
|
|> I think the problems can be circumvented by using the
|> following information bases, for NHDP and OLSRv2:
|> (to be verified)
|>
|> Local Information Base
|> 	Local Interface Set
|> 		ifIndex              # added
|> 		I_local_iface_addr   #
|> 		I_manet
|> 	Removed Interface Address Set
|> 		ifIndex              # added
|> 		IR_local_iface_addr
|> 		IR_time
|> 	Originator Set	    # not required if orig_addr is stable
|> 		O_orig_addr
|> 		O_time
|> 	Local Attached Network Set
|> 		AL_net_addr
|> 		AL_dist
|>
|> Interface Information Bases
|> 	Link Set
|> 		ifIndex         # added
|> 		L_orig_addr     #
|> 		L_ifIndex       # needed ??
|> 		L_HEARD_time
|> 		L_SYM_time
|> 		L_quality
|> 		L_pending
|> 		L_lost
|> 		L_time
|> 	2-Hop Set
|> 		ifIndex         # added
|> 		N2_orig_addr    #
|> 		L_ifIndex       # needed ??
|> 		N2_2H_orig_addr
|> 		N2_time
|>
|> Neighbor Information Base
|> 	Neighbor Set
|> 		N_orig_addr        #
|> 		N_symmetric
|> 		N_willingness
|> 		N_mpr
|> 		N_mpr_selector
|> 	Lost Neighbor Set
|> 		NL_orig_addr       #
|> 		NL_time
|>
|> Topology Information Base
|> 	Advertised Neighbor Set
|> 		A_orig_addr        #
|> 	Advertising Remote Router Set
|> 		AR_orig_addr       #
|> 		AR_seq_number
|> 		AR_time
|> 	Topology Set
|> 		T_dest_orig_addr   #
|> 		T_orig_addr
|> 		T_seq_number
|> 		T_time
|> 	Attached Network Set
|> 		AN_net_addr
|> 		AN_orig_addr
|> 		AN_dist
|> 		AN_seq_number
|> 		AN_time
|> 	Routing Set
|> 		R_dest_addr
|> 		R_next_iface_addr
|> 		R_dist
|> 		R_local_ifIndex    #
|>
|> Processing and Forwarding Information Base
|> 	Received Set
|> 		RX_type
|> 		RX_orig_addr
|> 		RX_seq_number
|> 		RX_time
|> 	Processed Set
|> 		P_type
|> 		P_orig_addr
|> 		P_seq_number
|> 		P_time
|> 	Forwarded Set
|> 		F_type
|> 		F_orig_addr
|> 		F_seq_number
|> 		F_time
|> 	Relay Set
|> 		RY_neighbor_orig_addr    #
|>
|>
|> As a result, the NHDP hello messages must contain
|> msg-orig-addr (may be suppressed if IP header source address
|> is msg-orig-addr). This may be a small increase of the size
|> of the packets. But other messages would be largely reduced
|> in size, as not ALL addresses are advertized anymore. Each
|> router identifier (orig-addr) represents all addresses of all
|> interfaces of the router.
|>
|> Also unidirectional links become available for routing, as
|> long as there is a pair of unidirectional links (in opposite
|> directions). This is desirable qualitative properties #7 of
|> MANET routing protocols (RFC2501).
|>
|> I discussed this with Thomas Clausen in SF last week. His
|> first response was that I was somewhat late with this
|> enhancement. I have to agree. But I think it is worth to
|> consider. Better late than never.
|>
|>
|> Teco.
|>
|> _______________________________________________
|> manet mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/manet
|>

---

From: "Justin Dean" <[email-masked]>
Date: Thu, 2 Apr 2009 10:03:32 -0400

I would like to jump in here as this is an issue we had lots of debate about
quite a while ago and some rational for why the current NHDP specification
does not use a routerID type of framework may appropriate at this time
before we get to far along in this discussion.  OLSRv1 had this idea but
NHDP/OLSRv2 does not and this choice was not arbitrary but stems from two
main issues.  Multiple interfaces and multiple mode operation.  The current
specification does not generate MID messages from all nodes which have
multiple interfaces.  This is not insignificant in terms of overhead because
ALL nodes which have more than one interface had to generate and flood these
message throughout the network.  NHDP HELLO messages do contain more address
information than previous OLSR HELLO messages but again this is mitigated in
terms of overhead by getting rid of MID messages.  Furthermore there were
and still are issues when using an router ID based approach specifically
when the ID address is no longer in use and when differing interfaces are
operating in differing modes (ie not all are participating in OLSRv2).
Having NHDP HELLOs and OLSRv2 TCs advertize all one hop addresses removes
both of these problematic issues.  Any address can be removed without issue
or countermeasures.  Furthermore interface addresses can be tagged with TLVs
to show specific MANET operation behaviors and capabilities of those
specific interfaces, which may be disjoint sets of behaviors across all
interfaces.  This is important if NHDP is to support differing protocols at
the same time without breaking.  

I am against changing the functioning of NHDP in such a fundamental way
given the above arguments.  I am however for some rational in the document
explaining this design choice, which I agree is not the intuitive choice
(see OLSRv1) and the benefits may not be readily apparent.

Justin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Dearlove, Christopher (UK)
Sent: Thursday, April 02, 2009 8:59 AM
To: Henning Rogge; [email-masked]
Subject: Re: [manet] OLSRv2 - RouterID

> It's not necessary for OLSR to use interface IPs in TCs and Hellos, a
single

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 2 Apr 2009 19:23:31 +0200

All, thanks for the quick responses.

It seems I missed the historical debate on this. I was not involved in MANET
until ~ 3.5 years ago, and up to recently I was not that interested in OLSR,
mainly because lack of link metrics. Sorry for this.

Objection #1: MID
=================
Getting rid of OLSRv1 MID makes sense. No need for justify that. But I am
with Henning that introducing a RouterID does not re-introduce the MID.
There is a need for a flag that defines RouterID is routable or not.
A requirement is that RouterID is stable. Simple to implement, config option
or highest configured unicast IP address. Other variants exists, all are
fine as long as the ID is unique in the MANET routing domain.

Objection #2: NHDP used by OLSRv2 and other protocols
=====================================================
I agree that flooding more identifiers (could be "changing" locators!!)
provides more functionality. But here we could use the more general multiple
topology approach (DYMO has already this capability with DID). I guess we
need hello capability TLV anyway. This would be stored in the Interface
Information Base Link Set. Guest protocols using NHDP shall only use the
link to a neighbor if the required capability for that protocol is found.
Flooding bulk of addresses doesn't help here. What am I missing?

Further enhancements as result of RouterID
==========================================
I think we need the RouterID for anycast support. If addresses are used as
RouterIDs, anycast addresses generate shortcuts in the graph, with black
holes as result (to be verified). This is unacceptable for me.

I have some thought on further reduction of TC overhead.
1) A msg-orig-addr prefix length may be included (own TLV or piggy back
somewhere ?). If included, the prefix msg-orig-addr/prefix-length is handled
as Attached Network Set.
2) All interface addresses within an advertized Attached Network Set (as
summary) should be suppressed in TC messages.
3) When TC msg-orig-addr is missing, the IP header source address is used as
msg-orig-addr (a MAY) used in first hop msg flooding. Message forwarding
routine shall include the msg-orig-addr.

On 1: I highly prefer a single "TC header TLV" with mandatory TLVs. Using
one octet Type for each one octet Value looks not very efficient to me. May
apply to other message types also.

Side remark on TC messages
==========================
I think it is hard to find out what addresses are actually sent by TC. I
**think** the Advertised Neighbor Set is sent, but I cannot find this in
Section 8.2. Maybe the name is altered from Advertised Address Set some day
and the text is not updated consistently (I hope so:-).

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Justin Dean
|Verzonden: donderdag 2 april 2009 16:04
|Aan: 'Dearlove, Christopher (UK)'; 'Henning Rogge'; [email-masked]
|Onderwerp: Re: [manet] OLSRv2 - RouterID
|
|I would like to jump in here as this is an issue we had lots of debate
|about
|quite a while ago and some rational for why the current NHDP
|specification
|does not use a routerID type of framework may appropriate at this time
|before we get to far along in this discussion.  OLSRv1 had this idea but
|NHDP/OLSRv2 does not and this choice was not arbitrary but stems from
|two
|main issues.  Multiple interfaces and multiple mode operation.  The
|current
|specification does not generate MID messages from all nodes which have
|multiple interfaces.  This is not insignificant in terms of overhead
|because
|ALL nodes which have more than one interface had to generate and flood
|these
|message throughout the network.  NHDP HELLO messages do contain more
|address
|information than previous OLSR HELLO messages but again this is
|mitigated in
|terms of overhead by getting rid of MID messages.  Furthermore there
|were
|and still are issues when using an router ID based approach specifically
|when the ID address is no longer in use and when differing interfaces
|are
|operating in differing modes (ie not all are participating in OLSRv2).
|Having NHDP HELLOs and OLSRv2 TCs advertize all one hop addresses
|removes
|both of these problematic issues.  Any address can be removed without
|issue
|or countermeasures.  Furthermore interface addresses can be tagged with
|TLVs
|to show specific MANET operation behaviors and capabilities of those
|specific interfaces, which may be disjoint sets of behaviors across all
|interfaces.  This is important if NHDP is to support differing protocols
|at
|the same time without breaking.
|
|I am against changing the functioning of NHDP in such a fundamental way
|given the above arguments.  I am however for some rational in the
|document
|explaining this design choice, which I agree is not the intuitive choice
|(see OLSRv1) and the benefits may not be readily apparent.
|
|Justin
|
|-----Original Message-----
|From: [email-masked] [mailto:[email-masked]] On Behalf
|Of
|Dearlove, Christopher (UK)
|Sent: Thursday, April 02, 2009 8:59 AM
|To: Henning Rogge; [email-masked]
|Subject: Re: [manet] OLSRv2 - RouterID
|
|
|> It's not necessary for OLSR to use interface IPs in TCs and Hellos, a
|single
|> "Originator IP" for the router instance would be enough to calculate
|the
|> route.
|
|I'm afraid that is not true. In HELLOs at least you need interface
|addresses
|in order for per interface MPR selection to work correctly. And the
|current
|design of TC messages is part of how we abolished MID messages from OLSR
|- and that's a major win in efficiency because MID message forced all
|multiple
|addressed nodes to transmit them, while TC messages are only required by
|MPRs.
|In addition coordintion between differently timed MID and TC messages is
|not
|at all nice, while the current processing is simpler in this regard.
|
|I believe these suggestions are failing to appreciate these details. And
|the
|serious revision that would be required is exactly what is not what we
|need
|at this time. Looking back over drafts, this has been stable in this
|form since
|2006.
|
|
|********************************************************************
|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://www.ietf.org/mailman/listinfo/manet
|
|
|_______________________________________________
|manet mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/manet

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 3 Apr 2009 08:17:11 +0200

Hi,

Comment on my own mail, after more thinking.

<skip>

|As a result, the NHDP hello messages must contain msg-orig-addr (may be
|suppressed if IP header source address is msg-orig-addr). This may be a
|small increase of the size of the packets. But other messages would be
|largely reduced in size, as not ALL addresses are advertized anymore.
|Each
|router identifier (orig-addr) represents all addresses of all interfaces
|of
|the router.
|
|Also unidirectional links become available for routing, as long as there
|is
|a pair of unidirectional links (in opposite directions). This is
|desirable
|qualitative properties #7 of MANET routing protocols (RFC2501).

This #7 property requires interface identifiers. Could be non-routable
"RouterID_local" identifiers like ifIndex. If this is the only (or most
important) benefit, I think it doesn't outweigh the complexity / overhead.
Not at all.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 3 Apr 2009 09:32:33 +0100

> 2-hop) traffic, MIDs are not necessary.

If an OLSRv2 node only has one address, it's already permitted
to include it just as an originator address in a TC message.
And in a HELLO message if it only has one address you can omit
it and use the sending address from IP. These optimisations
are already in the draft (and have been for several versions).

---

From: Henning Rogge <[email-masked]>
Date: Fri, 3 Apr 2009 10:39:25 +0200

Am Friday 03 April 2009 10:32:33 schrieb Dearlove, Christopher (UK):
> > If each OLSR node does only have one routable IP for "long range"
>
> (more than
>
The trick is to be able to do this even with multiple interfaces.

Each node will have one "public" IP and a number of linklocal interface IPs.

I will look through the NHDP/OLSRv2 draft in the weekend again, maybe there is 
a way to support this without any need of changing the packet format and with 
only very small changes in the NHDP handling (and of course without MIDs).

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 3 Apr 2009 09:42:56 +0100

I was unable to post this until now.

>		RY_neighbor_orig_addr    #

This is an example of why this proposal doesn't work.

The Relay Set (or its equivalent post-metrics) needs IP
addresses, originator addresses/router IDs don't work,
and it needs all the IP addresses that a neighbouring
router might use when semding (for example) a TC message.
This is because whether to forward a TC message is based
on its previous router, and that is available only through
the sending IP address of the datagram including the TC
message - the TC message's originator address is just that,
originator address, not updated  on each hop. (And before
anyone suggests changing that, very bad idea, for a number
of reasons, not the least of which is the security model
outlined in RFC 5444.)

Consequently neighbour information in HELLO messages needs
to include interface IP addresses, and you end up with the
design we have.

Also note that if a node just has the one address, you already
have the option to omit it in a HELLO message (use the sending
IP address) and include it only as the originator address in
a TC message. So that efficiency saving is already there.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 3 Apr 2009 10:08:08 +0100

> The trick is to be able to do this even with multiple interfaces.

I don't believe that the multiple interface case is the one that
needs maximal efficiency, because this is not going to be the
simplest, lowest power, devices. Of course I think it still needs
efficiency - especially at the number of messages sent level.
One saved message saves a lot more than its number of octets
- it saves many more octets due to 5444, UDP, IP, MAC, PHY
- and not just headers, also multiple access costs. But an odd
octet is less critical.

That said, as I pointed out in an email I just sent, we need IP
addresses so that (for example) TC message forwarding can work,
within the "intended usage" framework of RFC 5444 (which although
non-normative in 5444, is normative for OLSRv2). And note that the
address compression that's in RFC 5444 makes the multiple address
overhead lower. For example if you are already using various other
addresses in 10.0.0.0/24, the overhead of adding 10.0.0.51/32 (for
example) is one octet (not four).

---

From: Henning Rogge <[email-masked]>
Date: Fri, 3 Apr 2009 11:23:53 +0200

Am Friday 03 April 2009 11:08:08 schrieb Dearlove, Christopher (UK):
> simplest, lowest power, devices.
I think multiple interfaces are very important for efficient networks, and 
WLAN cards are not very expensive (in terms of money and power). We have good 
experience with multichannel OLSR networks on small devices (a few hundred mhz 
cpu) in Freifunk/Funkfeuer networks.

> Of course I think it still needs
Yes. Even requesting media access can be worse than sending a few bytes more.

> non-normative in 5444, is normative for OLSRv2).
Can you please explain this point a little bit more ? It seems I miss some 
important details. Do we need the interface IPs of the two-hop neighbors for 
TC forwarding ?

I thought we would need
- all IPs of the local node (we do have this information of course)
- all interface IPs of the 1-hop neighbors (and routerid if present ?)
- an identifier for 2-hop neighbors (don't need to be the interface ip list)
- knowledge about which 2-hop neighbor can be reached through each one-hop
  interface.

> And note that the
I know (I'm experimenting with automatic address compression), but this 
doesn't work well for IPv6 linklocal addresses. Each address will be at least 
an 8 byte overhead (maybe more).

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 3 Apr 2009 10:38:27 +0100

We don't need the IP addresses of the two hop neighbours
for TC forwarding.

But we get the IP addresses of the two hop neighbours mostly
for free as they are the same IP addresses included in HELLO
messages as are used for one hop neighbours (in order to
etablish symmetry). And those are the same IP addresses as
nodes themselves must send in order that TC forwarding can
work.

The "mostly" above is because there are the IP addresses sent
as neighbours on other interfaces. But those need to be
comparable with the addresses sent on this interface, to
manage the cases where there are more than one link between
two nodes (and because without forcing a node to send two sets
of identifiers - obviously inefficient - that's all we have).

The above is a rapidly composed, incomplete summary (I need to
get back to other stuff). But note that things really aren't as
simple as "let's just change this". The authors have considered,
now some time ago, various simplifications, and many just don't
work when all the details are considered. Ideally we'd have
published an informational draft, or paper, on this and other
issues - but time just hasn't permitted (and certainly won't
until NHDP is out and OLSRv2 has metrics).

-- 
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: 03 April 2009 10:24
To: Dearlove, Christopher (UK)
Cc: [email-masked]
Subject: Re: [manet] OLSRv2 - RouterID

I thought we would need

Henning Rogge

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 3 Apr 2009 12:18:44 +0200

|Van: |Dearlove, Christopher (UK)
|If an OLSRv2 node only has one address, it's already permitted
|to include it just as an originator address in a TC message.
|And in a HELLO message if it only has one address you can omit
|it and use the sending address from IP. These optimisations
|are already in the draft (and have been for several versions).

Extending this facility looks interesting.

What happens if MANET Routers use the same IP address on 
all its interfaces for NHDP/OLSRv2?

 o  It advertizes only one interface address, to be used 
    as IP_hdr_srce_addr, local_iface_addr, orig_addr, RouterID, etc.
    Functionality is equivalent with using a loopback interface
    address added to the MANET interface(s).

 o  This address is used for L2 address resolving (ARP, ND),
    on all interfaces.

 o  Symmetric link check is per interface (no change).

I think this will work, but could require minor text changes 
in NHDP / OLSRv2. The address may be link-local or unique. 
A unique address provides multi-hop reachability, which is 
"practical" for icmp, management, etc.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 3 Apr 2009 11:25:15 +0100

> all its interfaces for NHDP/OLSRv2?

Breaks the protocol.

> I think this will work

It doesn't.

Among other issues it is unable to distinguish a symmetric
link between interfaces I and J with two non-symmetric
links I1 to J1 and J2 to I2, and it fails to allow interface
specific MPR selection, which is necessary to avoid a race
condition which can otherwise occur.

Furthermore once we add metrics, when there are multiple
links between two nodes (easy to occur if, for example we
equip some nodes with one 802.11 card on channel 1, some
with one 802.11 card on channel 5, and some with two 802.11
cards, on each channel) they will have different metrics
and we need to distinguish them.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 3 Apr 2009 15:05:59 +0200

|Van: Dearlove, Christopher (UK) [mailto:[email-masked]]
|Aan: Teco Boot; Henning Rogge
|
|> What happens if MANET Routers use the same IP address on
|> all its interfaces for NHDP/OLSRv2?
|
|Breaks the protocol.
|
|> I think this will work
|
|It doesn't.

May be it isn't, maybe it is. I said, a minor change in text (or algorithm)
could be needed.

|Among other issues it is unable to distinguish a symmetric
|link between interfaces I and J with two non-symmetric
|links I1 to J1 and J2 to I2, 

Neighbors can perfectly distinguish the links, and can check symmetry.
I receives "J via I1" and "J via I2".
J receives "I via J1" and "I via J2".

Link tables router I:
  Interface I1:
    Neighbor J via J, status [heard | symmetric | lost]
  Interface I2:
    Neighbor J via J, status [heard | symmetric | lost]  
Link tables router J:
  Interface J1:
    Neighbor I via I, status [heard | symmetric | lost]
  Interface J2:
    Neighbor I via I, status [heard | symmetric | lost]  

|and it fails to allow interface
|specific MPR selection, which is necessary to avoid a race
|condition which can otherwise occur.

I don't understand this. The requirement is that the set
of MPRs must provide connectivity to all 2-hop neighbors
(Flooding-MPR "coverage criterion") .
Questions:
 o   Why MPR selection per interface?
 o   What is the problem? Because there is enough signaling
     to send selected MPR info via one of the interfaces,
     and the relay set is maintained per interface?

Example, assuming I and J has 2-hop neighbors K respectively L:

2-Hop Set router I:
	Router K
2-Hop Set router J:
	Router L

Relay Set router I:
  Interface I1:
    Neighbor J via J
  Interface I2:
Relay Set router J:
  Interface J1:
  Interface J2:
    Neighbor I via I

|Furthermore once we add metrics, when there are multiple
|links between two nodes (easy to occur if, for example we
|equip some nodes with one 802.11 card on channel 1, some
|with one 802.11 card on channel 5, and some with two 802.11
|cards, on each channel) they will have different metrics
|and we need to distinguish them.

Definitely agreed.
First, the sender knows the Tx data rate selected for each neighbor on a
link. When this is higher than the minimum (and there is unicast traffic),
this is enough for calculating a metric value. And the Rx RSSI level may be
used, but this is not recommended, the Rx RSSI captured by the neighbor is
to be used. This "remote Rx RSSI" can be transferred to the neighbor with
the NHDP hello messages on that link, the metric is for the link on that
interface.

What is the problem? So far, none yet.

Teco.

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 3 Apr 2009 14:16:32 +0100

> May be it isn't, maybe it is. I said, a minor change in text (or
algorithm)

No such change is going to be minor, and most such changes just don't
work (we've investigated many of them). And it is just not appropriate
to go down this route at this time, when we have been stable for three
years, with a protocol we understand and have running code for, chasing
the chimera of maybe we can simplify something that is non-trivial for
good reasons.

> of MPRs must provide connectivity to all 2-hop neighbors

That's not sufficient.

>  o   Why MPR selection per interface?

Read the literature. And yes, that is me not putting in the effort
to point out the race condition case and why per interface avoids
it and per router doesn't (a subtlety in the MPR flooding proof).

Note that with metrics, flooding MPRs will be per interface, routing
MPRs don't have to be.

The point is, this is a far too late, ill-thought out, proposal.
There are many subtle details that went into what we have.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 3 Apr 2009 16:43:18 +0200

|Van: Dearlove, Christopher (UK)

|I don't believe that the multiple interface case is the one that
|needs maximal efficiency, because this is not going to be the
|simplest, lowest power, devices. Of course I think it still needs
|efficiency - especially at the number of messages sent level.
|One saved message saves a lot more than its number of octets
|- it saves many more octets due to 5444, UDP, IP, MAC, PHY
|- and not just headers, also multiple access costs. But an odd
|octet is less critical.

Maybe, maybe not.
Some radio technologies do not have high UDP, IP, MAC & PHY overhead and
each odd octet could be critical.
This type of radios do occur where multiple interfaces are used. At least in
my environment.

Teco.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 03 Apr 2009 09:41:57 -0700

Hello Chris,

Comments below...

>> of MPRs must provide connectivity to all 2-hop neighbors

I believe this is highly debatable.

> it and per router doesn't (a subtlety in the MPR flooding proof).

I read the proofs, albeit a couple of years ago, and I don't remember
anything particular about this point.  Too bad I can't go back and review
this material today.

> The point is, this is a far too late, ill-thought out, proposal.

This is what goaded me into making a response.

First of all, I saw a suggestion, not a proposal.
Of course it wasn't fully thought out.

Second, it's never too late to simplify and improve
a protocol.  Sometimes it is too late for a particular
publication.  Sometimes code has to get frozen in order
to test and ship it.

It's never too late to suggest improvements.  And if
the engineering management decides to ship a product
because the improvements cannot be incorporated,
then the improvements may well be considered for
future product upgrades.

Perhaps you will claim that no future upgrades are
envisioned for OLSR.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 3 Apr 2009 20:19:23 +0200

I'll prefer the technical discussion. But some words on:
>> this is a far too late, ill-thought out, proposal

Far too late:
=============
I raised this issues a couple of times before. See below minutes of IETF-71
and two ML postings.
During meetings between, the response was "get out packetBB and others
first, thereafter we can take a look at it".
Now the time has come.

Ill-thought out:
================
Great scientists in history had ill-thought ideas. Nowadays, we think
different. I'm not saying my proposal is brilliant or even it is mine. 

Back to the technical discussion:
=================================
> Read the literature.

I read again the documents on MPR. I did not find problems with MPR
selection based on nodes. Can someone come up with some material? Otherwise
my conclusion is that my proposal is an important enhancement.

Teco.

===

Meeting  : IETF 71 Monday March 10th 2008

Teco Boot: 

       The number of addresses exchanged with the interface
       IDs is problematic. It is inefficient. Is possible to simply
       use a single router ID to improve it ?

       Thomas Clausen: If you have only one interface with one
       address, then things might be simplify-able. However with
       multiple interfaces and multiple addresses, then the
       bi-directionality check of a link over a pair of interfaces
       requires information describing all addresses.

       Ian Chakeres: Let's put this on the "to do" list.

===

http://www.ietf.org/mail-archive/web/manet/current/msg10433.html 
Date: Mon, 28 Jul 2008 19:15:17 +0200

All,

Let me repeat an older comment on NHDP (and OLSRv2).

The current document mandates exchange of ALL addresses on ALL interfaces of
the MANET Router.
E.g. page 11:
   o  A 2-Hop Set, which records the existence of bidirectional links
      between symmetric 1-hop neighbors of this MANET interface and
      other nodes (symmetric 2-hop neighbors).  The 2-Hop Set consists
      of 2-Hop Tuples, each of which records an interface address of a
      symmetric 2-hop neighbor, and all interface addresses of the
                                    =======================
      corresponding symmetric 1-hop neighbor.  The 2-Hop Set is updated
      by the signaling of this protocol, but is not itself reported in
      that signaling.

I prefer reducing overhead where we can, as bandwidth in the MANET can be
scarce and improvements on efficiency helps scalability.
IMHO a MANET router could advertize a single summary prefix into the MANET
protocol. For NHDP, a RouterID or alternative approach could be used for
identifying a MANET Router. Therefore I want to have removed specifications
that **all interface addresses** are exchanged.

Please respond on this opinion.

Regards, Teco

===

http://www.ietf.org/mail-archive/web/manet/current/msg10478.html
From: "Dearlove, Christopher (UK)" <chris.dearlove at baesystems.com>
Date: Wed, 27 Aug 2008 12:28:49 +0100

I agree with you in that this should be qualified as
limited to addresses which the node wishes to make
available for non-local routing. If a node has an
address that it doesn't want to be used for routing to it
from other nodes, there is of course no reason to advertise
that. We should qualify the wording to indicate that.
Whether a node then wants to advertise a single address, a
single prefix, or multiple addresses/prefixes is then up
to it, but it needs to then be consistent (it can change
its advertisement, but this over-rides any previous
advertisement and should be done infrequently).

===

---

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

> each odd octet could be critical.

I don't know any system in which all of those overheads aren't such
that one's first priority isn't to save messages, the secondly to
save message size. Obviously one message ten times the size of two
isn't (usually) a win, but one message is significantly cheaper than
two that apparently have the same total size (as long as within MTU
limits).

As for individual octets, well, we fought the fight when creating
RFC 5444 between the competing interests of flexibility, efficiency
and simplicity. One all three axes we had people wanting to move us
from where we ended up in both directions. (Of course no one wanted
to move to, for example, less efficient because it was less efficient,
but because they wanted it, say, simpler.) The same logic applies to
NHDP and OLSRv2. For ultimate every octet is critical design, I think
you'll need the ROLL group. Our target has to be reasonable efficiency,
while retaining the other characteristics (and some others as well.

---

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

|> Some radio technologies do not have high UDP, IP, MAC & PHY overhead
|and
|> each odd octet could be critical.
|
|I don't know any system in which all of those overheads aren't such
|that one's first priority isn't to save messages, the secondly to
|save message size. Obviously one message ten times the size of two
|isn't (usually) a win, but one message is significantly cheaper than
|two that apparently have the same total size (as long as within MTU
|limits).

Not (always) true for TDMA type of radios.

For CSMA/CA (with RTS/CTS) without header compression, I agree saving each
octet is not the primary goal.
The more advanced type of radios do have other media access and support
header compression. A single octet could cause usage of another timeslot,
causing a lot of overhead (worst case: doubling used bandwidth).

|As for individual octets, well, we fought the fight when creating
|RFC 5444 between the competing interests of flexibility, efficiency
|and simplicity. One all three axes we had people wanting to move us
|from where we ended up in both directions. (Of course no one wanted
|to move to, for example, less efficient because it was less efficient,
|but because they wanted it, say, simpler.) The same logic applies to
|NHDP and OLSRv2. For ultimate every octet is critical design, I think
|you'll need the ROLL group. Our target has to be reasonable efficiency,
|while retaining the other characteristics (and some others as well.

In general I agree. Still, I think it is more practical to use a single TLV
for a set of fields that are always there, e.g. a hello or tc header. 

Teco.

---

From: jacquet <[email-masked]>
Date: Mon, 06 Apr 2009 16:17:30 +0200

Hello, Charlie,

Your question is very pertinent. This was indeed an old discussion, that 
I merely forgot. It was based on the principle that if interfaces differ 
too much in performance you may have uncontrolled effects, and it was 
difficult to taylor a proper mechanism for each special cases.

One special case: assume that you have two kinds of interfaces: slow and 
fast. If slow means very slow, then you may have a very long flooding 
time for a single packet if you merge interfaces for MPR selection.  You 
may even have no end at all;-)

Consider the following network
   B-----D
  /  \    /   \
A   \ /       F
 \   /   \    /
   C-----E
with all interfaces of type fast excepted (B,D) and (C,E), that are 
slow. If all interfaces are merged for MPR calculation, then it can be 
that MPR of B and C are all on slow interface.

Suppose MPRs of A are both B and C (there may be additional neighbors on 
B and C to force that).

If A initiates a flood, then  B and C will retransmit simultaneously on 
fast interface and slow interface, but fast interface arrives first on D 
and E, both  receive first from non MPR and cannot relay. F does not 
receive the broadcast.

When D or E eventually receive from the slow interface it could compare 
time stamps to actually decide that slow interface indeed had precedence 
on fast interface in race competition and finally to decide to actually 
retransmit. But again you come out with the performance of the worse 
interface (and a very complicated mechanism).

If MPR are on per interface, then B will select E as MPR on fast interface
and you gain on the fastest interface which will win the race competition.

I think this was the issue (but I am not sure), but I agree that the 
result was a kind of compromise to keep things simple.

Best regards,
Philippe

---

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

Charlie

Didn't see your message until Philippe replied. For some reason
I think you are filtered out here - I never see your postings
these days (I used to) only replies to them. What email address
is your usual one (or ones) these days, I'll see if I can get
them whitelisted (or whatever it takes). 

My understanding (having posted in haste to see the literature,
and Stan Ratliff also having asked for the specific posting)
from Thomas is that the detail is published, but buried in some
INRIA report. On the (extensive) list of things Thomas and I
plan to do when time permits (which I hope doesn't mean never,
but you knwo how it is) is including this, among other details,
in various informational material (nature of publication TBD)
we'd would really like to put out for the first time, or in a
more accessible form. But don't hold your breath!

Thomas said (to me) he'd put this on the list, I'm not sure if
this is Philippe doing that for Thomas or independently.

Of course you can ignore the issue, and things will probably
work most of the time. But do you accept that a known race
condition exists, or do you do something that avoids it?
(Note that you really should follow the advice that I know
is in OLSRv2, and I think is in RFC 3626, and although each
interface has an MPR Set, and the overall MPR Set is the
union, they should be calculated together, so that typically
there's no serious loss in flooding efficiency.)

-----Original Message-----
From: jacquet [mailto:[email-masked]] 
Sent: 06 April 2009 15:17
To: Charles E. Perkins
Cc: Dearlove, Christopher (UK); [email-masked]
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. 

Hello, Charlie,

Best regards,
Philippe

---

From: jacquet <[email-masked]>
Date: Mon, 06 Apr 2009 17:01:45 +0200

Chris,

How do you filter Charlie? I thought it was impossible;-) In exchange I 
will show you how I can filter Thomas.

To be per interface or not per interface is not just a formal issue, it 
has impact on performance. Charlie was right to refresh this issue. But 
I understood that the main stream of the discussion is now mostly on the 
advertizement of routerID. And there is a kind of agreement that MPR 
selection should be done on a per interface basis. Am I right? But I 
wanted to be sure that no misunderstanding remains.

Best regards,
Philippe

---

From: "Justin Dean" <[email-masked]>
Date: Mon, 6 Apr 2009 11:11:44 -0400

Thank you Philippe you beat me to the rational for why MPR sets are chosen
per interface instead of aggregated across all interfaces of a node.  I feel
that a good portion of the discussion going on about router id type of
behaviors are muddling topics between NHDP and OLSRv2 and specifically
routing in general.  

NHDP is a hello protocol meant to collect 2 hop neighbor information.  For a
node to discover all of a two-hop neighbors addresses a one-hop neighbor has
to convey that information somehow, and including this information in a
HELLO message as opposed to a MID type message is the easiest solution,
which also does a few nice things.  It saves mandating generation of another
differing MID type of message within the NHDP protocol.  It allows tagging
of specific addresses to discover symmetric links;  It's not sufficient for
you to tell me just that you heard me, I need to know which interface
address you heard me on so I know which will interface will deliver a packet
to you unless one wishes to send out all interfaces every time.  Other
information such as capabilities/configuration/metrics can be added via TLVs
to the appropriate links without overly complex TLV (i.e. TLVs which include
extra addresses).  What including all one hop neighbors addresses in a HELLO
message does not do natively is aggregate 2-hop addresses into one logical
node, TLVs can be added for this informational purpose without breaking how
NHDP functions.  

One may argue that not all 2-hop addresses are needed only that a node
exists 2 hops away.  For most MANET operations I do not agree with this
argument as it oversimplifies the 2-hop network representation and requires
more complex mechanisms to solve issues which arise in non-trivial cases
(multiple interfaces, link metrics, multiple operation mode
OLSR/NHDP/OTHER.)  Without specific link information selecting MPRs which
guarantee 2-hop deliver in the network Philippe described is not possible.

I would like to point out however that reintroducing a MID type of message
within OLSRv2 may be possible within the context of TC messages.  I would go
even further and say that empty update TC message saying "no change" might
be sufficient and more efficient. 

Justin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
jacquet
Sent: Monday, April 06, 2009 10:18 AM
To: Charles E. Perkins
Cc: Dearlove, Christopher (UK); [email-masked]
Subject: Re: [manet] OLSRv2 - RouterID

Hello, Charlie,

Best regards,
Philippe

---

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

I believe the consensus of the authors is that per
interface is best, and we know why. But (based on that
people like Stan and Charlie are asking the questions)
although that this is the case is specified in OLSR, 
and every OLSRv2 draft I think, it's clearly not well
known, and the reasons why are even less well known.

-----Original Message-----
From: jacquet [mailto:[email-masked]] 
Sent: 06 April 2009 16:02
To: Dearlove, Christopher (UK)
Cc: Charles E. Perkins; [email-masked]
Subject: Re: [manet] OLSRv2 - RouterID

               *** WARNING ***

Chris,

Best regards,
Philippe

---

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

> Consider the following network
....
> result was a kind of compromise to keep things simple.

As soon as a routing metric enters the MPR selection it get's a little bit 
more complicated again. The "per interface to prevent bad links" concept 
reminds me a little bit to the hysteresis part of OLSRv1. It was a compromise 
to get a little bit more from the hopcount algorithm.

On Montag 06 April 2009 16:38:08 Dearlove, Christopher (UK) wrote:
> 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.

1 to 16 octets, not 32.

On Montag 06 April 2009 16:10:01 Dearlove, Christopher (UK) wrote:
> > However, topology information must be complete.
>
> And that's why the "relay only" node needs a little care.
> But we can give it that.

Maybe we could use a phrase like "MUST contain all global routable IPs but at 
least one network-wide unique IP to address the node".

Henning Rogge

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 6 Apr 2009 16:28:59 +0100

> behaviors are muddling topics between NHDP and OLSRv2 and specifically

I may have been guilty of that. But in part deliberately. Although NHDP
is a stand-alone protocol, it is also an essential underpinning of
OLSRv2
(after all, it was part of OLSRv2 until we spun it out) and we need it
not to become useles to OLSRv2 or, more subtlely, although (for some
possible changes) apparently slightly more efficient as a stand-alone
protocol, if all that saving and a lot more is lost in OLSRv2 (or in
SMF) it would be a bad tradeoff. So you do need to consider OLSRv2 (and
in this regard SMF is simpler or similar) as part of the question.

> within OLSRv2 may be possible within the context of TC messages.

There's a conceptual problem here that MID messages reported a node's
own state. This appears good, but isn't, as it forces otherwise silent
nodes to transmit. Furthermore there's much duplication of message
headers.
Putting all the work onto TC messages saves that. We don't bother in TC
messages pointing out where information comes from the same node - for
just
routing, as long as it gets where it should go efficiently, we don't
need
to know that (although for any node that sends TC messages we do know
that,
in the Advertising Remote Router Set).

> I would go

Mostly that's not a good idea as you don't know if there are new remote
nodes
that need the information, and you also don't know about losses.

But having said that, use of an incomplete TC message has some of that
effect.
(There is a detail there that you make me want to check.)

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 6 Apr 2009 11:32:06 -0400

Chris, 

I promise I'm not trying to be a rabble-rouser (at least this time through... ;-). I was just wanting to understand the nature of the race condition, and Philippe's email did a great job of explaining it. 

Regards,
Stan

> On Behalf Of Dearlove, Christopher (UK)
> Sent: Monday, April 06, 2009 11:17 AM
> To: jacquet
> Cc: [email-masked]
> I believe the consensus of the authors is that per interface 
> is best, and we know why. But (based on that people like Stan 
> and Charlie are asking the questions) although that this is 
> the case is specified in OLSR, and every OLSRv2 draft I 
> think, it's clearly not well known, and the reasons why are 
> even less well known.
> 
> --
> Christopher Dearlove
> Networks, Security and Information Systems Department BAE 
> Systems Advanced Technology Centre West Hanningfield Road, 
> Great Baddow, Chelmsford, CM2 8HN, UK
> Registered Office: Warwick House, PO Box 87, Farnborough 
> Aerospace Centre, Farnborough, Hants, GU14 6YU, UK Registered 
> in England & Wales No: 1996687
>

---

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

> more complicated again.

Indeed. See draft-dearlove-olsrv2-metrics-03. There we have had to
separate routing and flooding MPRs (only the latter needing to be
per interface) and the concept of strictly two hop gets messy. the
draft contains what should be complete algorithms - if you think
there's anything missing, now would be a great time to know.

> least one network-wide unique IP to address the node".

There's at least one more detail needed (which address(es) - changing
selection shouldn't be done unnecessarily and must change ANSN) that
needs some thought. Possibly the solution involves using the originator
address, but more thought needed to get it right.

---

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

I took your question exactly as you indicated. If I appeared
to suggest otherwise, my apologies. 

It is a tricky subject. My first semi-public work on OLSR
was commenting to the authors on drafts. And one suggestion
I made involved simplifying away this case, before someone
from the INRIA team (I think it was Cedric Adjih) dug up the
race condition case. So I've also been there, done that.

It's also worth clarifying what needs (in the sense that we
ae considering here) to be per interface.

First without metrics
- MPR selection, yes, but take union.
- MPR selectors, no.
- MPR Relay Set selection, is currently per interface
  (superset of MPR selectors).

With metrics
- For routing, no.
- For flooding, as without metrics (although can use them)
  but we're intending to cut the Gordian knot and scrap the
  Relay Sets, using only MPR selectors, so, no for usage
  (but yes for selection).

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: 06 April 2009 16:32
To: Dearlove, Christopher (UK); jacquet
Cc: [email-masked]
Subject: RE: [manet] OLSRv2 - RouterID

               *** WARNING ***

Chris, 

Regards,
Stan

---

From: Richard Ogier <[email-masked]>
Date: Mon, 06 Apr 2009 10:48:53 -0700

The race condition that Philippe described can also occur with
a single interface under certain conditions. 
For example, suppose a MAC protocol is used that decides to "multicast"
a packet by unicasting it to each neighbor, one at a time.
(In some cases, this might be more efficient if there are only 2 or 3
neighbors.)  Then, in Philippe's example, it is still possible for
nodes D and E to receive the packet from non-MPR selector neighbors
and thus not forward the packet.
(Such a situation can also occur in networks with very long propagation
delays, such as satellite networks, due to delay differences, but
perhaps that is out of scope.)

So it might be worthwhile to modify the MPR selection or the
MPR flooding mechanism in order to allow the above situation.
This is one of a number of drawbacks of MPRs that led me to use CDS
flooding instead of MPR flooding for the MANET extension of OSPF.

Richard

jacquet wrote:

> Hello, Charlie,
>
> Your question is very pertinent. This was indeed an old discussion, 
> that I merely forgot. It was based on the principle that if interfaces 
> differ too much in performance you may have uncontrolled effects, and 
> it was difficult to taylor a proper mechanism for each special cases.
>
> One special case: assume that you have two kinds of interfaces: slow 
> and fast. If slow means very slow, then you may have a very long 
> flooding time for a single packet if you merge interfaces for MPR 
> selection.  You may even have no end at all;-)
>
> Suppose MPRs of A are both B and C (there may be additional neighbors 
> on B and C to force that).
>
> If A initiates a flood, then  B and C will retransmit simultaneously 
> on fast interface and slow interface, but fast interface arrives first 
> on D and E, both  receive first from non MPR and cannot relay. F does 
> not receive the broadcast.
>
> When D or E eventually receive from the slow interface it could 
> compare time stamps to actually decide that slow interface indeed had 
> precedence on fast interface in race competition and finally to decide 
> to actually retransmit. But again you come out with the performance of 
> the worse interface (and a very complicated mechanism).
>

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 21:50:33 +0200

Thanks for all the information on the list. It is very helpful understanding
what we have.

Back to my questions, some are not answered yet.
 
|I have a question on:
|
|> OLSRv2 does not make any assumption about router addresses, other
|> than that each router is assumed to have at least one unique and
|> routable IP address for each interface that it has which participates
|> in the MANET.
|
|Why is this? It excludes usage of link local addresses. I do not see a
|hard
|reason not using LLs, as long as they are unique in the MANET Routing
|Domain. And LLs are not routable.

I can imagine a MANET with some MANET routers with only LL addresses, as
transit for other nodes. These routers would have (IPv6) LLs only. When LLs
are unique (e.g. using unique Interface IDs), this would not cause any
problem with current specification.

Why routable ?
Or: what is routable ?

On uniqueness and LLs I'll open another thread.

Teco.

---

From: "Teco Boot" <[email-masked]>
Date: Mon, 6 Apr 2009 22:30:24 +0200

My second question is why MANET unique addresses on interfaces are needed. I
think the discussion is drifted to MPR selection "per interface" or "over
all interfaces". My suggestion using RouterID leaves this open. 

In my proposal with RouterID, NHDP info is available per segment (or per
interface, if one prefers this term), so MPR selection can be done per
segment. I included "ifIndex" in the tables below to demonstrate the "per
interface" state. I adjusted the info below, it still needs verification.

The TC information is "per MANET", as its purpose is SPF calculation finding
the next hop for advertized prefixes. Details on multiple links between
nodes and 2-hop neighborhood is not needed for that.

As Henning suggested, this idea could be implemented based on current spec
as nothing really changes. It is just a matter of housekeeping available
information (also to be verified).

Teco.

|For SPF calculation, only identifiers for the nodes and their links are
|needed. A straightforward approach would be unique router identifiers
|within
|the routing domain and unique interface identifiers within the scope of
|each
|router. For the latter, ifIndex could be used and single octet provides
|namespace for 256 interfaces using continuous numbering. One may think
|of
|extended numbering. A link is identified by a 4-tuple of RouterID and a
|interface identifier, for itself and the neighbor. I don't think the
|interface identifiers are needed in the NHDP and OLSRv2 messages.
|
|I think the problems can be circumvented by using the following
|information
|bases, for NHDP and OLSRv2:
|(to be verified)
|
|Local Information Base
|	Local Interface Set
|		ifIndex              # added
|		I_local_iface_addr   #
|		I_manet
|	Removed Interface Address Set
|		ifIndex              # added
|		IR_local_iface_addr
|		IR_time
|	Originator Set	    # not required if orig_addr is stable
|		O_orig_addr
|		O_time
|	Local Attached Network Set
|		AL_net_addr
|		AL_dist
|
|Interface Information Bases
|	Link Set
|		ifIndex         # added
|		L_orig_addr     #
|		#    	L_ifIndex     not needed !!
|		L_HEARD_time
|		L_SYM_time
|		L_quality
|		L_pending
|		L_lost
|		L_time
|	2-Hop Set
|		ifIndex         # added
|		N2_orig_addr    #
|		#    	L_ifIndex     not needed !!
|		N2_2H_orig_addr
|		N2_time
|
|Neighbor Information Base
|	Neighbor Set
>>>   	ifIndex            # added
|		N_orig_addr        #
|		N_symmetric
|		N_willingness
|		N_mpr
|		N_mpr_selector
|	Lost Neighbor Set
>>>		ifIndex            # added
|		NL_orig_addr       #
|		NL_time
|
|Topology Information Base
|	Advertised Neighbor Set
|		A_orig_addr        #
|	Advertising Remote Router Set
|		AR_orig_addr       #
|		AR_seq_number
|		AR_time
|	Topology Set
|		T_dest_orig_addr   #
|		T_orig_addr
|		T_seq_number
|		T_time
|	Attached Network Set
|		AN_net_addr
|		AN_orig_addr
|		AN_dist
|		AN_seq_number
|		AN_time
|	Routing Set
|		R_dest_addr
|		R_next_iface_addr
|		R_dist
|		R_local_ifIndex    #
|
|Processing and Forwarding Information Base
|	Received Set
|		RX_type
|		RX_orig_addr
|		RX_seq_number
|		RX_time
|	Processed Set
|		P_type
|		P_orig_addr
|		P_seq_number
|		P_time
|	Forwarded Set
|		F_type
|		F_orig_addr
|		F_seq_number
|		F_time
|	Relay Set
>>>		ifIndex                  # added
|		RY_neighbor_orig_addr    #
|
|
|of the router.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 7 Apr 2009 09:21:42 +0200

> problem with current specification.
I think a routable address is one that you can reach through multiple hops in 
the entire net. An address you can only access from one hop away would not be 
routable because of the configuration of the OLSR network.

Henning

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 7 Apr 2009 10:25:18 +0100

I think this is part of the tidying up and relaxing some
details in OLSRv2 (but doesn't affect NHDP) that we are
(I think) all agreed is in order.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Teco Boot
Sent: 06 April 2009 20:51
To: 'manet'
Subject: Re: [manet] OLSRv2 - RouterID - Q1

               *** WARNING ***

Thanks for all the information on the list. It is very helpful
understanding
what we have.

|I have a question on:
|

I can imagine a MANET with some MANET routers with only LL addresses, as
transit for other nodes. These routers would have (IPv6) LLs only. When
LLs
are unique (e.g. using unique Interface IDs), this would not cause any
problem with current specification.

Why routable ?
Or: what is routable ?

Teco.