Subject: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00

From: "Thomas C. Schmidt" <[email-masked]>
Date: Sat, 13 Jun 2009 23:26:41 +0200

Dear all,

  multicast support for PMIPv6 domains has been one of the most debated
  issues for Multimob, and at the same time some divergent understanding
  of the topic arose.

  As promised earlier, we have now prepared a document defining
  multicast listener support in PMIPv6 domains solely on the basis of
  standardized IETF protocols (see below): 
http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt 

  It assigns the role of MLD proxies to MAGs and standard MLD queriers
  to LMAs, and we believe this is the minimal solution solely based on
  standard protocol behavior.

  At the price of "full multicast" functions at MAG and LMA, this
  approach provides some (but not all possible) traffic aggregations.

  In parallel, I should point on an alternative approach published earlier:
http://tools.ietf.org/html/draft-gundavelli-multimob-pmip6basicmcast-solution

  This approach uses minimal, but non-standard MLD forwarding at the MAG 
and
  individual, unidirectional data tunneling from LMA to MN. MLD support 
at the
  MAG is thus more lightweight on the price of a complete loss of traffic
  aggregation.

  Both drafts should serve as a good starting point for defining a "minimal
  multicast standard" in PMIPv6 - and for discussions prior to the BoF 
in Stockholm.

Looking forward to your comments!

Thomas

---------------------------- snip ----------------------------------

A new version of I-D, 
draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has been 
successfuly submitted by Thomas Schmidt and posted to the IETF repository.

Filename:	 draft-schmidt-multimob-pmipv6-mcast-deployment
Revision:	 00
Title:		 A Minimal Deployment Option for Multicast Listeners in PMIPv6 
Domains
Creation_date:	 2009-06-13
WG ID:		 Independent Submission
Number_of_pages: 10

Abstract:
This document describes deployment options for activating multicast
listener functions in Proxy Mobile IPv6 domains without modifying
mobility and multicast protocol standards.  Similar to Home Agents in
Mobile IPv6, PMIPv6 Local Mobility Anchors serve as multicast
subscription anchor points, while Mobile Access Gateways provide MLD
proxy functions.  In this scenario, Mobile Nodes remain agnostic of
multicast mobility operations.

-- 

Prof. Dr. Thomas C. Schmidt
° Hamburg University of Applied Sciences                   Berliner Tor 7 °
° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
° http://www.haw-hamburg.de/inet                   Fon: +49-40-42875-8452 °
° http://www.informatik.haw-hamburg.de/~schmidt    Fax: +49-40-42875-8409 °

---

From: Liu Hui <[email-masked]>
Date: Mon, 15 Jun 2009 10:45:25 +0800

Hi Thomas,

I  have a question and a comment. 

AFAIK,  the standard IGMP/MLD proxy  (MAG in the draft)  usually sends summary report to its upstream equipment.  Thus the source address of the report should be set to the address of MAG but not the address of MN.  If this is the case, how LMA tell which MN triggers the report ? Is it possible to realize explicit tracking on LMA for each MN in this solution?

In section 3,  multicast data will "flow from the LMA to the MN on an LMA-specific shared tree."   It seems not very clear  what this shared tree is.  Is it the tunnel from LMA to MAG?  Because multicast routing protocol are not involved here, it it better not to use shared tree here.

Best Regards,
Liu Hui

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Thomas C. Schmidt
> Sent: Sunday, June 14, 2009 5:27 AM
> To: [email-masked]
> Subject: [multimob] New Version Notification 
> fordraft-schmidt-multimob-pmipv6-mcast-deployment-00
> 
> Dear all,
> 
>   This approach uses minimal, but non-standard MLD forwarding 
> at the MAG and
>   individual, unidirectional data tunneling from LMA to MN. 
> MLD support at the
>   multicast standard" in PMIPv6 - and for discussions prior 
> to the BoF in Stockholm.
> 
> draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt has 
> been successfuly submitted by Thomas Schmidt and posted to 
> the IETF repository.
> 
> This document describes deployment options for activating 
> multicast listener functions in Proxy Mobile IPv6 domains 
> without modifying mobility and multicast protocol standards.  
> Similar to Home Agents in Mobile IPv6, PMIPv6 Local Mobility 
> Anchors serve as multicast subscription anchor points, while 
> Mobile Access Gateways provide MLD proxy functions.  In this 
> scenario, Mobile Nodes remain agnostic of multicast mobility 
> operations.
>  
> 
> 
> 
> -- 
> 
> _______________________________________________
> multimob mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/multimob
>

