Subject: [Manet-dt] Comments for the SMFdraft 01

From: Maoyu Wang <[email-masked]>
Date: Wed, 02 Nov 2005 15:12:41 -0500

Hello, All
After the implementation of SMF and some tests in a MANET, we are 
considering about adding the border gateway functionality to SMF. I have 
some initial considerations about the SMF Multicast Border Gateway and 
like to use it as the first stone to rise more discussions and opinions 
about the SMF Gateway.  This time, I cannot attend the IETF meeting in 
Vancouver since it conflicts with a conference.  Wish Joe gets well 
sooner.  Wish everyone have a good time in Vancouver.

Following is the considerations:
<>

6.  SMF Multicast Border Gateway Considerations

6.1  Forwarded Multicast Groups

<>   Determining which groups should be forwarded to or from a MANET SMF 
area presents challenges.  Ideally, only groups for which there is 
active group membership should be injected into the SMF domain.  This 
might be accomplished by providing an IPv4 Internet Group Membership  
Protocol (IGMP) or IPV6 Multicast Listener Discovery (MLD) proxy 
function so that MANET SMF nodes can inform attached gateways (and hence 
multicast networks) of their current group membership status.

<>Consideration:
Propagating IGMP or MLD in MANET means propagating packets with Link 
Local address in MANET? Is that appropriate? Instead of that, Should we 
define some SMF control message to propagate the membership status? How 
is everyone' opinion?  

6.2  Multicast Group Scoping

  (TBD)
Consideration:
 My suggestion for IPv6: Any packet with destination starting with 
ff05::/32 is restricted in MANET. Packets with destination starting with 
ff0e::/32 are forwarded to outside of the MANET before any new address 
scopes are defined.

6.3  Duplicate Packet Detection Marking

<>   Packets sourced external to an SMF area may not have duplicate 
packet sequencing properly applied and the gateway may need to provide 
that sequencing information upon entry to the network.  In the case of 
IPv6, the gateway can apply the SMF DPD Hop-by-Hop options header to 
packets forwarded into the MANET area for those packets that do not 
already have the option applied.  This header option provides the side 
benefit that the gateway can explicitly determine if the packet has 
already been marked and can use the packet identification field to 
determine that it is not re-injecting a duplicate packet. <>

Consideration:
 A gateway marks an external sourced multicast packet based on its 
<sourceAddress::destinationAddress>. Each 
<sourceAddress::destinationAddress> uses a sequence number space 
increasing from 0. There is a lifetime after a sequence number space is 
used last time. After the lifetime is expired, the sequence number space 
for the source address should increase from 0 again. The strategy will 
benefit multiple gateways. Keep multiple gateways add the sequence 
number at the same starting number. Details are in next " 6.5 multiple 
gateways" part.  <> 

 For IPv4, it is RECOMMENDED that gateway nodes re-sequence the ID field 
of packets injected into the area.  However, the IPv4 ID field does not 
provide the gateway with explicit information on whether the field has 
been previously set for SMF purposes.  Thus, in cases where the 
potential exists that duplicate packets may be re-injected by a gateway 
into an SMF area, it may be desirable to use a more explicit marking 
such as the alternative IPv4 DPD header option described in Section 
4.1.1. <> 

 _(If multiple gateways are injecting packets, how do we make sure  that 
dups are sequenced the same way? )_

 Please see "multiple gateways" for the suggestion.

6.4  Interface with Exterior Multicast Routing Protocols

   (TBD)

6.5 Multiple Gateways

Consideration:

When multicast packet enters the MANET from outside, we don't need 
multiple gateways injecting the same multicast packet. The main strategy 
should be how to keep a gateway injects the multicast packets instead of 
all gateways injecting the same multicast packet.

There is a gateway flag in each duplicate entry indicating that if this 
entry is originally generated by this gateway or by other nodes. When it 
is the first time to receive a packet from this external source with the 
<sourceAddress::destinationAddress>, before labeling any ingressing 
packets, a gateway checks if there is a duplicate entry for the 
<sourceAddress::destinationAddress>  and if its gateway flag indicates 
that this entry represents a duplicate packet not originally marking by 
this gateway. If yes, the multicast packet already enters MANET through 
other gateway, the gateway would not bother to mark the ingressing 
packet from this source address and has the 
<sourceAddress::destinationAddress>. Otherwise, labeling the ingressing 
packet with a sequence number start from 0.  If two gateways almost 
receive the same multicast packet from the same external source, they 
will mark the same packet by the same sequence number. The DPD works 
fine.  Sooner or later, if one gateway finds a external sourced packet 
has a entry in the duplicate table and its sequence number is bigger 
than current its own sequence number for the same external sourced node, 
it will stop marking multicast packet from the same source addresses. 
However, the gateway should keep update the lifetime for the  
<sourceAddress::destinationAddress> every time when it inserts an entry 
with <sourceAddress::destinationAddress> in its duplicate table because 
receiving a copy from other gateway. After the lifetime for 
<sourceAddress::destinationAddress> is expired, the 
<sourceAddress::destinationAddress> will be removed. Sequence number 
will start from 0 again. Otherwise, if the lifetime for 
<sourceAddress::destinationAddress> is not expired, this gateway does 
not mark any ingressing packets with the 
<sourceAddress::destinationAddress>.

