Jiazi YI | 1 Jul 09:42 2010
Picon

Re: Multipath OLSR (MP-OLSR) implementaion available online

OK, I think we will be there for the manet session, and prepare a possible presentation/discussion on multipath routing.
 
thanks
 
2010-07-01
Jiazi YI
 
www.jiaziyi.com
PhD Candidate, IVC Team (Image Video Communications)
IRCCyN Lab - UMR CNRS 6597
TEL: +33 (0) 240 683 044
Fax : +33 (0) 240 683 232

École d'ingénieurs de l'université de Nantes
Site de la Chantrerie -Rue Christian Pauc
B.P 50609 - 44306 NANTES CEDEX 3 - France
发件人: Dearlove, Christopher (UK)
发送时间: 2010-06-29  14:21:36
收件人: Joe Macker; Jiazi YI
抄送: manet <at> ietf.org
主题: RE: [manet] Multipath OLSR (MP-OLSR) implementaion available online
Unfortunately, I won't be able to be in Maastricht - or at least
it's sufficiently unlikely that that's the way to plan.
-- 
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: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf Of Joe Macker
Sent: 29 June 2010 12:02
To: Jiazi YI
Cc: manet <at> ietf.org
Subject: Re: [manet] Multipath OLSR (MP-OLSR) implementaion available online
                    *** WARNING ***
  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.
 
Well it would be good to discuss this with OLSR authors and the manet list. But I am collecting suggestions for additional presentations.  Usually we have room for 10 minutes short presentations at the end of the meeting re. new work, extensions of existing protocols, etc.  we have to spend the bulk of the meeting on WG items.  Is the WG ok with this presentation being added.
You should continue to check the agenda schedule on line because sometimes they switch meetings at the last minute but it is a safe bet it will be Tuesday afternoon.
On Jun 29, 2010, at 10:15 AM, Jiazi YI wrote:
> Hi dear M. Macker
>  
> We are very interested in this event.
> Just to confirm, The meeting will be at the end of July, in Maastricht? And the session for manet will be July 27, Tuesday afternoon, right?
>  
> In fact, I have never been in a IETF meeting before. What should we prepare for that? A short presentation about our work and a discussion for 10 minutes?
>  
> Thanks. Hopefully to see you there.
>  
> Sincerely
>  
> 2010-06-29
> Jiazi YI
>  
> www.jiaziyi.com
> PhD Candidate, IVC Team (Image Video Communications)
> IRCCyN Lab - UMR CNRS 6597
> TEL: +33 (0) 240 683 044
> Fax : +33 (0) 240 683 232
> École d'ingénieurs de l'université de Nantes 
> Site de la Chantrerie -Rue Christian Pauc
> B.P 50609 - 44306 NANTES CEDEX 3 - France
> 发件人: Joe Macker
> 发送时间: 2010-06-28  21:24:30
> 收件人: Jiazi YI
> 抄送:
> 主题: Re: [manet] Multipath OLSR (MP-OLSR) implementaion available online
> we often have presentation at the  end of manet about new work would someone be in Netherlands to discuss perhaps 10 minutes.
> -Joe
> On Jun 25, 2010, at 10:05 AM, Jiazi YI wrote:
> > Hi dear everyone.
> >  
> > I'm glad to announce that the implementation of Multipath OLSR (MP-OLSR) is availalbe online at
> >  
> > http://www.jiaziyi.com/SEREADMO.php
> > or
> > http://www.irccyn.ec-nantes.fr/spip.php?article527
> >  
> > The implementation for Qualnet and NS2 simulator is also available at
> >  
> > http://www.jiaziyi.com/MP-OLSR.php
> >  
> > Hopefully these will be helpful for those who are intrested.
> >  
> > sincerely
> >  
> > 2010-06-25
> > Jiazi YI
> >  
> > www.jiaziyi.com
> > PhD Candidate, IVC Team (Image Video Communications)
> > IRCCyN Lab - UMR CNRS 6597
> > TEL: +33 (0) 240 683 044
> > Fax : +33 (0) 240 683 232
> > 
> > École d'ingénieurs de l'université de Nantes 
> > Site de la Chantrerie -Rue Christian Pauc
> > B.P 50609 - 44306 NANTES CEDEX 3 - France
> > _______________________________________________
> > manet mailing list
> > manet <at> ietf.org
> > https://www.ietf.org/mailman/listinfo/manet
_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
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
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
Henning Rogge | 1 Jul 14:35 2010
Picon