---

From: Matthias Waehlisch <[email-masked]>
Date: Mon, 15 Jun 2009 13:49:42 +0200

Hi Liu,

On Mon, 15 Jun 2009, Liu Hui wrote:

> AFAIK, the standard IGMP/MLD proxy (MAG in the draft)  usually sends 
> summary report to its upstream equipment.
>
  yes, MLD reports based on the RFC4605-membership database.

> Thus the source address of the report should be set to the address of 
> MAG but not the address of MN.  If this is the case, how LMA tell which 
> MN triggers the report ? Is it possible to realize explicit tracking on 
> LMA for each MN in this solution?
>
  Hm, maybe you are right: the explicit tracking is bound to the proxy, 
i.e., MAG due aggregation based on RFC4605. We will rethink it. However, 
the explicit tracking is a minor optimization. The general operation is 
not affected by this.

> In section 3, multicast data will "flow from the LMA to the MN on an 
> LMA-specific shared tree."  It seems not very clear what this shared 
> tree is.  Is it the tunnel from LMA to MAG?  Because multicast routing 
> protocol are not involved here, it it better not to use shared tree 
> here.
>
  The intention was to highlight that multicast data cannot flow following 
a source specific path between multicast sender and MN but via the LMA.

Thanks for your comments
  matthias

-- 
Matthias Waehlisch
.  FU Berlin, Inst. fuer Informatik, AG CST
.  Takustr. 9, D-14195 Berlin, Germany
.. mailto:[email-masked] .. http://www.inf.fu-berlin.de/~waehl
:. Also: http://inet.cpt.haw-hamburg.de .. http://www.link-lab.net

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Mon, 15 Jun 2009 23:37:46 +0200

Hi Liu,

> AFAIK,  the standard IGMP/MLD proxy  (MAG in the draft)  usually sends summary report to its upstream equipment.  Thus the source address of the report should be set to the address of MAG but not t…

As Matthias already wrote: you're right, we have been too quick and 
assuming knowledge of the MN at the LMA is a lapse. Thanks for the hint.

So, explicit tracking is actually not an option - we will remove this. 
However, the base scheme is unaffected, as reports and querying work.

> In section 3,  multicast data will "flow from the LMA to the MN on an LMA-specific shared tree."   It seems not very clear  what this shared tree is.  Is it the tunnel from LMA to MAG?  Because mul…

Well, that's a matter of taste - we can remove shared tree, if you 
think. There is tree built from the LMA to (one or several) MAGs and 
further to (one or several) MNs, which is shared among sources. So it 
actually is a shared tree, but not erected by PIM-SM, that's right. We 
should probably state this more explicit.

Thanks for your valuable comments!

Thomas

--

---

From: Liu Hui <[email-masked]>
Date: Tue, 16 Jun 2009 15:42:55 +0800

Hi Thomas and Matthias,
 
If explicit tracking for each MN is not required, the solution should have no problem.  This MAG proxy method has the advantage that least reports could be sent from MAG to LMA.

Personally I think it is still possible for LMA to explicitly tracking each MAG, which may still be useful in practical application.  Thus I suggest explicit tracking feature could be preserved between MAG and LMA, with original illustration revised.  

Best Regards,
Liu Hui    

> 
> > AFAIK,  the standard IGMP/MLD proxy  (MAG in the draft)  
> usually sends summary report to its upstream equipment.  Thus 
> the source address of the report should be set to the address 
> of MAG but not the address of MN.  If this is the case, how 
> LMA tell which MN triggers the report ? Is it possible to 
> realize explicit tracking on LMA for each MN in this solution?
> 
> As Matthias already wrote: you're right, we have been too 
> quick and assuming knowledge of the MN at the LMA is a lapse. 
> Thanks for the hint.
>

