Subject: [manet] I-D ACTION:draft-ietf-manet-smf-00.txt

From: [email-masked]
Date: Thu, 14 Jul 2005 15:50:02 -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		: Simplified Multicast Forwarding for MANET
	Author(s)	: J. Macker
	Filename	: draft-ietf-manet-smf-00.txt
	Pages		: 19
	Date		: 2005-7-14
	
   This document describes the Simplified Multicast Forwarding (SMF)
   protocol that provides a basic IP multicast forwarding capability
   within mobile ad-hoc networks.  While it supports edge
   interoperability with a conventional IP multicast infrastructure, SMF
   is designed to have limited applicability as a forwarding mechanism
   for multiple hop multicast packets within MANET routing areas.  SMF
   uses a simplified forwarding mechanism that delivers multicast
   packets to all MANET multicast receivers within a MANET routing area.
   The core design does not use group and membership specific
   information in favor of reduced complexity and state maintenance
   within the mobile topology region.  The design accounts for the
   unique nature and behavior of MANET interfaces and takes advantage of
   particular efficient relay set algorithms previously designed and
   applied in the MANET routing designs.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-manet-smf-00.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-smf-00.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-smf-00.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: Li Li <[email-masked]>
Date: Thu, 21 Jul 2005 13:16:49 -0400

I'm reading the SMF draft. Thanks for the draft on this important feature 
and the draft is very well written. I quite agree with the approaches 
proposed in the draft. But I'm having one question here.

  In order to determine the packet sending node, if as required in making 
the forwarding decision, using the mac address information doesn't seem to 
be a native IP forwarding behavior. How about carrying the sender's IP 
address in the Hop-by-hop options header, as it already carries the 
sequence number generated by the originator of the packet? This would save 
us from messing with the mac layer info. Is it a concern that if IPsec is 
used then the hop-by-hop options header may not be useful to carry the 
info? Even for the sequence number, putting it in the hop-by-hop options 
header may not work when IPsec is used, as discussed in the draft? Based on 
my very limited understanding of IPsec, both AH and ESP headers are placed 
after the hop-by-hop options header in the packet. If my memory serves me, 
both of them would leave out the mutable headers, such as the hop-by-hop 
header, when they do the authentication or the encryption. (May be a bit 
different in the tunnel mode but are we considering the tunnel mode here?).

I must have missed something here. :) Any corrections are most appreciated.