Re: Metric encoding for OLSRv2

On Wed June 30 2010 00:33:45 Teco Boot wrote:
> Your alternative and the "- 15" option do not differ that much.
> So it is acceptable for me.
The "infinite" metric is not that important (it's a nice to have I think), as 
long as we can encode a cost of zero.

> Having a coding scheme with a maximum near to 2^24 - 1 would be nice, but a
> 1 to 10^6 ratio would be good enough for almost all scenarios.
value = (a + 2^m)*2^b - 2^m
0 <= value <= 1015792

What would be a good default link value for this encoding ?
I would suggest (a=0,b=15) = 524272 or (a=0,b=14) = 262128.

This would give us lot's of range for metrics better than hopcount and some 
space for links worse than it.

Henning Rogge

--

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge <at> fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0
_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
Joe Macker | 1 Jul 14:42 2010
Picon
Picon

Draft Agenda Items

I would like to finalize the draft agenda as soon as possible for Maastricht.
Authors on WG and related items please let me know your present status.  

Our presentation priorities are related to present WG documents so those will go first.

I have heard from two other presenters so far that would like a small timeslot on related work.

Jiazi Li: Multipath OLSR implementation
Stan Ratcliff: Draft on passing metrics between a radio/other interface and the router layer.

Any comments or other issues please let me know.

-Joe
Dearlove, Christopher (UK | 1 Jul 15:25 2010

Re: Metric encoding for OLSRv2

The current proposal is in the middle of the range
logarithmically, rather than arithmetically (I would
prefer a=0,b=15 to a=0, b=14). I can (otherwise we
wouldn't have proposed it) see some logic to that.

There is another value worth considering, and that
is the maximum value. This has the potential advantage
of clarity over that there are two different default
concepts

- The "don't need to signal a metric thus saving
  octets" value, and

- The "I haven't been able to work out what a good metric
  valus is yet, so let's use this" value.

The latter should almost certainly be the maximum value.
The former really only has two purposes

- If there is an often used value.

- For hop count.

Note that for pure hop count it is irrelevant what the default
value is. If you are going to have cases where e.g you signal
double hops then maximum is the worst value - and the best
value is probably the minimum value (excluding zero, if zero
is included). And that is another candidate.

Incidentally inclusion of zero makes a change to OLSRv2.
It means that you MUST pick the fewest hop route among those
with the same metric. Without it, that becomes a SHOULD,
or even a MAY.

-- 
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:henning.rogge <at> fkie.fraunhofer.de] 
Sent: 01 July 2010 13:35
To: Teco Boot
Cc: Dearlove, Christopher (UK); manet <at> ietf.org
Subject: Re: [manet] Metric encoding for OLSRv2

On Wed June 30 2010 00:33:45 Teco Boot wrote:
> Your alternative and the "- 15" option do not differ that much.
> So it is acceptable for me.
The "infinite" metric is not that important (it's a nice to have I think), as 
long as we can encode a cost of zero.

> Having a coding scheme with a maximum near to 2^24 - 1 would be nice, but a
> 1 to 10^6 ratio would be good enough for almost all scenarios.
value = (a + 2^m)*2^b - 2^m
0 <= value <= 1015792

What would be a good default link value for this encoding ?
I would suggest (a=0,b=15) = 524272 or (a=0,b=14) = 262128.

This would give us lot's of range for metrics better than hopcount and some 
space for links worse than it.

Henning Rogge

--

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:henning.rogge <at> fkie.fraunhofer.de http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

********************************************************************
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.
********************************************************************
Dearlove, Christopher (UK | 1 Jul 15:26 2010

Re: Draft Agenda Items

Is Stan's draft published?

-- 
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: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf
Of Joe Macker
Sent: 01 July 2010 13:42
To: manet <at> ietf.org
Subject: [manet] Draft Agenda Items

                    *** WARNING ***

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

I would like to finalize the draft agenda as soon as possible for
Maastricht.
Authors on WG and related items please let me know your present status.

Our presentation priorities are related to present WG documents so those
will go first.

I have heard from two other presenters so far that would like a small
timeslot on related work.

Jiazi Li: Multipath OLSR implementation
Stan Ratcliff: Draft on passing metrics between a radio/other interface
and the router layer.

Any comments or other issues please let me know.

-Joe
_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet

********************************************************************
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.
********************************************************************
Stan Ratliff | 1 Jul 19:43 2010
Picon

Re: Draft Agenda Items

Chris,

Not published as of yet. We are working on it; will submit ASAP.

Regards,
Stan

On Jul 1, 2010, at 9:26 AM, Dearlove, Christopher (UK) wrote:

> Is Stan's draft published?
>
> --  
> 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: manet-bounces <at> ietf.org [mailto:manet-bounces <at> ietf.org] On Behalf
> Of Joe Macker
> Sent: 01 July 2010 13:42
> To: manet <at> ietf.org
> Subject: [manet] Draft Agenda Items
>
>
>                    *** WARNING ***
>
>  This message has originated outside your organisation,
>  either from an external partner or the Global Internet.
>      Keep this in mind if you answer this message.
>
>
> I would like to finalize the draft agenda as soon as possible for
> Maastricht.
> Authors on WG and related items please let me know your present  
> status.
>
>
> Our presentation priorities are related to present WG documents so  
> those
> will go first.
>
> I have heard from two other presenters so far that would like a small
> timeslot on related work.
>
> Jiazi Li: Multipath OLSR implementation
> Stan Ratcliff: Draft on passing metrics between a radio/other  
> interface
> and the router layer.
>
> Any comments or other issues please let me know.
>
> -Joe
> _______________________________________________
> manet mailing list
> manet <at> ietf.org
> https://www.ietf.org/mailman/listinfo/manet
>
>
> ********************************************************************
> 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
> manet <at> ietf.org
> https://www.ietf.org/mailman/listinfo/manet
Joe Macker | 1 Jul 21:33 2010
Picon
Picon

Fwd: Draft Agenda Items

I would like the mailing list to comment first on the idea.
Since there is a draft to read and it deals with existing WG protocols it seems within scope..
but I personally am on vacation and have not read the draft..

Comments please.  

-Joe

Begin forwarded message:

> From: "Ramrekha, Arvind" <A.Ramrekha <at> kingston.ac.uk>
> Date: July 1, 2010 10:58:16 AM EDT
> To: Joe Macker <joseph.macker <at> nrl.navy.mil>
> Subject: Re: [manet] Draft Agenda Items
> 
> Dear Joe,
> 
> I would like to please request a small timeslot to make a brief presenation on my submitted draft on using a
cognitive and adaptive module for MANETs that could help in designing hybrid protocols. I briefly
describe a hybrid of OLSRv2 and DYMO as an example of how this MAY be utilized in future. I would like to make
the participants aware of the materials present in the draft so that we can then further discuss in the
mailing list if possible.
> 
> The draft is available at: https://datatracker.ietf.org/doc/draft-ramrekha-manet-cam/
> 
> Please let me know whether this is possible.
> 
> Kind regards
> 
> Arvind.
> 
>> Tipu Arvind Ramrekha
>> PhD Student
>> Wireless Multimedia and Networking Research Group
>> Faculty of CISM
>> Kingston University London KT12EE
> 
> 
> 
> 
> 
> On 1 Jul 2010, at 13:42, Joe Macker wrote:
> 
>> I would like to finalize the draft agenda as soon as possible for Maastricht.
>> Authors on WG and related items please let me know your present status.  
>> 
>> Our presentation priorities are related to present WG documents so those will go first.
>> 
>> I have heard from two other presenters so far that would like a small timeslot on related work.
>> 
>> Jiazi Li: Multipath OLSR implementation
>> Stan Ratcliff: Draft on passing metrics between a radio/other interface and the router layer.
>> 
>> Any comments or other issues please let me know.
>> 
>> -Joe
>> _______________________________________________
>> manet mailing list
>> manet <at> ietf.org
>> https://www.ietf.org/mailman/listinfo/manet
>> 
>> This email has been scanned for all viruses by the MessageLabs Email
>> Security System.
> 
> 
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.
> 
Ulrich Herberg | 2 Jul 00:08 2010

Re: MANET routing module: draft-ramrekha-manet-cam-00.txt

Hi,

are there any concrete examples and evaluations how this module can improve the performance of MANET routing protocols, or how it could simplify parametrization of these protocols? Is there any implementation of CAM?

Ulrich

On Thu, Jun 24, 2010 at 3:18 AM, Ramrekha, Arvind <A.Ramrekha <at> kingston.ac.uk> wrote:
Dear all,

We have submitted a personal I-D :

Filename: draft-ramrekha-manet-cam-00.txt
Link:  http://www.ietf.org/id/draft-ramrekha-manet-cam-00.txt

We feel that it presents materials about MANET routing protocols (design features e.g. configurable adaptive and hybrid components) and thus should be considered by the MANET WG.

The Cognitive and Adaptive Module (CAM) for MANET routing protocols is a module that helps in logically segmenting protocol features such as done by NHDP to make them cognitive and adaptive.
This in turn SHOULD help in developing hybrid and adaptive protocols for dynamic mobile ad hoc networks. CAM SHOULD also make MANET routing protocols more (auto) configurable to suit different use cases and encourage the use of MANETs for a wider range of scenarios. This draft also presents the design of the hybrid CML protocol (based on OLSRv2 and DYMO features) using CAM.

Please provide us with feedback related to this draft.

Kind regards,

Arvind.

Tipu Arvind Ramrekha (PhD Student)
Wireless & Multimedia Networking (WMN) Research Group
Faculty of Computing, Information Systems & Mathematics, Kingston University London
Kingston upon Thames
Tel: +44 (0)20 84177025
www.kingston.ac.uk/cism

This email has been scanned for all viruses by the MessageLabs Email
Security System.
_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet

_______________________________________________
manet mailing list
manet <at> ietf.org
https://www.ietf.org/mailman/listinfo/manet
Ramrekha, Arvind | 2 Jul 04:36 2010
Picon

Re: MANET routing module: draft-ramrekha-manet-cam-00.txt

Hi

>>are there any concrete examples and evaluations how this module can improve the performance of MANET
routing protocols, or how it could simplify parametrization of these protocols? 
Currently, no. But we should shortly have some research based analysis of such a module with initial
simulation results. In addition, such a module will give similar benefits to that obtained when
segmenting Hello messaging from OLSR into NHDP. It could in a way be regarded as an extension of such work
where we would allow implementors to develop their own protocol components while protocols remain
interoperable. This may be particularly useful for the application of MANETs in different scenarios
where user's requirements differ. For example, ETX metric based routing could be very efficient in user
domains where the applications are (delay tolerant, loss intolerant) but not efficient for (delay
intolerant, loss tolerant) user applications. Another example cited is bursty traffic environmen
 ts where OLSR or OLSRv2 proactive route maintenance would not be a green solution if data traffic profile is
bursty and sparse.
We also mention a probable use case for OLSRv2, DYMO and NHDP components. 

>>Is there any implementation of CAM?
We are currently working towards implementing such a module to facilitate hybridisation of MANET routing
protocols and promoting cross operability of MANET routing protocols. 

We are specifically interested in developing the twining of the ETX metric with another QoS metric so that
it could be more suitable for real time applications in MANETs. Is the consideration of the ETX metric
alone sufficient to support such applications in a mobile environment? 

Kind regards

Arvind.
________________________________________
From: Ulrich Herberg [ulrich <at> herberg.name]
Sent: 01 July 2010 23:08
To: Ramrekha, Arvind
Cc: manet <at> ietf.org; Millar, Grant P; Politis, Christos; Panaousis, Emmanouil
Subject: Re: [manet] MANET routing module: draft-ramrekha-manet-cam-00.txt

Hi,

are there any concrete examples and evaluations how this module can improve the performance of MANET
routing protocols, or how it could simplify parametrization of these protocols? Is there any
implementation of CAM?

Ulrich

On Thu, Jun 24, 2010 at 3:18 AM, Ramrekha, Arvind
<A.Ramrekha <at> kingston.ac.uk<mailto:A.Ramrekha <at> kingston.ac.uk>> wrote:
Dear all,

We have submitted a personal I-D :

Filename: draft-ramrekha-manet-cam-00.txt
Link:  http://www.ietf.org/id/draft-ramrekha-manet-cam-00.txt

We feel that it presents materials about MANET routing protocols (design features e.g. configurable
adaptive and hybrid components) and thus should be considered by the MANET WG.

The Cognitive and Adaptive Module (CAM) for MANET routing protocols is a module that helps in logically
segmenting protocol features such as done by NHDP to make them cognitive and adaptive.
This in turn SHOULD help in developing hybrid and adaptive protocols for dynamic mobile ad hoc networks.
CAM SHOULD also make MANET routing protocols more (auto) configurable to suit different use cases and
encourage the use of MANETs for a wider range of scenarios. This draft also presents the design of the
hybrid CML protocol (based on OLSRv2 and DYMO features) using CAM.

Please provide us with feedback related to this draft.

Kind regards,

Arvind.

Tipu Arvind Ramrekha (PhD Student)
Wireless & Multimedia Networking (WMN) Research Group
Faculty of Computing, Information Systems & Mathematics, Kingston University London
Kingston upon Thames
Tel: +44 (0)20 84177025
www.kingston.ac.uk/cism<http://www.kingston.ac.uk/cism>

This email has been scanned for all viruses by the MessageLabs Email
Security System.
_______________________________________________
manet mailing list
manet <at> ietf.org<mailto:manet <at> ietf.org>
https://www.ietf.org/mailman/listinfo/manet

This email has been scanned for all viruses by the MessageLabs Email
Security System.

This email has been scanned for all viruses by the MessageLabs Email
Security System.
Teco Boot | 2 Jul 08:17 2010
Picon

Re: Metric encoding for OLSRv2


Op 1 jul 2010, om 15:25 heeft Dearlove, Christopher (UK) het volgende geschreven:

> The current proposal is in the middle of the range
> logarithmically, rather than arithmetically (I would
> prefer a=0,b=15 to a=0, b=14). I can (otherwise we
> wouldn't have proposed it) see some logic to that.
> 
> There is another value worth considering, and that
> is the maximum value. This has the potential advantage
> of clarity over that there are two different default
> concepts
> 
> - The "don't need to signal a metric thus saving
>  octets" value, and
> 
> - The "I haven't been able to work out what a good metric
>  valus is yet, so let's use this" value.
> The latter should almost certainly be the maximum value.

This depends on the configuration.
The default for 10/100/1000/10000 Ethernet, where
rate is not known, should not be the max value, I think.

In general, we are in a discussion on guidelines, on what
cost value to use for what class / state of a link.
I think it is helpful to have an informational document,
with examples of (at a minimum) 802.3 and 802.11.

> The former really only has two purposes
> 
> - If there is an often used value.
> 
> - For hop count.
> 
> Note that for pure hop count it is irrelevant what the default
> value is. If you are going to have cases where e.g you signal
> double hops then maximum is the worst value - and the best
> value is probably the minimum value (excluding zero, if zero
> is included). And that is another candidate.
> 
> Incidentally inclusion of zero makes a change to OLSRv2.
> It means that you MUST pick the fewest hop route among those
> with the same metric. Without it, that becomes a SHOULD,
> or even a MAY.

As far as I understand, nobody asked for zero for OLSR.
The idea was having a generic coding scheme, and some
protocols do require a zero value (Henning says so ...).
The OLSRv2-metrics document could specify that zero MUST NOT
be used. 
Same could be specified for a max value = DoNotUse. This
leaves 254 codepoints for OLSRv2.

Teco.

Gmane