---

From: [email-masked]
Date: Tue, 16 Jun 2009 17:00:45 +0100 (BST)

I'm trying to understand the thread:

- A device can snoop or proxy the membership control traffic. The proxy
function generates queries from within the device.

 - A proxy can proxy the reporting, which means the proxy sends a summary
report upstream on behalf of all active downstream receivers when it is
queried, and hence uses one of its own interface addresses as a source.

- To me explicit tracking is a different issue - that is when the proxy
monitors responses from each receiver (it may also send membership queries
to receivers). The aim is to know which receivers (interfaces) need to
receive each group.  This a mode that is possible in IGMPv3 and MLDv2 to
speed-up the leave process.

Are we talking about the same thing here?

Gorry

>> summary report to its upstream equipment.  Thus the source address of
>> the report should be set to the address of MAG but not the address of
>> MN.  If this is the case, how LMA tell which MN triggers the report ? Is
>> it possible to realize explicit tracking on LMA for each MN in this
>> solution?
>

---

From: Matthias Waehlisch <[email-masked]>
Date: Tue, 16 Jun 2009 23:59:53 +0200

Hi Gorry,

> function generates queries from within the device.
  agree.

>  - A proxy can proxy the reporting, which means the proxy sends a 
> summary report upstream on behalf of all active downstream receivers 
> when it is queried, and hence uses one of its own interface addresses as 
> a source.
> 
  Agree, as well.

> monitors responses from each receiver (it may also send membership 
> queries to receivers). The aim is to know which receivers (interfaces) 
> need to receive each group.  This a mode that is possible in IGMPv3 and 
> MLDv2 to speed-up the leave process.
> 
  Yes. The confusion arose as we originally thought that LMA receives 
MN-specific membership states ... Anyhow, the explicit tracking is not 
specifically helpful to PMIP-multicast case. Sorry for the confusion.

Cheers
  matthias

---

From: jouni korhonen <[email-masked]>
Date: Thu, 18 Jun 2009 19:15:49 +0300

Hi Thomas,

One comment regarding the *-mcast-deployment-00 I-D. It would benefit  
greatly readability of this I-D and help to understand the exact MLD  
proxy behavior if MLD report/query/etc messages' source and  
destination addresses were listed in each case and both sides of the  
MAG. Something like what RFC2710 did.

Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd  
that it has new requirements to MNs apart from supporting certain MLD  
version. Also I do not understand what the first sentence in Section  
5. is about. Where is that requirement said?

Finally, what is the point of describing two different MLD handling  
behaviors for a MAG in these two I-Ds, when both obviously require  
changes to the MAG. Or did I miss something? ;)

Cheers,
	Jouni

On Jun 14, 2009, at 12:26 AM, Thomas C. Schmidt wrote:

> standardized IETF protocols (see below): http://www.ietf.org/internet-drafts/draft-schmidt-multimob-pmipv6-mcast-deployment-00.txt
>
> This approach uses minimal, but non-standard MLD forwarding at the  
> MAG and
> individual, unidirectional data tunneling from LMA to MN. MLD  
> support at the
> A new version of I-D, draft-schmidt-multimob-pmipv6-mcast- 
> deployment-00.txt has been successfuly submitted by Thomas Schmidt  
> and posted to the IETF repository.
>
> Title:		 A Minimal Deployment Option for Multicast Listeners in  
> PMIPv6 Domains

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Jun 2009 09:33:55 -0700 (PDT)

Hi Jouni,
  Thanks for your comments.
Let me answer the part on *-pmip6basicmcast-solution below.

Regards,

Behcet

----- Original Message ----
From: jouni korhonen <[email-masked]>
To: Thomas C. Schmidt <[email-masked]>
Cc: [email-masked]
Sent: Thursday, June 18, 2009 11:15:49 AM
Subject: Re: [multimob] New Version Notification for draft-schmidt-multimob-pmipv6-mcast-deployment-00

