Subject: [manet] I-D ACTION:draft-ietf-manet-packetbb-08.txt

From: [email-masked]
Date: Thu, 12 Jul 2007 12:15:08 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Mobile Ad-hoc Networks Working Group of the IETF.

	Title		: Generalized MANET Packet/Message Format
	Author(s)	: T. Clausen, et al.
	Filename	: draft-ietf-manet-packetbb-08.txt
	Pages		: 49
	Date		: 2007-7-12
	
This document specifies a multi-message packet format that may be
   used by mobile ad hoc network routing and other protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-packetbb-08.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-manet-packetbb-08.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-manet-packetbb-08.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Jul 2007 10:56:44 -0400

Thomas:

In the Address Block Examples section, could you please add examples
that include IPv6 addresses that are based upon the head/tail-length?
This would help validate the intended flexibility of the address block.

And if possible, could you add a paragraph or two on the suggestions
or requirements when building the address block as well as parsing
and validating the address entries.

Thanks
-Bo Berry
Cisco
RTP, NC

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 25 Jul 2007 17:00:25 +0200

Bo,

Thanks for your comment.

I'd be happy to do so -- would you have any preferences for *which*  
examples you'd like to see, or shall I just take my best pick?

Cheers,

Thomas

-- 
Thomas Clausen
[email-masked]
http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
http://www.lix.polytechnique.fr/hipercom/

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Jul 2007 11:06:09 -0400

Thomas:

There are many scenarios in the manet RFCs and drafts that you can choose
from.  These would demonstrate 'real' examples.

Thanks
-Bo

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 25 Jul 2007 08:47:41 -0700

John Heffner's document on "IPv4 Reassembly Errors at High Data
Rates" talks about implications of wrapping the 'ip_id' field. The
document is now in the RFC Editor queue. Below is the abstract and
link to the draft:

Fred
[email-masked]

Abstract

   IPv4 fragmentation is not sufficiently robust for use under some
   conditions in today's Internet.  At high data rates, the 16-bit IP
   identification field is not large enough to prevent frequent
   incorrectly assembled IP fragments, and the TCP and UDP checksums are
   insufficient to prevent the resulting corrupted datagrams from being
   delivered to higher protocol layers.  This note describes some easily
   reproduced experiments demonstrating the problem, and discusses some
   of the operational implications of these observations.

http://www.ietf.org/internet-drafts/draft-heffner-frag-harmful-05.txt

---

From: Bo Berry <[email-masked]>
Date: Wed, 25 Jul 2007 23:06:21 -0400

Manet WG

As we begin the discussions on the two link metric drafts

  OLSRv2 Update + Link Metrics for OLSRv2
  http://www3.ietf.org/proceedings/07jul/slides/manet-9.pdf

  Metrics TLV - Dean
  http://www3.ietf.org/proceedings/07jul/slides/manet-8.pdf

it would be useful, as Teco mentioned, to review previous
link metric work.

One reference can be found in

  RFC 4938, PPP Over Ethernet (PPPoE) Extensions for Credit
  Flow and Link Metrics

Here we used PPPoE links to logically connect a radio to
OSPF. Very simply, the radio link metrics are periodically
reported to the router.  The router translates the link metrics
into a link cost and injects the new cost into OSPF
to influence routing.

Key considerations

-There are many radio transceiver encoding schemes, 802.11 based
 schemes are one.  That being the case, we let the radio manage
 the RF links with periodic link metric reports.   The link
 metrics were boiled down to an abstract list that the local
 node can process without having to build in a lot of radio know-how.

-The radio links are under constant change due to the nature
 of RF.  Given this environment, there is a need for heuristics
 in the radio to throttle link metric reports.

-Because routing protocols have different definitions of link cost,
 it was important to be able to translate the link metrics
 into a link cost for each routing protocol.  This code is
 really associated with the routing protocol.

-When link metrics are translated into a new routing cost,
 heuristics were again needed to throttle the effective change in
 link cost to avoid excessive flooding.  For example,
 if the newly computed link cost is 1 point change, is there
 really a need to flood the network?

Hope this reference helps
-Bo

---

From: Philip Levis <[email-masked]>
Date: Mon, 30 Jul 2007 23:23:34 -0700

>  really a need to flood the network?

There has been a great deal of work in the research community on this  
topic in the past few years, mostly due to the fact that hopcount  
does not capture intermediate links, asymmetric links, or temporally  
varying links. Given the desire for internetworking in heterogeneous  
networks (or even in networks with dynamic bitrates such as 11.b),  
ETT [Draves, Mobicom 2004] is generally a good approach, but it  
assumes layer 2 retransmissions. Fundamentally, what you find is that  
purely hello/broadcast approaches don't work well, as they don't  
adapt quickly to link changes and cause a lot of packets to be lost.

Some starting points for the wireless place include:

Aguayo, D., Bicket, J., Biswas, S., Judd, G., and Morris, R.
Link-level measurements from an 802.11b mesh network.
In Proc. of the ACM SIGCOMM Conf., 2004

Couto, D.~D., Aguayo, D., Bicket, J., and Morris, R.
A High-Throughput Path Metric for Multi-Hop Wireless Routing.
In Proc. of the ACM MobiCom Conf.,  2003.

Draves, R., Padhye, J., and Zill, B.
Comparison of routing metrics for static multi-hop wireless networks.
In Proc. of the ACM SIGCOMM Conf., 2004

Draves, R., Padhye, J., and Zill, B.
Routing in Multi-Radio, Multi-Hop Wireless Mesh Networks.
In Proc. of the ACM MobiCom Conf., 2004.

Kim, K.-H., and Shin, K.
On Accurate Measurement of Link Quality in Multi-hop Wireless Mesh  
Networks.
In Proc. of the ACM MobiCom Conf., 2006.

Kim, M., and Noble, B.
Mobile Network Estimation.
In Proc. of the ACM MobiCom Conf., 2001.

Koksal, C.~E., and Balakrishnan, H.
Quality-Aware Routing Metrics for Time-Varying Wireless Mesh Networks.
IEEE Journal of Selected Areas in Communications, Nov 2006.

Srinivasan, K., and Levis, P.
RSSI is Under Appreciated.
In Proceedings of the Third ACM Workshop on Embedded Networked  
Sensors (EmNets), 2006.

Srinivasan, K., Dutta, P., Tavakoli, A., and Levis, P.
Some Implications of Low-Power Wireless to IP Routing
In Proceedings of HotNets V, 2006.

Woo, A., and Culler, D.
Evaluation of Efficient Link Reliability Estimators for Low-Power   
Wireless Networks.
Tech. Rep. CSD-03-1270, {UC Berkeley}, May 2004.

Zhao, J., and Govindan, R.
Understanding Packet Delivery Performance in Dense Wireless Sensor  
Networks.
In Proc. of the ACM SenSys Conf., 2003.

Phil