When packets enter outside network from MANET, how can we keep only a 
gateway removes the DPD part used in MANET and sends the multicast 
packet out instead of multiple copies of the same packet are sent from 
multiple gateways? Before a gateway remove the DPD part, checking if a 
multicast packet with the same <sourceAddress::destinationAddress> has 
been received from outside network? If yes, other gateway already take 
care of the group of multicast packets, this gateway doesn't need to 
forward the packet with the same <sourceAddress::destinationAddress>. 
Otherwise, the gateway removes the DPD part, and forwards it to outside 
network. If two gateways almost remove the DPD parts at the same time 
and forwarding the multicast packet into outside network, sooner or 
later, they will notice that. However, there is no way to decide who 
should stop.  Without extra control message exchanges between the 
gateway, there is no way to stop multiple copies of the same packet 
injecting to outside network because there is no DPD at the routing 
layer for other multicast routing protocol.

_______________________________________________
Manet-dt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet-dt

---

From: "Pedro M. Ruiz" <[email-masked]>
Date: Thu, 03 Nov 2005 12:42:42 -0800

Hi,

Please find some comments below... If any of you is interested to talk 
about this I'll be in Vancouver from Tuesday to Thrusday right after 
MANET-WG meeting. By the way Joe, I hope you get well soon.

Maoyu Wang wrote:

> considering about adding the border gateway functionality to SMF. I 
> have some initial considerations about the SMF Multicast Border 
> Gateway and like to use it as the first stone to rise more discussions 
> and opinions about the SMF Gateway.  This time, I cannot attend the 
> IETF meeting in Vancouver since it conflicts with a conference.  Wish 
> Joe gets well sooner.  Wish everyone have a good time in Vancouver.
>
> <>   Determining which groups should be forwarded to or from a MANET 
> SMF area presents challenges.  Ideally, only groups for which there is 
> function so that MANET SMF nodes can inform attached gateways (and 
> hence multicast networks) of their current group membership status.
>
> <>Consideration:
> Local address in MANET? Is that appropriate? Instead of that, Should 
> we define some SMF control message to propagate the membership status? 
> How is everyone' opinion?   

There is some previous work we have been doing on this particular aspect 
from the last three years. After many internal discussions, we found 
that propagating MLD or IGMP messages is not a good idea (too much 
overhead). What we did is embbed the group membership information into 
routing messages. Then, ad hoc nodes in the fringe of the MANET (one hop 
away from an standard multicast acess router [we called them MIGs]) 
generate appropriate IGMP/MLD messages to join the required mcast groups.

This requires no changes to routing nor group membership in the fixed 
network, and it can work with existing routers.

We already have this scheme implemented in Linux both for IPv4 and IPv6, 
integrated with a mesh-based multicast routing protocol called MMARP. 
The current version includes a mesh optimization to reduce the number of 
forwarding operations required, and it also includes some security 
extensions to avoid forging of routing messages.

As I told to Joe in Washington's IETF, I'd be up for talking about how 
integrate these ideas into SMF design at any time.

Please find below some links which I think might be useful to get 
details on what I summarized above:

Pedro M. Ruiz, Antonio F. Gomez-Skarmeta, "Integrated IP Multicast in 
Mobile Ad Hoc Networkis with Multiple Attachments to Wired IP Networks", 
In proc. of the 15th IEEE Symposium on Personal, Indoor and Mobile Radio 
Communications (PIMRC-2004), Barcelona, 5-8 Sept. 2004. 
(http://ants.dif.um.es/staff/pedrom/papers/Ruiz-PIMRC04.pdf)

Pedro M. Ruiz, Antonio F. Gomez-Skarmeta, Ian Groves. "Multicast Routing 
for MANET Extensions to IP Access Networks: The MMARP Protocol". In 
proceedings of the International Mobile IP-based Network Developments 
(MIND) Workshop. 7th October, 2002. London, UK. 
(http://ants.dif.um.es/staff/pedrom/papers/WS-WP2-MMARP-doc.pdf)

Pedro M. Ruiz, Antonio F. Gómez Skarmeta, " Mobility-Aware Mesh 
Construction Algorithm for Low Data-Overhead Multicast Ad Hoc Routing," 
Journal of Communications and Networks (JCN), Vol. 6, no. 4, December 
2004, pp. 331-342.(http://ants.dif.um.es/staff/pedrom/papers/Ruiz-JCN.pdf)

> ff05::/32 is restricted in MANET. Packets with destination starting 
> with ff0e::/32 are forwarded to outside of the MANET before any new 
> address scopes are defined. 

This is fine to me.

> increasing from 0. There is a lifetime after a sequence number space 
> is used last time. After the lifetime is expired, the sequence number 
> space for the source address should increase from 0 again. The 
> strategy will benefit multiple gateways. Keep multiple gateways add 
> the sequence number at the same starting number. Details are in next " 
> 6.5 multiple gateways" part.  <> 

I think that the problem is that if coordinating multiple gateways to 
use the same sequence number is hard. Take into account for instance 
that if some packet is lost in the fixed network for some of the GWs, 
then its sequence number gets desynchronized. I think I'd try computing 
a hash of the message itself (excluding mutable IP fields) so that you 
can detect if a message is duplicate regardless of the gateway is is 
comming from.

Another option is just coordinate gateways so that only one joins to a 
fixed network, but in our experiments this created very long paths in 
some cases. We found much better to use many GWs, all of them joining 
the fixed networks for groups with members, and then avoiding duplicates 
within the MANET so that the traffic forwarded is exactly the same as if 
1 single GW would join. This provides more reliability, and the mean 
quality of the paths is better (very long ones are avoided).

And here I also enter into your comments of multiple GWs below :).  I 
think this scheme is very simple, and avoid a lot of control overhead. 
For instance, we made recently experiments integrating this multiple GW 
support with an autoconfiguration protocol, and this idea of splitting 
the load managed to get better performance.

Thanks for your interesting comments... I'd be glad to discuss with you 
possible design alternatives for this.

Regards, Pedro

>
>  For IPv4, it is RECOMMENDED that gateway nodes re-sequence the ID 
> field of packets injected into the area.  However, the IPv4 ID field 
> does not provide the gateway with explicit information on whether the 
> field has been previously set for SMF purposes.  Thus, in cases where 
> the potential exists that duplicate packets may be re-injected by a 
> gateway into an SMF area, it may be desirable to use a more explicit 
> marking such as the alternative IPv4 DPD header option described in 
> Section 4.1.1. <> 
>
>  _(If multiple gateways are injecting packets, how do we make sure  
> that dups are sequenced the same way? )_
>
> multiple gateways injecting the same multicast packet. The main 
> strategy should be how to keep a gateway injects the multicast packets 
> instead of all gateways injecting the same multicast packet.
>
> There is a gateway flag in each duplicate entry indicating that if 
> this entry is originally generated by this gateway or by other nodes. 
> When it is the first time to receive a packet from this external 
> source with the <sourceAddress::destinationAddress>, before labeling 
> any ingressing packets, a gateway checks if there is a duplicate entry 
> for the <sourceAddress::destinationAddress>  and if its gateway flag 
> indicates that this entry represents a duplicate packet not originally 
> marking by this gateway. If yes, the multicast packet already enters 
> MANET through other gateway, the gateway would not bother to mark the 
> ingressing packet from this source address and has the 
> <sourceAddress::destinationAddress>. Otherwise, labeling the 
> ingressing packet with a sequence number start from 0.  If two 
> gateways almost receive the same multicast packet from the same 
> external source, they will mark the same packet by the same sequence 
> number. The DPD works fine.  Sooner or later, if one gateway finds a 
> external sourced packet has a entry in the duplicate table and its 
> sequence number is bigger than current its own sequence number for the 
> same external sourced node, it will stop marking multicast packet from 
> the same source addresses. However, the gateway should keep update the 
> lifetime for the  <sourceAddress::destinationAddress> every time when 
> it inserts an entry with <sourceAddress::destinationAddress> in its 
> duplicate table because receiving a copy from other gateway. After the 
> lifetime for <sourceAddress::destinationAddress> is expired, the 
> Otherwise, the gateway removes the DPD part, and forwards it to 
> outside network. If two gateways almost remove the DPD parts at the 
> same time and forwarding the multicast packet into outside network, 
> sooner or later, they will notice that. However, there is no way to 
> decide who should stop.  Without extra control message exchanges 
> between the gateway, there is no way to stop multiple copies of the 
> same packet injecting to outside network because there is no DPD at 
> the routing layer for other multicast routing protocol.
>
>
>------------------------------------------------------------------------
>

---

From: "Joe Macker" <[email-masked]>
Date: Thu, 3 Nov 2005 17:12:52 -0500

Pedro and Maoyu:

I appreciate your comments. 
The tradeoffs in gateway interaction requires more discussion.

I would like to keep these discussions going.
It would be nice to have a side meeting on these issues to get everyone's
thoughts out. Please try to coordinate with Brian Adamson and Ian.

I can particapte remotely if needed.