Hi Thomas,

One comment regarding the *-mcast-deployment-00 I-D. It would benefit greatly readability of this I-D and help to understand the exact MLD proxy behavior if MLD report/query/etc messages' source and destination addresses were listed in each case and both sides of the MAG. Something like what RFC2710 did.

Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd that it has new requirements to MNs apart from supporting certain MLD version. Also I do not understand what the first sentence in Section 5. is about. Where is that requirement said?

[behcet] If you look at Section 6.10.5.  Forwarding Rules in RFC 5213,
it says: 

However, the packets that are sent
      with the link-local source address MUST NOT be forwarded.

As it is stated in *-pmip6basicmcast-solution-01 I-D this was probably to support ND.

Finally, what is the point of describing two different MLD handling behaviors for a MAG in these two I-Ds, when both obviously require changes to the MAG. Or did I miss something? ;)

[behcet] This is a deeper question.
The reason for *-pmip6basicmcast-solution-01 I-D is to come up with a solution which is LMA-based and which is inline with MIPv6/MIPv4 base spec multicast support. We did not assume any multicast proxy support at the MAG. Very minimal forwarding requirement on the MAG
So basically the idea was not to get into any optimization ideas.

I think that *-mcast-deployment-00  did not have the same requirements.

Cheers,
    Jouni

snipped the rest

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Thu, 18 Jun 2009 18:38:03 +0200

Hi Jouni,

thanks for your comments!

jouni korhonen wrote:

> proxy behavior if MLD report/query/etc messages' source and destination 
> addresses were listed in each case and both sides of the MAG. Something 
> like what RFC2710 did.
> 

O.k., good suggestion: we will add this in the next revision which is 
about to come soon.

> version. Also I do not understand what the first sentence in Section 5. 
> is about. Where is that requirement said?
> 
What requirements do you refer to - apart from MLDv2?
Actually, there should not be any.

Regarding MLDv2: there is no general consensus on putting this as a 
requirement ... I don't believe there is an issue in using MLDv1 here, 
as well.

About Sect 5, first sentence:
I guess, this is just "catch up" on PMIPv6, recalling the context. I 
suppose it is not meant as adding a requirement ...

> changes to the MAG. Or did I miss something? ;)

Two different approaches to the problem have been around - in preparing 
two documents we hope to support the discussion on the right way to go.

However, the *-mcast-deployment-00 I-D should not require changes to the 
MAG apart from activating another protocol standard (MLD Proxy). That's 
at least the objective of it.

Regards,

Thomas

--

---

From: jouni korhonen <[email-masked]>
Date: Thu, 18 Jun 2009 23:33:13 +0300

Hi Bechet,

On Jun 18, 2009, at 7:33 PM, Behcet Sarikaya wrote:

> One comment regarding the *-mcast-deployment-00 I-D. It would  
> benefit greatly readability of this I-D and help to understand the  
> exact MLD proxy behavior if MLD report/query/etc messages' source  
> and destination addresses were listed in each case and both sides of  
> the MAG. Something like what RFC2710 did.
>
> that it has new requirements to MNs apart from supporting certain  
> MLD version. Also I do not understand what the first sentence in  
> Section 5. is about. Where is that requirement said?
>

Right. Anyway, MLD hop limit is 1. It would not be forwarded beyond  
MAG anyway.

What about the new requirement on MNs?

> The reason for *-pmip6basicmcast-solution-01 I-D is to come up with  
> a solution which is LMA-based and which is inline with MIPv6/MIPv4  
> base spec multicast support. We did not assume any multicast proxy  
> support at the MAG. Very minimal forwarding requirement on the MAG

It is ok to have multiple solution proposals. The thing I am puzzled  
here is that *-pmip6basicmcast-solution-01 seems to require code  
changes in a MAG, then why not making it properly multicast aware?

Cheers,
	Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Jun 2009 14:19:27 -0700 (PDT)

Hi Jouni,

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>
> Cc: Thomas C. Schmidt <[email-masked]>; [email-masked]
> Sent: Thursday, June 18, 2009 3:33:13 PM
> > From: jouni korhonen 
> > To: Thomas C. Schmidt 
> > Subject: Re: [multimob] New Version Notification for 
> draft-schmidt-multimob-pmipv6-mcast-deployment-00
> > 
> > Hi Thomas,
> > 
> > One comment regarding the *-mcast-deployment-00 I-D. It would benefit greatly 
> readability of this I-D and help to understand the exact MLD proxy behavior if 
> MLD report/query/etc messages' source and destination addresses were listed in 
> each case and both sides of the MAG. Something like what RFC2710 did.
> > 
> > Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit odd that it 
> has new requirements to MNs apart from supporting certain MLD version. Also I do 
> not understand what the first sentence in Section 5. is about. Where is that 
> requirement said?
> > 
> Right. Anyway, MLD hop limit is 1. It would not be forwarded beyond MAG anyway.
> 

Because no multicast interface is assumed on the MAG, MN receives the multicast data encapsulated in a unicast packet, it should decapsulate and give it its multicast interface. 
This requirement is the same as in MIPv6 RFC 3775. 
> > Finally, what is the point of describing two different MLD handling behaviors 
> for a MAG in these two I-Ds, when both obviously require changes to the MAG. Or 
> did I miss something? ;)
> > 
> > 
> > The reason for *-pmip6basicmcast-solution-01 I-D is to come up with a solution 
> which is LMA-based and which is inline with MIPv6/MIPv4 base spec multicast 
> support. We did not assume any multicast proxy support at the MAG. Very minimal 
> forwarding requirement on the MAG
> It is ok to have multiple solution proposals. The thing I am puzzled here is 
> that *-pmip6basicmcast-solution-01 seems to require code changes in a MAG, then 
> why not making it properly multicast aware?
> 

I understand but making MAG multicast aware comes with a lot assumptions and also complications at the LMA. It has been left out of scope with *-pmip6basicmcast-solution-01 I-D. These are optimizations that avoid things like avalanche problem. It is left for other drafts to deal with.
*-pmip6basicmcast-solution-01 I-D is simple and enables maximum code share with the legacy HA.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Fri, 19 Jun 2009 00:29:06 +0300

Hi Thomas,

On Jun 18, 2009, at 7:38 PM, Thomas C. Schmidt wrote:

>> and destination addresses were listed in each case and both sides  
>> of the MAG. Something like what RFC2710 did.
>
> O.k., good suggestion: we will add this in the next revision which  
> is about to come soon.

Great.

>
>
>> Regarding the *-pmip6basicmcast-solution-01 I-D, I find it a bit  
>> odd that it has new requirements to MNs apart from supporting  
>> certain MLD version. Also I do not understand what the first  
>> sentence in Section 5. is about. Where is that requirement said?

The last sentence in Section 6. states:

"..unicast packets with the multicast datagram encapsulated. The  
mobile node MUST be capable of decapsulating packets sent to its home  
address in order to receive multicast datagrams."
I see a MUST there. I am no means multicast savvy but it seems that  
the functionality above requires a bit more than just multicast  
reception capabilities from the MN... or? The LMA encapsulates a  
multicast packet inside another IP header before tunneling it to the  
MAG and eventually the MN is supposed to decapsulate the additional  
header before realizing that the packet is about multicast traffic.  
Section 3. references to RFC3344 (MIPv4..?) when it discusses this case.
How the MN would know when it needs to decapsulate some packet and  
when not? Based on the source address? Maybe I have missed some RFC  
where this is already defined?

> requirement ... I don't believe there is an issue in using MLDv1  
> here, as well.

Ok. That's fine. The I-D just says in Section 6. that the MN must be  
MLDv2 capable.

> Two different approaches to the problem have been around - in  
> preparing two documents we hope to support the discussion on the  
> right way to go.
>
> However, the *-mcast-deployment-00 I-D should not require changes to  
> the MAG apart from activating another protocol standard (MLD Proxy).  
> That's at least the objective of it.

The MLD proxy approach looked fine to me.

Cheers,
	Jouni

---

From: "Thomas C. Schmidt" <[email-masked]>
Date: Fri, 19 Jun 2009 00:32:22 +0200

Hi Jouni,

jouni korhonen wrote:

> "..unicast packets with the multicast datagram encapsulated. The mobile 
> node MUST be capable of decapsulating packets sent to its home address 
> in order to receive multicast datagrams."
> I see a MUST there. I am no means multicast savvy but it seems that the 
> functionality above requires a bit more than just multicast reception 
> capabilities from the MN... or? The LMA encapsulates a multicast packet 
> inside another IP header before tunneling it to the MAG and eventually 
> the MN is supposed to decapsulate the additional header before realizing 
> that the packet is about multicast traffic. Section 3. references to 
> RFC3344 (MIPv4..?) when it discusses this case.
> How the MN would know when it needs to decapsulate some packet and when 
> not? Based on the source address? Maybe I have missed some RFC where 
> this is already defined?
>

Actually, I'm a bit uneasy with this tunneling, as well. If a MN 
receives encapsulated packets from a uni-directional GRE-tunnel, I guess 
it should just decapsulate them. However, the problem seems to be with 
the "interfaces": Unlike in RFC3775, the MN does not have a 
(bi-directional) tunnel interface to which it issues the MLD reports. 
Instead, it uses its regular (wireless) interface that in response 
receives unicast-encapsulated packets. I'm not exactly sure whether this 
really does work transparently, but it certainly gets more confusing 
with queries arriving from the LMA also in the tunnel.

So this approach certainly needs more analysis and discussions.

Cheers,

Thomas

--

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 18 Jun 2009 16:28:40 -0700 (PDT)

----- Original Message ----
> From: Thomas C. Schmidt <[email-masked]>
> To: jouni korhonen <[email-masked]>
> Cc: [email-masked]
> Sent: Thursday, June 18, 2009 5:32:22 PM
> > "..unicast packets with the multicast datagram encapsulated. The mobile node 
> MUST be capable of decapsulating packets sent to its home address in order to 
> receive multicast datagrams."
> capabilities from the MN... or? The LMA encapsulates a multicast packet inside 
> another IP header before tunneling it to the MAG and eventually the MN is 
> supposed to decapsulate the additional header before realizing that the packet 
> is about multicast traffic. Section 3. references to RFC3344 (MIPv4..?) when it 
> discusses this case.

Please see Sec. 4.4 in RFC 3344 on page 67. MIPv4 HA uses nested tunneling to send multicast data to MN.

> > How the MN would know when it needs to decapsulate some packet and when not? 
> Based on the source address? Maybe I have missed some RFC where this is already 
> defined?
> > 
> 
> Actually, I'm a bit uneasy with this tunneling, as well. If a MN receives 
> encapsulated packets from a uni-directional GRE-tunnel, I guess it should just 
> decapsulate them. However, the problem seems to be with the "interfaces": Unlike 
> in RFC3775, the MN does not have a (bi-directional) tunnel interface to which it 
> issues the MLD reports. Instead, it uses its regular (wireless) interface that 
> in response receives unicast-encapsulated packets. I'm not exactly sure whether 
> this really does work transparently, but it certainly gets more confusing with 
> queries arriving from the LMA also in the tunnel.
> 
Maybe so. In this case MN sends and receives from the MAG regularly and the tunneled incoming packets are indicated properly so MN should be able to decapsulate them.

I am not sure if this means MN is taking part in mobility signaling which is not allowed in PMIPv6.

More comments will be welcome.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Fri, 19 Jun 2009 09:27:22 +0300

Hi Behcet,

On Jun 19, 2009, at 2:28 AM, Behcet Sarikaya wrote:

>>>>> odd that it
>>> mobile node

The text is for a MIPv4 capable MN.. here in PMIP6 context we are  
talking about unmodified MN and cannot assume it has some  
functionality inherited just like that from MIPv4 specs.

>>> when not?
>> receives
> Maybe so. In this case MN sends and receives from the MAG regularly  
> and the tunneled incoming packets are indicated properly so MN  
> should be able to decapsulate them.

Indicated properly how?

Cheers,
	Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Jun 2009 07:46:56 -0700 (PDT)

Hi Jouni,

----- Original Message ----
> Cc: [email-masked]; Thomas C. Schmidt <[email-masked]>
> Sent: Friday, June 19, 2009 1:27:22 AM
> inside
> The text is for a MIPv4 capable MN.. here in PMIP6 context we are talking about 
> unmodified MN and cannot assume it has some functionality inherited just like 
> that from MIPv4 specs.
> 
> 
> > 
> > 
> > Maybe so. In this case MN sends and receives from the MAG regularly and the 
> tunneled incoming packets are indicated properly so MN should be able to 
> decapsulate them.
> 
> Indicated properly how?

IP Header Protocol field. There is a value reserved for IP-in-IP encapsulation. You can check this at:
http://www.iana.org/assignments/protocol-numbers/

So MN knows that it received an encapsulated packet. Whether an unmodified MN can decapsulate such packets and look at the new header and process them as multicast data, I guess yes, but I am not sure.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Mon, 22 Jun 2009 14:31:17 +0300

Hi Behcet,

> Hi Jouni,

[snip]

> So MN knows that it received an encapsulated packet. Whether an  
> unmodified MN can decapsulate such packets and look at the new  
> header and process them as multicast data, I guess yes, but I am not  
> sure.

Righty. The "IPIP decapsulation" i.e. the tunnel interface should be  
clever enough to figure out this is about multicast traffic and pass  
the packet to the proper multicast receiver part in the stack. That is  
a broad assumption. Here, GRE could work better than IPIP. There is  
also another problem. You cannot assume that the MN has any  
possibility to find out the LMA Address. For example, in some  
architectures that has been purposely prohibited. And how an  
unmodified host could tell a difference between LMA Address and any  
other address?

Regarding the I-D, it has to be more specific what is actually  
required from a MN to receive encapsulated multicast traffic. So far  
it looks to me that none of the proposed (encapsulation) methods work  
out of box in a multicast enabled host, even if we were not  
considering configuring (widely deployed) tunnels and such as a host  
change. If host changes are in scope, then chances are better but the  
I-D must be explicit about that decision then. The amount of  
additional text would not be that big imho.

Cheers,
	Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 23 Jun 2009 13:49:56 -0700 (PDT)

Hi Jouni,

----- Original Message ----
> Sent: Monday, June 22, 2009 6:31:17 AM
> > So MN knows that it received an encapsulated packet. Whether an unmodified MN 
> can decapsulate such packets and look at the new header and process them as 
> multicast data, I guess yes, but I am not sure.
> 
> Righty. The "IPIP decapsulation" i.e. the tunnel interface should be clever 
> enough to figure out this is about multicast traffic and pass the packet to the 
> proper multicast receiver part in the stack. That is a broad assumption. Here, 
> GRE could work better than IPIP. There is also another problem. You cannot 
> assume that the MN has any possibility to find out the LMA Address. For example, 
> in some architectures that has been purposely prohibited. And how an unmodified 
> host could tell a difference between LMA Address and any other address?

Yes, this is good point.

> 
> Regarding the I-D, it has to be more specific what is actually required from a 
> MN to receive encapsulated multicast traffic. So far it looks to me that none of 
> the proposed (encapsulation) methods work out of box in a multicast enabled 
> host, even if we were not considering configuring (widely deployed) tunnels and 
> such as a host change. If host changes are in scope, then chances are better but 
> the I-D must be explicit about that decision then. The amount of additional text 
> would not be that big imho.

What we came up with is to get the decapsulation done at the MAG so that MAG gets MN address and forwards the multicast packet to MN on MAG-MN link.

What do you think about it?

Regards,

Behcet